1. SOEN 6011 Software Engineering Processes
Section SS Fall 2007
Dr Greg Butler

2. Week 11
Software Architecture
4+1 Views
Siemen’s Approach

3. Software Architecture: Definitions
… for a system is the structure … which consist of elements, their externally visible properties, and the relationships among them.
The fundamental organization of a system [as] embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (IEEE ).
Definitions from Clements et. al.
“… or structures of the system, …”
Documentation includes rational.

4. Architecture: Benefits?
Contributes to elicitation of requirements.
First design: can already assess / determine
satisfaction of requirements.
Work allocation / distribution (schedule).
Instructional: useful to learn about system.
Initial development & maintenance.
Reuse of the architectural style / framework.
Also …
Architectural design activity:
Architecture / Architecture documentation

5. Conceptual Integrity …
… is central to achieving product quality.
Also called Architectural Integrity.
Coherent conceptual (design) model makes product easier to understand, hence easier to …
Develop (e.g. Design, test),
Learn to use: customer, I&C, sales & marketing
Maintain.
How to achieve conceptual integrity? …
Central argument: Conceptual integrity (unity) of the product is paramount.
[… or developing a test suite offering optimal / appropriate coverage.]

6. System Architect Custodian of product ensures Design coherence.
Also, to some extent, Interface coherence (esp. UI).
Architect:
However a straightforward approach to conceptual integrity is often impractical for industry. E.g.
Market pressures
Complexity of the product.

7. System Architect Full-time job!
Separation of architecture from implementation.
Project size  hierarchy of architects.
“Single mind”
Having a system architect is an effective means of achieving conceptual integrity.
Architect:
However a straightforward approach to conceptual integrity is often impractical for industry. E.g.
Market pressures
Complexity of the product.

8. Components S/W entities … Physical
Systems (e.g. COTS), subsystems, frameworks, packages, layers, libraries, modules, classes, objects, executables, DLLs, plug-ins, …
Processes, tasks.
Physical
Network elements.
Processing elements.
Databases.

9. Interrelationships Static: Dynamic:
Interface dependencies: e.g. uses/import.
Containment, inheritance, subtype, …
Data dependencies (database applications). …
Dynamic:
Thread of control.
Dataflow.

10. Documentation: Putting it all together
How best to capture all of these different kinds of components and their interrelationships?
Consider …

11. View Based Documentation of Architectures
Architecture Document =
View A +
View B +
View C + …
View X +
“Beyond Views”

12. “4+1” View Model of Architecture
By Philippe Kruchten [Kruchten95] (URL to paper given on web site.)
Rational Unified Process.

13. “4+1” View Model
Implementation/
Deployment/

14. References Kruchten95, becoming a bit dated. RUP documentation
Available in lab.
Also includes samples.
To access RUP from lab machines
Launch the Rational Unified Process.
From the Overview page …
Select Analysis and Design
At the top of this page select “Artifacts”
Select “Software Architecture Documents”
You will see links to the examples … . Note that I do not consider the examples complete.

15. “4+1” VM (Alternate names)
Excerpt from Kruchten95.
Shows
alternate names for the two right views.
Kruchten’s suggested main stakeholders for each view.

16. “5+1” View Model = 4 + 1 + data view.
Other combinations of views are possible.

17. “4+1”: Let us look at each view
Implementation/
Deployment/

18. Use Case View
Main goal: present architecturally significant use cases either:
Duplicated from req. doc. 
Named and reference given to req. doc. 
These use cases are to help highlight main
Architectural decisions / choices

19. Logical View: Main Goals
Convey …
Overall structure and
Interfaces to the environment, in a manner that is
conceptually as simple as possible
Challenge: find right level of detail.
Class diagrams: which can show more than just classes, of course.
Rational Rose like structure diagrams.

20. Logical View & Requirements
Main focus: functional.
It should be possible to assess (up to a certain level of detail) whether requirements will be satisfied by the proposed architectural design.

21. Logical View: Components & …
active classes, classes,
modules,
packages,
subsystems, …
Connectors (interrelationships):
Usage.
Containment, aggregation.
Inheritance, instantiation.

22. Logical View: How Presented?
Mainly UML “class” diagrams, including
Package diagrams.
Component structure (UML2)
Explanatory text, including design rational
Class diagrams: which can show more than just classes, of course.
Rational Rose like structure diagrams.

23. Logical View, Example
You have seen many examples of class and package diagrams.
UML 2 component diagrams you have seen as well …

24. Logical View (e.g. Kruchten)

25. Process View Components: processes, tasks, … Interrelationships:
group of tasks : single exec. unit.
Control: start, shutdown, recover, restore
Primary / secondary (redundancy)
Interrelationships:
Communication
Allocation of
Logical view components to processes/tasks.
Synchronization mechanisms

26. Process View – e.g. (Kruchten)

27. Logical View Components
Process View – ex.

28. Implementation (Development)View
Actual S/W organization.
Components:
Libraries, subsystems, exec., object files, …
Most common top-level arch. style: layers
Connectors: containment, dependencies, …
Allocate logical components to impl. comp.
Reuse:
Off-the-shelf.
“To-the-shelf”: sharing with other projects.

29. Implementation View – illustration

