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 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 Use case view Logical view Process view Implementation view Deployment view Every line is a different mapping

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