1. Unit-1 INTRODUCTION Presented by Sushma Narasimhan Asst. Professor,
Computer Science Department
Engineered for Tomorrow

2. Unit- I
Architecture Business Cycle
What is Software Architecture?

3. The Architecture Business Cycle
Introduction
Where Do Architectures Come From?   
Software Processes and the Architecture Business Cycle 
What Makes a "Good" Architecture?

4. Introduction
A software architecture is developed as the first step toward designing a system.
The software architecture of a program is the structure of the system, which includes:
the software elements,
the externally visible properties of those elements,
the relationships among the elements.

5. Que: What happens when two different architects working in two different organizations, are given the same requirement specification for a system? Ans: They will produce different architecture. WHY???

6. Relationship b/w Software Architecture & its environment
Technical Influences
Business Influences
Social Influences
Software Architecture
An architecture is the result of a set of business and technical decisions.

7. Contd..
Software architecture is a result of technical, business, and social influences.
The Software architecture existence affects the technical, business, and social environments that subsequently influence future architectures.
We call this cycle of influences, from the environment to the architecture and back to the environment, the Architecture Business Cycle (ABC).

8. The Architecture Business Cycle
Introduction
Where Do Architectures Come From?   
Software Processes and the Architecture
Business Cycle 
What Makes a "Good" Architecture?

9. Contd.. Factors influencing Software Architecture
1) System stakeholders
2) Developing organization
3) Background & Experience of the Architect
4) Technical Environment

10. 1) ARCHITECTURES ARE INFLUENCED BY THE SYSTEM STAKEHOLDERS
Customer
Marketing
Development organization’s management
Maintenance organization
End User
Low Cost, Keeping people employed, leveraging existing corporate assets !
Neat features, short time to market, low cost, parity with competing products !
Behavior, performance, security, reliability !
Modifiability
Low cost, timely delivery, not changed very often !

11. Contd.. Customers Who are System Stakeholders? End users Developers
Project manager
Maintenance
personnel
Marketing

12. Contd..
Each stakeholder has different concerns and goals, some of which may be contradictory, such as:
an optimized system
certain runtime behaviour
good performance on specific hardware
easy customization
low development cost & shorter marketing time
provide broad range of functionality
The architect often has to fill in the blanks and mediate the conflicts.

13. 2) ARCHITECTURES ARE INFLUENCED BY THE DEVELOPING ORGANIZATION
Architecture of the proposed system is influenced by the structure or nature of the development organization.
3 classes of influence from developing organization are:
Immediate business – proposed system is next in a sequence of similar systems, with a high degree of re-use.
Long-term business – organisation likes to make long-term investment in an infrastructure to pursue strategic goals.
Organizational structure – functionality in the architecture is divided to facilitate development of sub-systems, by contracts to specialized experts.

14. 3) ARCHITECTURES ARE INFLUENCED BY background & experience of the Architects
Factors influencing the choice of architecture:
Architect’s education & training
Previous exposure to successful architectural patterns
Previous exposure to systems that have worked extremely poor or extremely well

15. 4) ARCHITECTURES ARE INFLUENCED BY THE TECHNICAL ENVIRONMENT
The environment where an architecture is designed will influence that architecture.
The environment might include standard industry practices or software engineering techniques common in the architect's professional community

16. Ramifications of influences on an architecture
Architects must identify & actively engage the stakeholders to solicit their needs and expectations.
This allows the architects to understand constraints, manage expectations, negotiate priorities & make trade-offs.
Architecture reviews and iterative prototyping are two means for achieving it.
Apart from technical skills, an effective architect, diplomacy, negotiation, and communication skills are essential.

17. Fig: Ramification of influences on an architecture

18. Contd…
Software Architecture is influenced by several factors such as system stakeholders, goals & structure of developing organization, technical environment of the proposed system, experience & background of the architect.
At the same time, these factors are influenced by the software architecture and the system built from it, forming feedback loops.
This cycle of influences, from the environment to the architecture and back to the environment, the Architecture Business Cycle (ABC).

19. Architect’s Influences
Contd..
Architect’s Influences
Customers
and End User
Architect
Requirements
(Qualities)
Architecture
Developing
Organization
System
Technical
Environment
Architect’s
Experience
Fig: Architecture Business Cycle

