Architectural Blueprints The 41 view Model of Software

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

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) http: //serg. cs. drexel. edu 2

Lines and Boxes Software architecture and design documentation is often modeled using box and line diagrams Modelers often struggle with: n n 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) http: //serg. cs. drexel. edu 3

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) http: //serg. cs. drexel. edu 4

The 4+1 View Model Architects Logical View Developers Development View Scenarios Process View Business Analysts Physical View Integrators Infrastructure Engineers Each view is consumed by a different stakeholder © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 5

The Architecture Widgets The “Widgets” of Architecture Component A Connector Interface Connector Component B 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 © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 6

The Logical View This view expresses the key abstractions from the problem domain n Classes, Components Think in terms of the services that the system will provide to the user Express the relationships between the logical components n Use, generalize, aggregate Define the important interfaces of the components and connectors associated with this view © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 7

The Logical View Choose a “style” for the logical view n n n Object-oriented style Component style Service-oriented style The style helps define the structure and semantics of the elements captured in the logical view © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 8

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 n n Intra-process threads Inter-process coordination (messages to and from different servers) © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 9

The Process View A “process” in the process view groups tasks into logical execution units. Execution units have a: n 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: n Client/Server, MVC, pipe and filter. © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 10

The Process View Components for the process view include: n Processes and threads Connectors include n Messages, shared memory, pipes © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 11

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 n Classes, Packages, Subsystems This view should clearly define the import and output relations n We will hear more about this later when we talk about provided and required interfaces… © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 12

The Development View Connectors for the development view may include: n Function/procedure calls, inheritance, includes, uses, etc. Styles for the development view include the layer style n Subsystems, components, modules/classes, functions/procedures © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 13

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 © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 14

The +1 View - 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 © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 15

The +1 View - Scenarios Why scenarios: n n n 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 © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 16

From the mid-90’s to current thinking… Then Now © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 17

What’s Different Now? The logical view and development view are combined into the structural view n The structural view combines both the abstract logical view and the more detailed development view © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 18

What’s Different Now? The process view has been incorporated into the behavioral view. n 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) http: //serg. cs. drexel. edu 19

What’s Different Now? The packaging view is new, as newer component oriented languages allow grouping of structural elements into components n n 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) http: //serg. cs. drexel. edu 20

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) http: //serg. cs. drexel. edu 21

The “newer” 4+1 model and SOA Structural Packaging/Implementation Classes and Components that physically represent the service Service interface (schema) and usage semantics, perhaps WSDL. Includes service policy definitions Requirements, Test/ and metadata Validation Criteria Behavioral Service Contract(s) Workflows showing how the service fulfils a logical business-unit-ofwork (BUOW). Also includes intraservice behavioral models Infrastructure/ Environment Deployment on. Net and/or J 2 EE – emphasis on reliability, availability and security. © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 22