Software Architecture PDF

DR. KHUBAIB AMJAD ALAM FAST-NU 1 Agenda – What will you Learn Today? What is Software Architecture? Architecture Attributes Software Architecture What is Software Architecture? The Software Architecture of a system consists of a description of the system elements,...

DR. KHUBAIB AMJAD ALAM FAST-NU 1 Agenda – What will you Learn Today? What is Software Architecture? Architecture Attributes Software Architecture What is Software Architecture? The Software Architecture of a system consists of a description of the system elements, interactions between the system elements, patterns that guide the system elements and constraints on the relationships between system elements. [Shaw and Garlan] Carnegie Mellon University What is Software Architecture? A neat-looking drawing of some boxes, circles, and lines, laid out nicely in Powerpoint or Word, does not constitute an architecture. — D’Souza & Wills ESE — SOFTWARE ARCHITECTURE What is Software Architecture? The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. [SEI] What is Software Architecture? Architectural design: The process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system. [IEEE Glossary] Architectural design Architectural design is the first stage in the software design process. It is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them. The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components In agile processes, it is generally accepted that an early stage of the development process should be concerned with establishing an overall system architecture. Incremental development of architectures is not usually successful. While refactoring components in response to changes is usually relatively easy, refactoring a system architecture is likely to be expensive. The architecture of a packing robot control system You can design software architectures at two levels of abstraction: architecture in the small : architecture of individual programs. Concerned with the way that an individual program is decomposed into components. architecture in the large: Concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers, which may be owned and managed by different companies. Why software architecture is important Software architecture is important because it affects the performance, robustness, distributability, and maintainability of a system (Bosch, 2000). Sub-systems, Modules and Components A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems. A module is a system component that provides services to other components but would not normally be considered as a separate system. A component is an independently deliverable unit of software that encapsulates its design and implementation and offers interfaces to the out-side, by which it may be composed with other components to form a larger whole. © Oscar Nierstrasz ESE — SOFTWARE ARCHITECTURE ESE 10.13  Importance of Architecture ▪ Communication between stakeholders ▪ A high-level presentation of the system ▪ Use for understanding, negotiation and communication ▪ Early design decisions ▪ Profound effect on the systems quality attributes, e.g. performance, availability, maintainability etc. ▪ Large-scale reuse ▪ If similar system have common requirements, modules can be identified and reused Architecture Attributes System attributes and (associated) architectural styles / structures Performance – localize operations by using fewer, large-grain components to minimize sub-system communication. (reflected in repository model) Security – use a layered architecture with critical assets in inner layers. (reflected in abstract machine model)  System attributes and (associated) architectural styles / structures Safety – isolate safety-critical compo-nents in one or just a few sub- systems. Availability – include redundant components in the architecture. Maintainability – use (more) fine-grain, self-contained components. (reflected in objected-oriented model)  Performance Localize the operations to minimize subsystem communication Scale up … Scale out …  Security Use a layered architecture with critical assets in inner layers Confidentiality ▪ Only authorized users can read the information ▪ E.g. Military Availability Integrity ▪ Only authorized users can modify, edit or ▪ Right information is available at the right time delete data. ▪ Important for everyone ▪ E.g. bank systems  Safety Isolate safe-critical components The Whole System Critical Design so that all safety critical operations are located in one or few modules / subsystems.  Availability Include redundant components in the architecture  Maintainability Use fine-grain, self-contained components  “Architectural design” process ▪System structuring – the system is decomposed into major sub-systems and commun-ication (e.g., data sharing) mechanisms are identified. ▪The architectural design is normally expressed as a block diagram presenting an overview of the system structure ▪More specific models showing how sub-systems share data, are distributed and interface with each other may also be developed Modular decomposition – the identified sub-systems are decomposed into lower-level modules (components, objects, etc.). Control modelling – a model of the control relationships between the sub-systems is established. you make decisions about how the execution of components is controlled. Unified Modeling Language UML for Software Architecture The Unified Modeling Language (UML) is a graphical language for ▪visualizing (pictorially connected components ) ▪specifying, ▪constructing, and ▪documenting the artifacts of a software-intensive system. UML offers a standard way to draw a system's blueprints. Same notation for every project Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view that can present all aspects of complex software to stakeholders!!!  View Model View models provide partial representations of the software architecture to specific stakeholders such as the system users, the analyst/designer, the developer/programmer, the system integrator, and the system engineer. View Model Software designers can organize the description of their architecture decisions in different views. Krutchen’s 4+1 View Model The 4 +1 View Model ▪ The 4+1 view model was originally introduced by Philippe Kruchten (Kruchten, 1995). ▪ The model provides four essential views: o the logical view, o the process view, o the physical view, and o the development view ▪ and fifth is the scenario view The 4+1 view model Multiple-view model that addresses different aspects and concerns of the system. Standardizes the software design documents and makes the design easy to understand by all stakeholders. The “4+1” Views of Architecture The Scenario View ▪ The scenario view describes the functionality of the system, i.e., how the user employs the system and how the system provides services to the users. ▪ It helps designers to discover architecture elements during the design process and to validate the architecture design afterward. ▪ The UML use case diagram and other verbal documents The Logical or Conceptual View The logical view is based on application domain entities necessary to implement the functional requirements. The logical view specifies system decomposition into conceptual entities (such as objects) and connections between them (such as associations). ▪ The logical view is typically supported by The logical view ▪ UML static diagrams including class diagrams and domain model. ▪ UML dynamic diagrams such as the interaction overall diagram, sequence diagram, communication diagram, state diagram, and activity diagram. Date Class Time class  The Development or Module View ▪ The development view derives from the logical view and describes the static organization of the system modules. ▪ Modules such as namespaces, class library, subsystem, or packages are building blocks that group classes for further development and implementation. ▪ UML diagrams such as package diagrams and component diagrams are often used to support this view. ▪ A package diagram is a UML diagram composed only of packages and the dependencies between them. A package is a UML construct that enables you to organize model elements, such as use cases or classes, into groups. ▪ Component diagram does not describe the functionality of the system but it describes the components used to make those functionalities. Show static behavior The Process View ▪ The process view focuses on the dynamic aspects of the system, i.e., its execution time behavior. ▪ This view maps functions, activities, and interactions onto runtime implementation. ▪ The process view takes care of the concurrency and synchronization issues between subsystems. ▪ The UML activity diagram and interaction overview diagram support this view. The Physical View ▪ The physical view describes installation, configuration, and deployment of the software application. ▪ It concerns itself with how to deliver the deploy-able system. ▪ The physical view shows the mapping of software onto hardware. ▪ It is particularly of interest in distributed or parallel systems. ▪ The UML deployment diagrams and other documentation are often used to support this view. The User Interface View ▪ The User Interface (UI) view is an extended view that provides a clear user- computer interface view and hides implementation details. ▪ This view may be provided as a series of screen snapshots or a dynamic, interactive prototype demo. ▪ Any modification on this view will have direct impact on the scenarios view. Architectural Styles  Architectural Styles ▪ The architectural model of a system may conform to a generic architectural model or style ▪ An awareness of these styles can simplify the problem of defining system architectures  Architectural Styles (cont.) ▪ Each style describes a system category that encompasses: 1) A set of components (e.g. database, computational modules) that perform a function required by a system 2) A set of connectors that enable “communication, coordination and cooperation” among components 3) Constraints that define how components can be integrated to form the system  Recap What is Software Architecture? Architecture Attributes