30. Deployment (Physical) View
Components: processors, processing nodes, …
Network topology.
Usually several topo’s are supported.
S/W should be relatively independent of topo.
Allocation of process view elements to H/W (processing nodes).
Examples:
Network elt: Process mapping into application cards.
Network Mgmt: one or more NOCs.
What are the components and their interrel.?

31. Deployment View - illustration

32. Deployment View - illustration

33. Siemens Four View Model
Reference:
Applied Software Architecture by C. Hofmeister, R. Nord and D. Soni.

34. Siemens Four View Model: Overview
S/W Architecture
Here are the four views and their interrelationships. Arrows indicate how one view influences or contributes input to another view. Bold arrow heads are direction of main dependency.
Other notes:
H/W arch and Source Code are separate from the S/W arch.

35. Comparing the View Models
4+1
Logical
Implementation (Development)
Process
Deployment (Physical)
(Use Case)
S4VM
Conceptual
Module
Execution
Code
There is no one-to-one mapping.

36. S4VM: in more detail. Notice activity groups in each view are the same …
S4VM Overview

37. S4VM Activities Groups in each view
For each view perform
Global analysis
(Mostly the same for each view.)
Central design tasks.
(Specific to each view.)
Final design tasks.

38. Overview

39. Global Analysis: Purpose
To identify issues (early) so that strategies can be proposed to resolve them.
(Architectural) Factors can be seen merely as a means of organizing (group) issues.

40. Global Analysis Activities: Analyze Factors. Identify Issues.
Develop Strategies.

41. 1. Analyze Factors - purpose
Identify and describe factors that can influence the system architecture.
Document the factors.

42. 1. Analyze Factors Use given factor categorization / list to kickoff.
For each factor consider:
How it relates to the project.
Flexibility and changeability.
Impact.

43. Factor Categorization (e.g. SFVM)
Organizational
Technological
Product

44. Organizational Factors
Top-level grouping of factors:
O1: Management
O2: Staff skills, interests, strengths, weaknesses.
O3: Process and development environment.
O4: Development schedule.
O5: Development budget.

45. O1: Management, further refined …
Build vs. buy.
Schedule vs. functionality.
Environment.
Business goals.

46. Ex. Project Factor Analysis Output
O1: Management
O1.1: Build vs. buy
There is a mild preference to build.
Flexibility & changeability: organization will consider buy if justified.
Impact: moderate impact on meeting schedule.
O1.2: Schedule vs. functionality
Preference for meeting schedule over some features…
Flex.&chng: negotiable for some features … …

47. Technological Factors
T1: General-purpose hardware
E.g. processors, memory, network, disk, …
T2: Domain-specific hardware
T3: Software technology
E.g. OS, UI, prog. lang., design patterns, …
T4: Architecture technology
E.g. arch. Styles, patterns, frameworks.
T5: Standards

48. Product Factors P1: Functional features P2: User interface
P3: Performance
P4: Dependability
P5: Failure detection, reporting, recover
P6: Service
P7: Product Cost

49. What is an Issue?
A (potential) problem.

50. 2. Identify Issues
Key issues influencing architectural design which are to be resolved.
Consider influencing factors.

51. Issue: Skill Deficiencies
Influencing factors:
O2: Staff skills
O2.3 (Experience with multithreading): only one developer has multithreading experience.
O2.4 (Experience with multiprocessor systems): only two developers …

52. 3. Develop Strategies
What is a strategy?

53. What is a Strategy?
A means by which one or more issues are to be resolved, partially or totally.

54. 3. Develop Strategies For each issue:
Develop strategies to address issue.
Identify related strategies.

55. Ex. Issue: Changes in Hardware
Changes in both general-purpose and domain-specific hardware are anticipated on a regular basis. The challenge is to reduce the effort and time involved in adapting the product to the new hardware.
Influencing factors: T1 (General-purpose H/W), T2 (Domain-specific H/W).
Solutions: … ?

56. Ex. Strategies
Encapsulate hardware

57. S4VM: Conceptual View

58. Conceptual View – Documentation
Structure
Configurations of: components, connectors, ports, roles, protocols.
Behavior
State diagrams.
Sequence diagrams.
Natural language.

59. Conceptual View – Activities
Global analysis.
Central design tasks.
Final design task.

60. Conceptual V.: Central Design Tasks
Create conceptual
Components,
Connectors (and ports, roles, protocols)
Configuration.
Global evaluation

61. Conceptual V.: Final Design Tasks
Resource budgeting
Resources used by the software, but
Resources themselves can be H/W or S/W.
Examples of resources include:
Memory,
CPU time,
Bandwidth,
… .

62. Global Evaluation Evaluate design decisions
Continually, relative to results of global analysis.
Periodically, w.r.t. interactions among themselves.
During central design tasks.

63. Module View – Activities
What is the top level grouping of activities?

64. Module View – Activities
Global analysis.
Central design tasks.
Final design task.

65. Module View, Central Design Tasks
Definition of
Subsystems.
Layers
Modules
Allocation of conceptual elements to the above.
Global evaluation.

66. Module View, Final Design Tasks
Design of (key) module interfaces
Operations:
name, signature (return type, parameter type).
Behavior (via specification).

67. What is a “Module”? You can think of this as a UML package.
Does not imply that code will be non OO.
In execution view, will eventually “hold” either OO (classes,…) or non OO code.