Engineered for Tomorrow Unit1 INTRODUCTION Engineered for Tomorrow

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

Engineered for Tomorrow Unit- I • Architecture Business Cycle • What is Software Architecture?

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

Engineered for Tomorrow 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: 1. the software elements, 2. the externally visible properties of those elements, 3. the relationships among the elements. 4

Engineered for Tomorrow 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? ? ?

Engineered for Tomorrow Relationship b/w Software Architecture & its environment Business Influence s Technical Influence s Social Influence s Software Architecture An architecture is the result of a set of business and technical decisions.

Engineered for Tomorrow 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). 7

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

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

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

Engineered for Tomorrow Contd. . Who are System Stakeholders? • Customers • • End users Developers Project manager Maintenance personnel • Marketing personnel

Engineered for Tomorrow 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. 12

Engineered for Tomorrow 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. 13

Engineered for Tomorrow 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 14

Engineered for Tomorrow 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 15

Engineered for Tomorrow 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.

Engineered for Tomorrow Fig: Ramification of influences on an architecture

Engineered for Tomorrow 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).

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

Engineered for Tomorrow 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.

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

Engineered for Tomorrow 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

Engineered for Tomorrow 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

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

Engineered for Tomorrow 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

Engineered for Tomorrow 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. 26

Engineered for Tomorrow 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. 27

Engineered for Tomorrow 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. 28

Engineered for Tomorrow 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. 29

Engineered for Tomorrow 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.

Engineered for Tomorrow Unit- I • Architecture Business Cycle • What is Software Architecture?

Engineered for Tomorrow 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

Engineered for Tomorrow Definition • The software architecture of a program is the structure of the system, which include: 1. the software elements, 2. the externally visible properties of those elements, 3. 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

Engineered for Tomorrow 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow 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

Engineered for Tomorrow 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 interrelationships & 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.

Engineered for Tomorrow 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

Engineered for Tomorrow 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 40

Engineered for Tomorrow 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 41

Engineered for Tomorrow 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow Contd. . Reference Model Architectural Pattern Reference Architecture Software Architecture 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.

Engineered for Tomorrow 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

Engineered for Tomorrow 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

Engineered for Tomorrow 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

Engineered for Tomorrow Contd. . ii) Architecture manifests the earliest set of design decisions 1. 2. 3. 4. Architecture defines constraints on implementation. Architecture dictates organizational structure. Architecture inhibits or enables a system’s quality attributes. 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.

Engineered for Tomorrow Contd. . iii) 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.

Engineered for Tomorrow 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

Engineered for Tomorrow View & Structure- Illustration

Engineered for Tomorrow 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow 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)

Common software architecture structures

Engineered for Tomorrow 1)Module based structures 1. 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. 2. 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.

Engineered for Tomorrow 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.

Engineered for Tomorrow 2)Component and Connector structures This structure includes the following: 1. 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.

Engineered for Tomorrow 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.

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

Engineered for Tomorrow 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 multisourced distributed development projects.

Engineered for Tomorrow Architectural structures at a Glance 1. 2. 3. 4. 5. 6. 7. Decomposition Uses Layered Class Client-Server Process Concurrency 8. Shared Data 9. Deployment 10. Implementation 11. Work Assignment

Engineered for Tomorrow 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.

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

Engineered for Tomorrow Contd… 3. Physical : • Maps other elements onto processing and communication nodes. • This is an allocation view.