Architectural Blueprints – The “4+1” view Model of Software Architecture

1. Architectural Blueprints – The “4+1” view Model of Software Architecture Based on the paper by Philippe Kruchten from Rational Software

2. Complexity Management via Views • Modeling software architectures is best done using multiple concurrent views • This approach is consistent with the “Views and Beyond” approach outlined by the SEI for documenting software architectures • Individual views divide thecomplexity, and create artifactsthat separately address the concernsof different stakeholders

3. Lines and Boxes • Software architecture and design documentation is often modeled using box and line diagrams • Modelers often struggle with: • What do the lines and boxes represent? • Do the lines and boxes represent the same abstractions from one model to another? • Do models developed by more than one individual have the same meaning for the lines and boxes? • Is the goal of the model clear - are the lines network messages, procedure calls, or structural relationships? – are the boxes functions, classes, components, servers, etc.

4. Requirements for Modeling SW Architectures • Use multiple views, each view addressing one specific set of concerns • Organize the views into categories, with each category being specifically targeted to be used by a different constituency • Use consistent notation for the individual views

5. The 4+1 View Model Architects Developers • Each view is consumed by a different stakeholder Logical View Development View Scenarios BusinessAnalysts Process View Physical View Integrators InfrastructureEngineers

6. The Architecture Widgets The “Widgets” of Architecture • Each view is expressed using a set of elements and connectors • Each view can be guided by using patterns or architectural styles to introduce constraints on downstream design artifacts • Each view is developed taking the appropriate set of requirements into mind • Each view might use different notation that is most appropriate for the view Connector Interface Component A Component B Connector

7. The Logical View Logical View • This view expresses the key abstractions from the problem domain • Classes, Components • Think in terms of the services that the system will provide to the user • Express the relationships between the logical components • Use, generalize, aggregate • Define the important interfaces of the components and connectors associated with this view

8. The Logical View Logical View • Choose a “style” for the logical view • Object-oriented style • Component style • Service-oriented style • The style helps define the structure and semantics of the elements captured in the logical view

9. The Process View Process View • The process view takes into account non-functional requirements such as performance, availability • This view also deals with concurrency, showing the different threads of control • Intra-process threads • Inter-process coordination (messages to and from different servers)

10. The Process View Process View • A “process” in the process view groups tasks into logical execution units. Execution units have a: • Well defined point where they start and stop as well as rule for dealing with exceptions to the normal course of operation • Possible styles for the process views: • Client/Server, MVC, pipe and filter.

11. The Process View Process View • Components for the process view include: • Processes and threads • Connectors include • Messages, shared memory, pipes

12. The Development View DevelopmentView • The development view defines the actual software modules to be constructed • The granularity of the components in this view should be at the level where they can be implemented by one or a small set of developers • Classes, Packages, Subsystems • This view should clearly define the import and output relations • We will hear more about this later when we talk about provided and required interfaces…

13. The Development View DevelopmentView • Connectors for the development view may include: • Function/procedure calls, inheritance, includes, uses, etc. • Styles for the development view include the layer style • Subsystems, components, modules/classes, functions/procedures

14. The Physical View PhysicalView • The physical view maps the software components to the hardware (deployment) • Elements include networks, processes, and tasks; Connectors include network links and interprocess communication • Different physical views might be needed for development, test and production • A good design promotes the flexibility to map the software components to different physical configurations for different phases of the software development lifecycle

15. The +1 View - Scenarios Scenarios • Scenarios are abstractions of the most important requirements • Map closely to use cases • Ties the other views together • The scenario view is redundant to the other views (+1) but is a cross-cutting aspect tying the architecture together

16. The +1 View - Scenarios Scenarios • Why scenarios: • A mechanism to discover the key architectural elements and connectors • Validation of the architecture design after the other views are created • Addresses the concerns of both the functional and non-functional requirements

17. From the mid-90’s to current thinking… Then Now

18. What’s Different Now? • The logical view and development view are combined into the structural view • The structural view combines both the abstract logical view and the more detailed development view

19. What’s Different Now? • The process view has been incorporated into the behavioral view. • The process view only defines units of execution where the behavioral view includes these plus important behavioral interactions between the architectural elements

20. What’s Different Now? • The packaging view is new, as newer component oriented languages allow grouping of structural elements into components • Examples: COM, CORBA, Java Beans, EJB, Services • The packaging of the components, their interfaces and metadata are very important design artifacts • The infrastructure view in the new maps closely with the physical view in the older model

21. What’s Different Now? • The Scenario view in the old model, which was reflective of the requirements now includes a logical rendering of the requirements (typically rendered as use-cases), as well as definition of test cases needed to verify the software product

22. The “newer” 4+1 model and SOA Structural Packaging/Implementation Classes and Componentsthat physically representthe service Service interface (schema) and usage semantics, perhaps WSDL. Includes service policy definitions and metadata Requirements, Test/Validation Criteria Service Contract(s) Behavioral Infrastructure/Environment Workflows showing how the service fulfils a logical business-unit-of-work (BUOW). Also includes intra-service behavioral models Deployment on .Net and/or J2EE – emphasis on reliability,availability and security.