1 / 22

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

Architectural Blueprints – The “4+1” view Model of Software Architecture. Based on the paper by Philippe Kruchten from Rational Software. Complexity Management via Views. Modeling software architectures is best done using multiple concurrent views

jodie
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related