20. How ABC Works ?
Architecture affects the structure of the developing organization.
Architecture affects the goals of the developing organisation.
Architecture affects the customer requirements for the next system.
Process of system building will affect the architect’s experience with subsequent systems.
Few systems influence and change the technical environment in which system builders operate & learn.

21. The Architecture Business Cycle
Introduction
Where Do Architectures Come From?   
Software Processes and the Architecture
Business Cycle 
What Makes a "Good" Architecture?

22. Software Processes and the Architecture Business Cycle
Software process – used to describe organization, ritualization, and management of software development activities
Activities in the software process include:
Creating business case for system
Understanding requirements
Creating or selecting architecture
Documenting & communicating architecture
Analyzing or evaluating architecture
Implementing system based on architecture
Ensuring implementation conforms to architecture
Creating Business Case – broader than assessing market need for a system – important for creating and constraining future requirements
How much should cost? What is target market? What is targeted time to market? Will it need to interface with other systems?
Understanding Requirements – Many techniques for determining requirements of stakeholders.
Fundamental decision – to what extent is it a variation of other systems
Important to understand prior system’s characteristics
Creation of prototypes will also help to understand the requirements
Creating or Selecting Architecture – conceptual integrity is the key to sound design & small # of minds must come together to design architecture
Documenting & Communicating Architecture – to be effective, architecture must be documented and clearly communicated to all stakeholders
Documentation should be informative and readable by many people with different backgrounds
Analyzing or Evaluating Architecture – Any design process multiples alternative will be considered. Architecture must be evaluated for its qualities to be sure it will meet needs of stakeholders.
Scenario based techniques provides an effective approach for evaluation.
Implementing system based on architecture – Keeps developers faithful to structure & interaction protocols constrained by architecture
Ensuring Implementatioin conforms to architecture – after architecture is created & used, it goes into a maintenance phase

23. Contd.. Architecture activities in ABC
Creating business case for system
Understanding requirements
Creating or selecting architecture
Documenting & communicating architecture
Analyzing or evaluating architecture
Implementing system based on architecture
Ensuring implementation conforms to architecture

24. The Architecture Business Cycle
Introduction
Where Do Architectures Come From?   
Software Processes and the Architecture
Business Cycle 
What Makes a "Good" Architecture?

25. What Makes “Good” Architecture?
No inherently good or bad Architecture
Architectures are either more or less fit for some stated purpose.
Rules of thumb or guidelines should be followed while designing an architecture.
Process guidelines or recommendations
Product(structural) guidelines or recommendations

26. Process Guidelines
Single architect or small group with identified leader.
Must have system technical requirements and articulated, prioritized qualitative properties.
Architecture must be well-documented using an agreed-on notation that all can understand.
Architecture should be actively reviewed by all stakeholders.

27. Process Guidelines (Cont.)
Analyze architecture for applicable quantity measures and formally evaluate for quality attributes.
Architecture should allow creation of a skeletal system on which functionality can incrementally grow.
Architecture should result in specific set of resource contention areas. Ex: If network utilization is area of concern, architect should design an architecture which results in minimum network traffic.

28. Product (Structural) Guidelines
Should have well-defined modules whose functional responsibilities are achieved using information hiding and separation of concerns.
Each module should have a well-defined interface that encapsulates implementation strategies and data structure choices from other software which uses their facilities.
Quality attributes should be achieved using well-known architectural tactics specific to each attribute.

29. Product (Structural) Guidelines (Cont.)
Never depend on a particular version of a commercial product or tool; make change straightforward and inexpensive.
Modules which produce data should be separate from modules which consume data, hence increasing the modifiability..
For parallel processing, well-defined processes and tasks that may not mirror module decomposition structure.

30. Product (Structural) Guidelines (Cont.)
Every process or task should be written such that processor allocation can be easily changed, even at run-time.
Consistently use a small number of simple interaction patterns, so that the system performs same things in same manner all the time.

31. Unit- I
Architecture Business Cycle
What is Software Architecture?

32. What is Software Architecture?
What software architecture is & what isn’t?
Other points of view
Architectural patterns, Reference models, Reference architectures
Why is software architecture important?
Architectural structures & views

