1 / 20

Software Architectural Views

Software Architectural Views. By the end of this lecture, you will be able to: list and describe the views in the 4+1 view model of software architecture describe how and why the views are needed to document architecture

Download Presentation

Software Architectural Views

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. Software Architectural Views • By the end of this lecture, you will be able to: • list and describe the views in the 4+1 view model of software architecture • describe how and why the views are needed to document architecture • discuss the relationship of architectural design to related stages of the software life-cycle You will get your midterms back on Tuesday

  2. Where are we? • Set-up for architecture discussion: Design principles & “low-level” design • What software architecture is and different styles that can be used to help create an architecture for a system with particular properties • Today • How do you write an architecture down?

  3. Capturing an architecture • Lots of different suggestions • 4+1 views • 5 in Hofmeister • IEEE 1471-2000 recommended practice for architectural description • Commonality is that each approach involves multiple views that together describe the architecture • Each view is a project of a model • (Terminology of view and model can be confusing)

  4. Why multiple views? • Recall that there are many stakeholders interested in a system’s architecture • Can you name some kinds of stakeholders? • Different stakeholders have different concerns • We can’t capture the information for all stakeholders in one view

  5. 4+1 view model of architecture • Diagram from paper • The 4 views (logical, process, implementation and deployment) describe the solution space • The +1 view describes the problem space

  6. Use case view (+1 view) • Interested stakeholders tend to be developers and eventual users • Questions of interest include: • What is the business environment in which the system will operate? • What are the business objects and events of interest? (Domain model)

  7. Representing the use case view • Use case diagrams (structural) • Use case textual descriptions (behavioural) • Use case activity diagrams (behavioural) • Use case interaction diagrams (behavioural) • We’ll look at examples of each kind of view on the overhead (reference the reading for today after class)

  8. Purpose of use case view • (You’ll see it helps) Bind the other views together • Helps explain what the system is to do and the rationale behind the architecture (implicitly) • Helps drive the design of the architecture • i.e., helps in the selection of the architectural elements

  9. Since the reading was published • As part of the use case view, a developer would typically also consider a domain model and the non-functional requirements • What are some examples of non-functional requirements?

  10. Logical view (1 of 4 views) • Interested stakeholders include customer, developers, and development managers • Questions of interest include: • What are the logical elements of the system and how do they interact? • What is the function of each element? • Does the logical architecture support good design principles?

  11. Representing the logical view • Package diagrams (to show structural partitions) • Class diagrams (to show elements of architectural interest) • Interaction diagrams (for behaviour) • Statechart diagrams (for behaviour)

  12. Process view (2 of 4 views) • Interested stakeholders include developers, customer, and eventual system operators • Questions of interest include: • What are the runnable elements (e.g., processes, active objects, etc.) of the system? • What is the composition of the runnable elements? • How do the runnable elements communicate? • What runs concurrently?

  13. Representing the process view • Class diagrams showing which classes are processes and which are threaded, and which communicate over IPC (inter-process communication) • Object diagrams showing what happens (structurally) at run-time • Interaction diagrams and activity diagrams to show behaviour

  14. Implementation view (3 of 4 views) • Interested stakeholders include developers, development managers, customers, field support that must configure the system, eventual system operators • Questions of interest include: • What are the actual run-time elements of the system? • What implementation technology was used for each element? • How do the elements depend upon each other at run-time and system construction time?

  15. Representing the implementation view • Component diagrams • Showing deployment elements (parts needed to deliver a running system), work products (parts used to create the deployment elements), and execution components (parts created and destroyed as system runs) • Showing dependencies between all of these different entities

  16. Deployment view (4 of 4 views) • Interested stakeholders include customers, users, designers, and system operations personnel • Questions of interest: • What hardware is needed to run the system? • How will the hardware be interconnected? • What will the hardware cost? • What will be the performance, availability, reliability, etc. of the system?

  17. Representing the deployment view • Deployment diagram (structure)

  18. Mapping between views • Need to understand the correspondence (mapping) between views • Diagram below is a subset of all the mappings Every line is adifferentmapping Use case view Logical view Process view Implementation view Deployment view

  19. An example of view correspondence • Logical to Process • Objects to Tasks/Processes • Krutchen suggests two strategies: • Inside-Out: Starting from the logical determine which objects can share a thread of control within an agent • Outside-In: Starting from the physical architecture, define client processes to handle external stimuli and servers to provide services

  20. Architecture: What is it really? • True or false? • Architecture is the same as design • Architecture considers more than just the structural aspects of the system • Architecture is flakey and can’t be validated • There is a defined process for selecting and enacting an architecture for a system based on the requirements of the system

More Related