Lecture 1 Introduction To Software Architecture Architecture thinking One possible answer Role of software architecture Context What is software architecture ? Definitions  Architecture for a specific system may be captured as “a collection of computational components – or simply components – together with a description of the interactions between these components – the connectors” An Introduction to Software Architecture - Garlan and Shaw (1993)  The design process for identifying the subsystem making up a system and the framework for sub-system control and communication is the architecture design. The output of this design process is a description of the software architecture. Software Engineering - Sommerville (2004) Concept & examples To sum up, we can define software architecture as "The decomposition of software systems into modules" Primary criteria: extendibility and reusability Examples of software architecture techniques & principles:  Abstract data types  Object-oriented techniques: the notion of class, inheritance, dynamic binding  Object-oriented principles: uniform access, single- choice, open-closed principle…  Design patterns  Classification of software architecture styles, e.g. pipes and filters Develop systems “architecturally”  Design at an architectural level of abstraction  Build systems compositionally from parts  Assure that the system will satisfy critical requirements before it is constructed  Recognize and reuse standard architecture patterns and styles  Reuse codified architectural design expertise  Reduce costs through product-lines “Large” software systems What may be large: any or all of  Source size (lines of code)  Binary size  Number of users  Number of developers  Life of the project (years)  Number of changes  Number of versions Process and product o Software engineering affects both:  Software products  The processes used to obtain and operate them o Products are not limited to code. Other examples include requirements, design, documentation, test plans, test results, bug reports o Processes exists whether they are formalized or not Software quality factors Software engineering today 3 main cultures:  Process  Agile  Object-oriented The first 2 are usually seen as exclusive, but all have major contributions to make. Process culture Emphasize:  Plans  Schedules  Documents  Requirements  Specifications  Order of tasks  Commitments Examples: Rational Unified Process, CMMI, Waterfall… Agile culture Characteristics: o Short iterations o Emphasis on working code; de-emphasis of plans and documents o Emphasis on testing; de-emphasis of specifications and design . "Test-Driven Development" o Constant customer involvement o Refusal to commit to both functionality and deadlines o Specific practices, e.g. Pair Programming Examples: Extreme Programming (XP), Scrum Agile culture XP methodology Scrum framework Object-oriented culture Emphasizes:  Seamless development  Reversibility  Single Product Principle  Design by Contract Software Architecture  Architecture serves as a blueprint for a system.  It provides an abstraction to manage the system complexity and establish a communication and coordination mechanism among components.  It defines a structured solution to meet all the technical and operational requirements, while optimizing the common quality attributes like performance and security. Software Architecture  It involves a set of significant decisions about the organization related to software development and each of these decisions can have a considerable impact on quality, maintainability, performance, and the overall success of the final product. These decisions comprise of:  Selection of structural elements and their interfaces by which the system is composed.  Behavior as specified in collaborations among those elements.  Composition of these structural and behavioral elements into large subsystem.  Architectural decisions align with business objectives.  Architectural styles guide the organization. Goals of Architecture  The primary goal of the architecture is to identify requirements that affect the structure of the application.  A well-laid architecture reduces the business risks associated with building a technical solution and builds a bridge between business and technical requirements.  Some of the other goals are as follows:  Expose the structure of the system, but hide its implementation details.  Realize all the use-cases and scenarios.  Try to address the requirements of various stakeholders.  Handle both functional and quality requirements.  Reduce the goal of ownership and improve the organization’s market position.  Improve quality and functionality offered by the system.  Improve external confidence in either the organization or system. From Requirements to Architecture  From problem definition to requirements specification o Determine exactly what the customer and user want o Specifies what the software product is to do  From requirements specification to architecture o Decompose software into modules with interfaces o Specify high-level behavior, interactions, and non-functional properties o Consider key tradeoffs  Schedule vs. Budget  Cost vs. Robustness  Fault Tolerance vs. Size  Security vs. Speed o Maintain a record of design decisions and traceability o Specifies how the software product is to do its tasks Focus of Software Architecture  Two primary focuses:  A framework for understanding o System Structure system-level concerns o Correspondence between o Global rates of flow requirements and implementation o Communication patterns o Execution Control Structure o Scalability o Paths of System Evolution o Capacity o Throughput o Consistency o Component Compatibility Why software architecture ?  A key to reducing development costs o Component-based development philosophy o Explicit system structure  A natural evolution of design abstractions o Structure and interaction details overshadow the choice of algorithms and data structures in large/complex systems  Benefits of explicit architectures o A framework for satisfying requirements o Technical basis for design o Managerial basis for cost estimation & process management o Effective basis for reuse o Basis for consistency, dependency, and tradeoff analysis o Avoidance of architectural erosion Scope of Software Architecture  Details of the architecture are a reflection of system requirements and trade-offs made to satisfy them  Possible decision factors o Performance o Compatibility with legacy software o Planning for reuse o Distribution profile  Current and Future o Safety, Security, Fault tolerance requirements o Evolvability Needs  Changes to processing algorithms  Changes to data representation  Modifications to the structure/functionality Software “Architecting”  The “architecting” problem lies in: o Decomposition of a system into constitutional elements o Composition of (existing) elements into a system  Two idealized approaches o Top-Down  Decompose the large problem into sub-problems  Implement or reuse components that solve the sub-problems o Bottom-Up  Implement new or reuse existing stand-alone components  Compose (a subset of) the components into a system  A realistic approach will require both. Architecture Evaluation  A software architecture is the earliest life-cycle artifact that embodies significant design decisions.  Analyzing for system qualities early in the life cycle allows for a comparison of architectural options.  With the advent of cost-effective, repeatable architecture evaluation methods, architecture evaluation should be a standard part of every architecture-based development methodology. When and why to evaluate an architecture ?  When building a system o Evaluation should be done when deciding on architecture.  When acquiring a system o Architectural evaluation is useful if the system will have a long lifetime within organization. o Evaluation provides a mechanism for understanding how the system will evolve. o Evaluation can also provide insight into other visual qualities. A pattern example A reservation panel Flight sought from: To: Santa Barbara Zurich Depart no earlier than: 03 Feb 2023 No later than: 04 Feb 2023 ERROR: Let’s choose a date in the future Choose next action: 0 – Exit 1 – Help 2 – Further enquiry 3 – Reserve a seat A reservation panel Flight sought from: To: Santa Barbara Zurich Depart no earlier than: 15 Feb 2023 No later than: 16 Feb 2023 AVAILABLE FLIGHTS: 2 Flt# UA 425 Dep 8:25 Arr 7:45 Thru: LAX, JFK Flt# AA 082 Dep 7:40 Arr 9:15 Thru: LAX, DFW Choose next action: 0 – Exit 1 – Help 2 – Further enquiry 3 – Reserve a seat The transition diagram What’s wrong with the previous solution ? Complex branching structure  unstructured solution, difficult to-maintain source code Extendibility problems: dialogue structure "wired“ into program structure. A functional, top-down solution Represent the structure of the diagram by a function transition ( i, k) giving the state to go to from state i for choice k. This describes the transitions of any particular application. Function transition may be implemented as a data structure, for example a two-dimensional array. The transition function 0 1 2 3 0 (Initial) 2 1 (Help) Exit Return 2 (Confirmation) Exit 3 0 3 (Reservation) Exit 4 2 4 (Seats) Exit 5 3 5 (Flights) Exit 0 4 The transition diagram Software Architecture in context Fundamental Understanding  3 fundamental understandings of software architecture o Every application has an architecture o Every application has at least one architect o Architecture is not a phase of development Wrong View: Architecture as a Phase o Treating architecture as a phase denies its foundational role in software development o More than “high-level design” o Architecture is also represented, e.g., by object code, source code, … Context of Software Architecture o Requirements o Design o Implementation o Analysis and Testing o Evolution o Development Process Requirements Analysis  Traditional SE suggests requirements analysis should be clean and fresh by any consideration for a design  However, without reference to existing architectures it becomes difficult to assess practicality, schedules, or costs o In building architecture we talk about specific rooms… o …rather than the abstract concept “means for providing shelter”  In engineering, new products come from the observation of existing solution and their limitations New Perspective on Requirements Analysis  Existing designs and architectures provide the solution vocabulary  Our understanding of what works now, and how it works, affects our wants and perceived needs  The insights from our experiences with existing systems • helps us imagine what might work and • enables us to assess development time and costs  Requirements analysis and consideration of design must be pursued at the same time Non-Functional Properties (NFP)  NFPs are the result of architectural choices  NFP questions are raised as the result of architectural choices  Specification of NFP might require an architectural framework to enable their statement  An architectural framework will be required for assessment of whether the properties are achievable The Twin Peaks Model  The Twin Peaks Model is used in software development to iteratively develop the architecture and the requirements.  Both “peaks” are equally important. Design and Architecture  Design is an activity that pervades software development  It is an activity that creates part of a system’s architecture  Typically in the traditional Design Phase decisions concern o A system’s structure o Identification of its primary components o Their interconnections  Architecture denotes the set of principal design decisions about a system o That is more than just structure Architecture-Centric Design  Traditional design phase suggests translating the requirements into algorithms, so a programmer can implement them  Architecture-centric design o stakeholder issues o decision about use of Commercial off-the-shell (COTS) component o overarching style and structure o package and primary class structure o deployment issues o post implementation/deployment issues Design Techniques o Basic conceptual tools  Separation of concerns  Abstraction  Modularity o Two illustrative widely adapted strategies  Object-oriented design  Domain-specific software architectures (DSSA) Object-Oriented Design (OOD) o Objects  Main abstraction entity in OOD