33. Definition
The software architecture of a program is the structure of the system, which include:
the software elements,
the externally visible properties of those elements,
the relationships among the elements.
Externally-visible properties of elements are assumptions that one elements can make about another:
provided services, required services, performance characteristics, fault handling, resource usage
Replace building photo, and improve runaround.
© 2002 by Carnegie Mellon University 17

34. Contd.. Implications of this Definition
1) Architecture defines software elements.
Architecture is an abstraction of a system, which describes interaction between these software elements.
Private details such as their internal implementation are not included.
2) Systems comprise of more than one structure.
A structure by itself cannot be termed as architecture.
An architecture comprises of several kinds of structures, several kinds of elements and several kinds of interactions among elements.

35. Contd…
3) Every computing system with software has a software architecture.
An architecture can exist independently of its description or specification.
4) Behavior of each element is part of the architecture.
How an element’s behavior influences another element and the acceptability of the system as a whole is captured in the architecture.

36. Contd..
5) The definition does not explain whether the architecture for a system is good or bad.
This gives rise to the need for architecture evaluation and design.

37. What is Software Architecture?
What software architecture is & what isn’t?
Other points of view
Architectural patterns, Reference models, Reference architectures
Why is software architecture important?
Architectural structures & views

38. Other Points of view Architecture is high-level design.
Architecture is the overall structure of the system.
Architecture is the structure of the components, their inter-relationships & guidelines for their design & evolution.
Architecture is nothing but a cluster of components and connectors.
Connectors are run-time mechanisms for transferring control & data around a system.

39. What is Software Architecture?
What software architecture is & what isn’t?
Other points of view
Architectural patterns, Reference models, Reference architectures
Why is software architecture important?
Architectural structures & views

40. Architectural patterns, Reference models, Reference architectures
Architectural Patterns - Definition
An architectural pattern is a description of
Software elements and their relation types
Set of constraints on the element types & their interaction pattern
A widely used pattern in modern distributed systems is the three-tiered system pattern
Science
Banking
E-commerce
Reservation systems

41. Contd.. Example - Three-Tiered Pattern Front Tier
Contains the user interface functionality to access the system’s services
Middle Tier
Contains the application’s major functionality
Back Tier
Contains the application’s data access and storage functionality

42. Contd.. Reference pattern-Definition
A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem.
Can you name the standard parts of a compiler or a
database management system?
Can you explain in broad terms how the parts work together to accomplish their collective purpose?
If so, it is because you have been taught a reference model of these application.

43. Contd.. Reference Architecture-Definition
A reference architecture is a reference model mapped onto software.
Whereas a reference model divides the functionality, a reference architecture is the mapping of that functionality onto a system decomposition.
A reference architecture can be thought of as a resource that documents the learning experiences gained through past projects.
By using a reference architecture, a project team can potentially save time and avoid mistakes by learning from past experiences. 

44. Contd..
Fig: Relationship between reference models, architectural patterns and reference architecture
Reference models, architectural patterns and reference architectures are themselves not architecture but capture the elements of architecture.
Reference Model
Reference Architecture
Software Architecture
Architectural Pattern

45. What is Software Architecture?
What software architecture is & what isn’t?
Other points of view
Architectural patterns, Reference models, Reference architectures
Why is software architecture important?
Architectural structures & views

46. Why is software architecture important?
Three fundamental reasons for software architecture’s importance:
Communication among stakeholders
a basis for mutual understanding, negotiation, & consensus
Early design decisions
earliest point at which decisions can be analyzed
Transferable abstraction of a system
can promote large-scale reuse

47. Contd.. i) Architecture is vehicle for stakeholder communication
1. Architecture provides a common language in which different concerns can be expressed, negotiated and resolved among the stakeholders.
2. Makes it easier to understand large systems sufficiently in order to make earlier decisions that influence both quality & usefulness of the system

48. Contd.. Architecture manifests the earliest set of design decisions
1. Architecture defines constraints on implementation.
2. Architecture dictates organizational structure.
3. Architecture inhibits or enables a system’s quality attributes.
4. System’s qualities can be predicted by studying the architecture.
5. Architecture makes it easier to reason about and manage change.
6. Architecture helps in evolutionary prototyping
7. Architecture enables more accurate cost & schedule estimate.

