Software Architectural Views

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