Architectural Descriptions

1. Architectural Descriptions Lecture 6

2. References • Chapter 12: Architectural Description Languages from Software Architectures in Practice. • IEEE Recommended Practice for Architectural Description of Software Intensive Systems. • Architectural Blueprints-The 4+1 View Model of Software Architecture by Philippe Kruchten. Available from www.rational.com/media/whitepapers/Pbk4p1.pdf

3. Classical Architectural Descriptions • Largely represented by box and line drawings. • Nature of components, their properties, semantics of connections and overall behavior of the systems is reflected poorly. • Offer an intuitive view of system’s constructions but fail to identify, • Components, their behavior and their associations with other components. • Differentiation between runtime and compile time abstractions. • Nature of connections.

4. Architectural Description Languages (ADLs) • A linguistic approach to formal representation of architectures. • Address the shortcomings of informal representations. • Sophisticated ADLs allow for early analysis and feasibility testing of architectural design decisions.

5. Advantages of ADL • Architectures allow • Mutual Communication. • Embodiment of early design decisions suitable for analysis. • Transferable abstractions of a system. • These issues are better served if a standard notation for describing and representing architectures exists.

6. Advantages of ADL (Contd…) • Standardized and formal architectural description languages allow: • Enhanced communication between architect and other stakeholders. • Analysis of early design decisions. • Enable tools to be built to assist in development. • Construction of artifacts that are transferable to subsequent systems.

7. What are ADLs • ADLs differ from requirement languages because ADLs describe solution space. • ADLs differ from programming languages as latter bind all architectural abstractions to specific point solutions. • ADLs differ from modeling languages as latter are more concerned with the behavior of the whole rather than of the parts. • ADLs provide abstractions, structures and analysis capabilities that are clearly architectural in nature.

8. Minimal Requirements for ADL • Suitability to communicate architecture to all stake holders. • Support for representation of static and dynamic structures. • Support for representation of components and connectors. • Support for creation, refinement and validation of architecture. This should include mechanisms to test completeness and consistency of the architecture.

9. Minimal Requirements for ADL (Contd…) • Support for the representation of most common architectural styles. • Support for structures that express architectural information while suppressing implementation or non-architectural information. • Support for further development by adding information to ADL specification to enable the final system specification to be derived from ADL.

10. Minimal Requirements for ADL (Contd…) • If the language can express implementation level information it must contain capabilities for matching more than one implementation to the architectural level structures of the system. • Support for either an analytical capability based on architectural level information or a capability for quickly generating prototype implementations.

11. Using the Object Oriented Notation for Architectural Description • Advantages: • Familiarity to developers. • Close mapping to implementation. • Commercial tool support. • Considerations in using an object oriented notation for an architectural notation. • A graphical language for visualizing, constructing,specifying and documenting the artifacts of a software intensive system. • Support for multiple structural and behavioral views of the system.

12. Using the Object Oriented Notation for Architectural Description (Contd…) • Considerations in using an object oriented notation for an architectural notation (Contd…) • Support for stylistic constraints. • Support for connectors and interfaces as first class entities. • Support for hierarchical structures.

13. IEEE-1471 • IEEE Recommended Practice for Architectural Description of Software Intensive Systems. • Scope of the recommendation includes architectural descriptions allowing • Expression of the system and its evolution. • Communication among stake holders. • Evaluation and comparison of architectures in a consistent manner. • Planning, managing and executing the activities of system development.

14. IEEE- 1471 (Contd…) • Scope of the recommendation includes architectural descriptions allowing (Contd…), • Expression of the persistent characteristics and supporting principles of a system to guide acceptable change. • Verification of a system implementation’s compliance with an architectural description. • Recording contributions to the body of knowledge of software intensive systems architecture.

15. Architectural Description as Specified in IEEE-1471 • Every system has an architecture. • An architecture can be recorded by an architectural description. • Architecture of a system is a conceptual entity distinguished from particular descriptions of that architecture. • Architectural descriptions are considered concrete products or artifacts.

16. Architectural Description as specified in IEEE-1471 (Contd…) • An architectural description is organized into one or more constituents called views. • Each view addresses one or more of the concerns of system stakeholders. • View is used to refer to the expression of a system’s architecture with respect to a particular viewpoint.

17. Architectural Description as specified in IEEE-1471 (Contd…) • A viewpoint establishes the conventions by which a view is created, depicted and analyzed, • A view conforms to a viewpoint. • The viewpoint determines the languages (including notations models, or product types ) to be used to describe a view. • Any associated modeling method or analysis technique to be applied to these representations of the view.

18. Architectural Description as specified in IEEE-1471 (Contd…) • An architectural description selects one or more viewpoints for use. • A viewpoint defined else where is referred to as library viewpoint. • A view may consist of one or more architectural models. • Each architectural model is developed using the methods established by its associated architectural viewpoints. • An architectural model may participate in more than one view.

20. 4+1 View Model of Software Architecture • Description of a software architecture using several concurrent views each addressing one specific set of concerns. • Architectures made up of five main view • Logical view: Describes the object model of system. • Process view: Describes the concurrency and synchronization aspects of the system. • Physical view: Describes the mapping(s) of the software onto the hardware and reflects its distributed aspects. • Development view: Describes the static organisation of the software in its development environment. • Scenarios: Functionality illustrated by selected use-cases.

21. The 4+1 View Model End-user Functionality Programmers Software Management Logical View Development View Scenarios Process View Physical View Integrators Performance Scalability System Engineers Topology Communications

22. The 4+1 View Model(Contd.) • Perry & Wolfe’s equation applied independently on each view, • Software Architecture = {Elements, Forms, Rationale/Constraints} • For each view, a set of elements are to be defined. • Forms and patterns are described.

23. The 4+1 View Model(Contd.) • Rationale and constraints connecting an architecture to requirements are captured. • Each view is described by a blueprint in its own particular notation. • For each view, architects can pick a certain architectural style, allowing the coexistence of multiple styles in one system.

24. The Logical Architecture • Primarily supports the functional requirements. • The system is decomposed into a set of key abstractions taken mostly from the problem domain. • The abstractions as recorded in the form of objects and object classes.

25. The Logical Architecture(Contd.) • Key relationships between abstractions are highlighted, i.e., • Encapsulation, • Abstraction, • Inheritance. • Main guideline • Maintenance of a single coherent object model across the whole system. • Avoidance of premature specialisation of classes and mechanisms per site or per processor.

26. The Process Architecture • Takes into account non-functional requirements, e.g., performance, availability. • Addresses issues of • Concurrency and distribution, • System’s integrity, • Fault tolerance, • Manner in which main abstractions of logical view fit within the process architecture. • Typical styles for the process view • Pipe and filter, • Client server.

27. The Development Architecture • Focuses on the actual software module organisation on the software development environment. • The software is packaged into manageable chunks, e.g., program libraries or subsystems, that can be developed by one or a small number of developers. • A layered style is used for the development model. • RULE: Not to allow layer bridging to maintain simplicity.

28. The Physical Architecture • Focuses on non-functional requirements, e.g., • Availability, • Reliability or fault tolerance, • Performance or throughput, • Scalability. • Software executes on a network of computers or processing nodes. • Various elements identified earlier, i.e., objects, processes, etc., are to be mapped onto the various nodes.

29. Scenarios • Scenarios show the elements of the other four views to work together seamlessly. • Scenarios are abstractions of most important requirements. • Design of scenarios is expressed using the object scenario diagrams and object interaction diagrams. • The view is redundant with other views for • Discovering architectural elements, • Validation, illustration and demonstration.