© Drexel University Software Engineering Research Group (SERG) 1 Based on the paper by Philippe Kruchten from Rational Software Architectural Blueprints – The “4+1” view Model of Software Architecture

© Drexel University Software Engineering Research Group (SERG) 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 the complexity, and create artifacts that separately address the concerns of different stakeholders

© Drexel University Software Engineering Research Group (SERG) 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.

© Drexel University Software Engineering Research Group (SERG) 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

© Drexel University Software Engineering Research Group (SERG) 5 The 4+1 View Model Each view is consumed by a different stakeholder Logical View Development View Process ViewPhysical View Scenarios ArchitectsDevelopers IntegratorsInfrastructure Engineers Business Analysts

© Drexel University Software Engineering Research Group (SERG) 6 The Architecture Widgets 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 The “Widgets” of Architecture Component AComponent B Connector Interface Connector

© Drexel University Software Engineering Research Group (SERG) 7 The 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 Logical View

© Drexel University Software Engineering Research Group (SERG) 8 The 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 Logical View

© Drexel University Software Engineering Research Group (SERG) 9 The 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) Process View

© Drexel University Software Engineering Research Group (SERG) 10 The 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. Process View

© Drexel University Software Engineering Research Group (SERG) 11 The Process View Components for the process view include: Processes and threads Connectors include Messages, shared memory, pipes Process View

© Drexel University Software Engineering Research Group (SERG) 12 The Development View 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… Development View

© Drexel University Software Engineering Research Group (SERG) 13 The Development View 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 Development View

© Drexel University Software Engineering Research Group (SERG) 14 The Physical View 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 Physical View

© Drexel University Software Engineering Research Group (SERG) 15 The +1 View - 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 Scenarios

© Drexel University Software Engineering Research Group (SERG) 16 The +1 View - 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 Scenarios

© Drexel University Software Engineering Research Group (SERG) 17 From the mid-90’s to current thinking… Then Now

© Drexel University Software Engineering Research Group (SERG) 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

© Drexel University Software Engineering Research Group (SERG) 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

© Drexel University Software Engineering Research Group (SERG) 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

© Drexel University Software Engineering Research Group (SERG) 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

© Drexel University Software Engineering Research Group (SERG) 22 The “newer” 4+1 model and SOA StructuralPackaging/Implementation BehavioralInfrastructure/ Environment Requirements, Test/ Validation Criteria Service Contract(s) Classes and Components that physically represent the service Workflows showing how the service fulfils a logical business-unit-of- work (BUOW). Also includes intra- service behavioral models Service interface (schema) and usage semantics, perhaps WSDL. Includes service policy definitions and metadata Deployment on.Net and/or J2EE – emphasis on reliability, availability and security.