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: o System Structure o Correspondence between requirements and implementation . A framework for understanding system-level concerns o Global rates of flow 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: No later than: 15 Feb 2023 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 • Encapsulations of state with functions for accessing and manipulating that state Advantages and Disadvantages of OOD . Advantages o UML modeling notation o Design patterns . Disadvantages o Provides only • One level of encapsulation (the object) • One notion of interface • One type of explicit connector (procedure call) • Even message passing is realized via procedure calls o OO programming language might dictate important design decisions o OOD assumes a shared address space Domain Specific Software Architecture (DSSA) o Capturing and characterizing the best solutions and best practices from past projects within a domain o Production of new applications can focus on the points of novel variation o Reuse applicable parts of the architecture and implementation o Applicable for product lines Implementation o The objective is to create machine-executable source code • That code should be faithful to the architecture • Alternatively, it may adapt the architecture • How much adaptation is allowed? • Architecturally-relevant vs. unimportant adaptations o It must fully develop all outstanding details of the application Faithful Implementation o All of the structural elements found in the architecture are implemented in the source code o Source code must not utilize major new computational elements that have no corresponding elements in the architecture o Source code must not contain new connections between architectural elements that are not found in the architecture Unfaithful Implementation o The implementation does have an architecture • It is latent, as opposed to what is documented. o Failure to recognize the distinction between planned and implemented architecture • robs one of the ability to reason about the application’s architecture in the future • misleads all stakeholders regarding what they believe they have as opposed to what they really have • makes any development or evolution strategy that is based on the documented (but inaccurate) architecture doomed to failure Implementation Strategies o Generative techniques • e.g. parser generators o Frameworks • collections of source code with identified places where the engineer must “fill in the blanks” o Middleware • CORBA, DCOM, RPC, … o Reuse-based techniques • COTS, open-source, in-house o Writing all code manually How It All Fits Together Analysis and Testing o Analysis and testing are activities undertaken to assess the qualities of an artifact o The earlier an error is detected and corrected the lower the aggregate cost o Strict representations are required for analysis, so accurate questions can be asked and answered Analysis of Architectural Models o Formal architectural model can be examined for internal consistency and correctness o An analysis on a formal model can reveal • Component mismatch • Incomplete specifications • Undesired communication patterns • Deadlocks • Security flaws o It can be used for size and development time estimations Analysis of Architectural Models (cont’d) • Architectural model o may be examined for consistency with requirements o may be used in determining analysis and testing strategies for source code o may be used to check if an implementation is faithful Evolution and Maintenance • All activities that chronologically follow the release of an application • Software will evolve o Regardless of whether one is using an architecture-centric development process or not • The traditional software engineering approach to maintenance is largely ad hoc o Risk of architectural decay and overall quality degradation • Architecture-centric approach o Sustained focus on an explicit, substantive, modifiable, faithful architectural model Architecture-Centric Evolution Process • Motivation • Evaluation or assessment • Design and choice of approach • Action o includes preparation for the next round of adaptation Processes • Traditional software process discussions make the process activities the focal point • In architecture-centric software engineering the product becomes the focal point • No single “right” software process for architecture-centric software engineering exists THANK YOU FOR LISTENING !