49. Contd.. Architecture as a transferable re-usable model
1. Software product lines share a common architecture.
2. Systems can be built using large, externally developed elements.
3. Less is more: It pays to restrict the vocabulary of design alternatives.
4. Architecture permits template-based development.
5. An architecture can be the basis for training.

50. What is Software Architecture?
What software architecture is & what isn’t?
Other points of view
Architectural patterns, Reference models, Reference architectures
Why is software architecture important?
Architectural structures & views

51. View & Structure- Illustration

52. Contd..
The neurologist, orthopedist, hematologist & the dermatologist have a different view of the structure of a human body.
Although these views have different properties, they are related to each other.
Similarly to communicate meaningfully about an architecture, it must be clear which structure or view of the architecture is being discussed.

53. Definition
A view is a representation of coherent set of architectural elements and the relations among them.
A structure is the set of elements itself, as they exist in software or hardware.
Example: A module structure is the set of system’s modules & their organization.
A module view is the representation of that view. As documented & used by the system stakeholders.

54. Types of Architectural Structures
There are 3 types of architectural structures based on the nature of architectural elements they consist of:
Module structures
units of implementation with assigned areas of functionality - usually static
Component-and-connector structures
runtime components (principal units of computation) and connectors (communication vehicles)
Allocation structures
show relationships between software elements & external environments (creation or execution)

55. Common software architecture structures

56. 1)Module based structures
Decomposition :
Units are modules related to each other, represented by “is a sub-module of” relation.
Larger modules are decomposed into smaller ones recursively until they are easily understood.
Uses :
The uses structure is used to engineer systems that can be easily extended to add functionality.
Units of this structure are related by the uses relation.

57. Contd..
3. Layered:
A layer is a coherent set of related functionality in which layer n may only use the services of layer n-1.
Layers are used primarily for data hiding & encapsulation.
4. Class or generalization:
Units of this structure are classes which are related by “ inherits from” or “ is an instance of” relation.

58. 2)Component and Connector structures
This structure includes the following:
Process or communicating process:
Units here are processes or threads that are connected with each other by communication, synchronization, and/or exclusion operations.
2. Concurrency:
Units are components and the connectors are logical threads.
A logical thread is a sequence of computation that can be allocated to a separate physical thread later in the design process.

59. Contd… 3. Shared data or repository:
Comprises of components & connectors that create, store & access persistent data.
Is used to ensure good performance and data integrity.
4. Client-server:
Components are clients & servers and the connectors are protocols and messages they share to carry out system’s work.
Useful for separation of concerns, physical distribution & load-balancing.

60. 3) Allocation Structures
Deployment:
Shows how software is assigned to hardware-processing & communication elements.
Relation “allocated to” shows on which physical units, the software elements reside, and “migrates to” , for dynamic allocation.
Implementation:
Shows how software elements are mapped to the file structure in the system’s development, integration or configuration control environment.

61. Contd… 3. Work assignment:
Assigns responsibility for implementing & integrating the modules to the appropriate development teams.
Helps to call out units of common functionality & assign them to a single team instead of individual implementation, in large multi-sourced distributed development projects.

62. Architectural structures at a Glance
Decomposition Shared Data
Uses Deployment
Layered Implementation
Class Work Assignment
Client-Server
Process
Concurrency

63. Relating Structures to Each Other
Although the structures give different system perspectives, they are not independent.
Elements of one structure are related to elements in another, and we need to reason about these relationships.
For example, a module in a decomposition structure may map to one, part of one, or several, components in a component-and-connector structure at runtime.
In general, mappings are many-many.

64. Which Structures to choose?(Four Plus One approach)
In Philippe Kruchten proposed the “Four Plus
One” approach, which forms the basis for the
Rational Unified process. The four views are:
Logical :
Elements are key abstractions, which are manifested as objects or object classes.
This is a module view.
Process :
Addresses concurrency & distribution of functionality.
This is a component & connector view.

65. Contd…
3. Physical :
Maps other elements onto processing and communication nodes.
This is an allocation view.