Lecture 1 - Intorduction to Software Architecture.pdf

Chapter 1 INTRODUCTION TO SOFTWARE ARCHITECTURE  Objectives Introduce the relationship between software requirements and architecture Introduce the relationship between architectural styles and architecture Introduce the elements of software architecture Descr...

Chapter 1 INTRODUCTION TO SOFTWARE ARCHITECTURE  Objectives Introduce the relationship between software requirements and architecture Introduce the relationship between architectural styles and architecture Introduce the elements of software architecture Describe quality attributes trade-off analysis  Software architects use various design strategies in software construction to divide and conquer the complexities of a problem domain and solve the problem. A good software design reduces risks in software production, coordinates development teams to work together orderly, makes the system traceable for implementation and testing, and leads to software products that have higher quality attributes.  The input of software design is a Software Requirements Specification (SRS). The SRS is the result of requirement analysis; it records the functional and non-functional requirements that must be met by the software system. The output of software design is a document called Software Design Description (SDD). The SDD describes the software architecture or high-level design and the detailed design of the system.  It serves as the blueprint for the implementation phase. The SDD describes the components of a system, the modules that comprise each component, and the detailed information (such as data attributes, operations, and algorithms) of each module. From the SDD, the system is then implemented using programming language, which is followed by debugging, testing, and maintenance.  Sample outline of SDD based on IEEE Std 1016. Design overview, purpose, scope Decomposition description (module, data, process) Dependency and connection description (between modules, data, processes) Attributes User interface description Detailed design (module and data)  Notice that the software design stage can be further split into two steps: the architectural design step and the detailed design step. During the architectural design step we describe user accessible components and the interconnections among them that are visible to stakeholders. During the detailed design step we specify the internal details of each component and we might introduce new invisible components – to the stakeholder, into the design.  In practice, designers abstract common features such as similar choices on element types and connections into “families of architectures” using the notion of “architectural style.” Each style represents a layout topology of elements, and connections and interactions among these. It also describes its semantic constraints and behaviors concerning data transfer and control transfer among the elements in the system and the quality attributes trade-off as well.  Quality attributes are closely related to architectural styles. Each architectural style supports some quality features. An architectural style encapsulates tradeoffs among many conflicting quality attributes. List of sample quality attributes: Performance Maintainability Reliability Adaptability Portability Modifiability Security Usability Testability Scalability.  tradeoff between system performance Time Resource System Reliability Availability.  Software Architecture: Bridging Requirements and Implementation Software architecture plays a very important role in software development. The actual design is a blueprint and a guideline for developing a software system based on the software requirement analysis specification. The architectural design embodies earliest decisions that have a decisive impact on the ultimate success of the software product.  It shows how the system is structured in terms of components, and how its components work together. As the description of software construction structure, an architectural design must cover the software functional requirements and non- functional requirements as well. It serves as an evaluation and implementation plan for software development and for software evolution.  IEEE Std 1471 defines the system architecture as “the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” Shaw and Garlan (1996) regard software architecture as the description of elements that comprise a system, the interactions and patterns of these elements, the principles that guide their composition, and the constraints on these elements. A complete software architecture specification must describe not only the elements and connections between elements but also the constraints and runtime behaviors so that developers know what must be implemented and how it should be implemented.  Software architect’s tasks: Perform system static partitioning and decomposition into sub-systems and communications between sub-systems. A software element can be configured, delivered, developed, deployed and is replaceable in future. Each element has its interface that encapsulates details and provides loose coupling with other elements or sub-systems.  Establish dynamic control relationships between different sub-systems in terms of data flow, or control flow orchestration, or message dispatching. Consider and evaluate alternative architecture styles for the problem at hand. Perform trade-off analysis on quality attributes and other non-functional requirements during the selection of architecture styles. The most important job for a software architect is to map the software requirements specification to the software architecture and guarantee that the software architecture satisfies functional and non-functional requirements.  Architectural Styles An architectural style abstracts the common properties of a family of similar designs. An architectural style is a set of design decisions that describes a set of rules, constraints, and patterns of how to structure a system into a set of elements and connectors. It governs the overall structure design pattern of constituent element types and their runtime interaction of flow control and data transfer. Architectural Patterns vs. Antipatterns Architectural pattern – Set of architectural design decisions that apply to a recurring design problem and are parameterized to account for different software development contexts in which that problem appears e.g., three-tiered, sense-compute-control, MVC, etc. Antipatterns – Common solutions to common problems where the solution is ineffective and may result in undesired consequences such as design smells. It differs from bad practice as it is a common practice that initially seems an appropriate solution but ends up having bad consequences that outweigh any benefits, and there is another solution that is known, repeatable, and effective. e.g., the use of drag-drop for UI design.  The key components of an architectural style are listed as follows: Elements that perform functions required by a system Connectors that enable communication, coordination, and cooperation among elements Constraints that define how elements can be integrated to form the system Attributes that describe the advantages and disadvantages of the chosen structure  Pipe & Filter, Process Control (Data Flow) Repository, Blackboard (Data Centered) Object-Oriented Layered, Virtual Machine, Master/Slave(Hierarchy) Multi-tier, Client/Server (Distributed) Event-Based, Buffered Messaging (Asynchronous Communication) MVC, PAC (Interaction Oriented)  Quality Attributes Each architectural style has its advantages, disadvantages and potential risks. Choosing the right architectural style to satisfy required quality attributes is also very important in addition to function satisfaction. Quality attributes are identified in the requirement analysis process.  Implementation attributes (not observable at runtime) Interoperability: This refers to the universal accessibility and the ability to exchange data with internal components and the outside world. It needs loose dependency of infrastructure. Maintainability & extensibility: This refers to the ability to modify the system and extend it conveniently. Testability: This refers to the degree to which the system facilitates the establishment of test cases. It usually requires a complete set of documentation accompanied with system design and implementation.  Portability: This refers to the level of independence of the system on software and hardware platforms. Systems developed using high-level programming languages usually have good portability. One typical example is Java – most Java programs need only be compiled once and can run everywhere. Scalability: This refers to the ability to adapt to an increase of user requests volume. It disfavors bottlenecks in system design. Flexibility: This refers to the ease of modification of a system to cater for different environment or problems for which the system is originally not designed. Systems developed using the component based architecture or the service- oriented architecture usually possess this property. Runtime attributes (observable at runtime) Availability: This refers to the ability of a system to be available 24x7. Availability can be achieved via replication and careful design to cope with failures of hardware, software, or the network Security: This refers to the ability to cope with malicious attacks from outside or inside of the system. Security can be improved by installing firewalls and establishing authentication and authorization processes, and using SSL and encryption.  Performance: This refers to increasing efficiencies such as response time, throughput and generally resource utilization, which most of the time conflict with each other. Usability: This refers to the level of “satisfaction” from a human perspective in using the system. Usability includes completeness, correctness, compatibility, and more critically user friendliness.  Business attributes Time to market: This refers to the time it takes from requirement analysis to the date product is released. Cost: This refers to expense of building, maintaining, and operating the system. Lifetime: This refers to the period of time that the product is “alive” before retirement.  Tradeoff between space and time. For example, to increase the time efficiency of a hash table means to decrease its space efficiency. Tradeoff between reliability and performance. For instance, Java programs are well protected against buffer overflow due to its security measures such as boundary check on arrays. Such reliability features come at the cost of time efficiency, compared with the simpler and faster C language which provides the “dangerous” yet efficient pointers.  Tradeoff between scalability and performance. For example, one typical approach to increase the scalability of a service is to replicate servers. To ensure consistency of all servers (e.g., to make sure that each server has the same logically consistent data), performance of the whole service is sacrificed.  Software Architecture Design Guidelines Think of what to do before thinking of how to do it. Functional and non-functional requirements should be identified, verified, and validated before architectural and detailed design. Using an abstract architectural design of a system to communicate with stakeholders helps avoid overhauling the system design in later stages of the software development cycle.  Think of abstract design before thinking of concrete design. Always start with an abstract design that specifies interfaces of components and abstract data types. Use multiple levels of abstraction if necessary. Make all implementation decisions depend on the abstract interfaces instead of concrete ones because those are more stable – they are the contracts between service providers and services requesters so they are defined at the early stages of software development cycle.  Think of non-functional requirements earlier. When we map functional requirements to an architectural design, we should consider non- functional requirements as well. Communicate with stakeholders and document their preferences of quality attributes. It is not possible to find a design that meets all quality attributes. Balance the quality attributes, and consider heterogeneous architecture styles when necessary.  Think of software reusability and extensibility as much as possible. For most software systems, it is very likely that new functionalities will be added after they are deployed. In addition, we need to consider how to reuse existing software components to increase the reliability and cost-effectiveness of new systems. Always try hard to make software extensible in the future.  Tolerate refinement of design. Never expect to have software design completely perfect within one step. We may need to use prototyping and iteration to refine the software design. Avoid ambiguous design and over-detailed design. Ambiguous design lacks constraints and over- detailed design restricts implementation.  Summary Software architectural design has emerged as an important part of software development. A software architecture specification consists of software elements, connections and collaborations among the elements, and desired software quality attributes.  An architectural style is a set of rules, constraints, or patterns that guide how to structure a system into a set of elements and connectors, and how to govern overall structure design patterns of constituent element types and their runtime interaction. One specific architectural style may not be able to honor all quality attributes of the system.  There are always quality attribute tradeoffs between different styles. Hence how to keep a balance on quality attributes is an important design issue.