AUTHOR: PHILIPPE B' KRUCHTEN,

1
The 41 Views Model of Architecture
1

• AUTHOR PHILIPPE B. KRUCHTEN,
• RATIONAL SOFTWARE
• PRESENTED BY AHMED A. BAHJAT,
• AHMED M. HUSSAIN,
• ABDULAZIZ AL-KHALID,
• HOMOUD I. AL-JAMAAN

12/25/2009
2
Introduction
2

• Using multiple views allows to address separately
  the concerns of the various stakeholders
  (end-users, developers, systems engineers,
  project managers, etc..)
• Also an aid to handle functional and
  non-functional requirements.
• Diagrams and articles (consist of boxes and
  arrows) attempt to show the core of the
  architecture of the system. But there are some
  questions
• Are the boxes representing running programs?
  chunks of code? physical computers? logical
  grouping of functionality?
• Are the arrows representing compilation
  dependencies? control flow? dataflow?
• does an architecture need a single architectural
  style?
• The architecture does not address the concerns of
  all its customers or stakeholders?

12/25/2009
3
An Architectural Model
3

• Perry and Wolfe put software architecture in very
  nice formula, modified by Boehm
• Software Architecture Elements, Forms,
  Rationale/Constraints
• Software architecture is the result of assembling
  these architectural elements in some well-chosen
  forms to satisfy functionality, performance of
  the system, and non-functional requirements such
  as reliability, scalability, portability and
  reliability.
• Software architecture deals with design,
  implementation of the high level structure of the
  software, abstraction, decomposition and
  composition, style and esthetics.
• We use a model composed of five views
• A- The Logical view the object model for the
  design(for object oriented methods).
• B- The Process view for capturing concurrency
  and synchronization aspects of the design.
• C- The Physical view for mapping the software
  onto the hardware and reflects its distributed
  aspects.
• D- The Development view for describing the
  static organization of the software in its
  development environment.
• E- Decision made or description of an
  architecture this illustrated by a few selected
  use cases or scenarios.

12/25/2009
4
The 41 view model
4
12/25/2009
5
The logical View
5
12/25/2009
6
The Logical Architecture (Object Oriented
Decomposition)
6

• Primarily supports the functional requirements.
• The system is decomposed into a set of key
  abstractions, taken from problem domain in the
  form of objects or object classes.
• Principles of abstraction, encapsulation, and
  inheritance are used.
• Class diagram shows a set of classes and their
  logical relationship, association, usage,
  composition, inheritance and so forth.
• Class template emphasize the main class
  operations and identify key object
  characteristics
• Class utilities define common mechanisms or
  services.
• State transition diagrams or state charts are
  used to define the internal behavior of an
  object.
• Applications that is very data-driven may use
  some other form of logical view, such as E-R
  diagrams.
• Notation for Logical View
• Rationale/Boach approach used for representing
  the logical architecture by means of class
  diagrams and class templates.
• Take items that are architecturally significant .

12/25/2009
7
Style for Logical view
7

• Object oriented style.
• We try to keep a single, coherent object model
  across the whole system.

12/25/2009
8
Example 1
8

• Line Controller
• decode and inject all the signals on the line
  interface card, translating card-specific signals
  to and from a small, uniform set of events
  start, stop, digit, etc.
• Terminal
• maintain the state of a terminal,
• and negotiate services on behalf of that line.
• Conversation
• set of terminals engaged in a conversation.

12/25/2009
9
Example 2
ICS 513 Software Design
10
The Process View
10
12/25/2009
ICS 513 Software Design
11
The Process Decomposition

• It takes into account
• Some non-functional requirements (performance,
  Availability).
• Issues of (concurrency, distribution, systems
  integrity)
• Description
• It described at several levels of abstraction
• highest level logical networks of processes
  distributed across a set of hardware resources
  connected by a LAN or a WAN.

ICS 513 Software Design
12
Process Task

• Process is a grouping of tasks that form an
  executable unit (executable started, recovered,
  reconfigured, shutdown).
• Task is a thread of control that can be
  scheduled individually on one process.
• major tasks architectural elements that can be
  uniquely addressed.
• minor tasks additional tasks used for
  implementation reasons (cyclical activities,
  buffering, time-outs, etc.).
• software is partitioned into a set of independent
  tasks.

ICS 513 Software Design
13
Communication

• Major tasks communicate via a set of well-defined
  inter-task.
• communication mechanisms
• synchronous and asynchronous message-based
  communication services
• remote procedure calls
• event broadcast
• .
• Minor tasks may communicate by rendezvous or
  shared memory.

ICS 513 Software Design
14
Notation
ICS 513 Software Design
15
Style for the process view

• Garlan and Shaws taxonomy pipes and filters,
  or client/server, with variants of multiple
  client/single server and multiple
  clients/multiple servers.
• For more complex systems, style similar to the
  process groups approach of the system as
  described by K. Birman with another notation and
  toolset.

ICS 513 Software Design
16
Process blueprint for the Telic PABX (partial)
ICS 513 Software Design
17
Process blueprint for the Telic PABX (partial)

• Terminal process handle all terminals, and
  driven by messages in its input queues.
• Controller Process is composed of three tasks,
  controller objects are executed on one of these 3
  tasks.
• Low cycle rate task scans all inactive terminals
  (200 ms), puts any terminal becoming active in
  the scan list of the high cycle rate task.
• High cycle rate task (10ms) detects any
  significant change of state, and passes them to
  the main controller task
• Main controller task which interprets the changes
  and communicates them by message to the
  corresponding terminal.
• message passing within the controller process is
  done via shared memory.

ICS 513 Software Design
18
Correspondence From logical to process view
19
Correspondence From logical to process view

• classes characteristics
• Autonomy
• are the objects active, passive, protected?
• Active object
• invoke other objects operations or its own
  operations
• has full control over the invocation of its own
  operations by other objects.
• Passive object
• never invokes any operations
• has no control over the invocation of its own
  operations by other objects.
• protected object
• never invokes any operations
• performs some arbitration on the invocation of
  its operations
• Persistence
• are the objects transient , permanent?
• Subordination
• is the existence of an object depending on
  another object?
• Distribution
• are the operations of an object accessible from
  several processes in the process architecture?

ICS 513 Software Design
20
Strategies

• We use two strategies the set of processes that
  are needed.
• Inside-out
• Definition define agent tasks (a single thread
  of control , multiple active objects of a class)
• Subordination objects whose life is subordinate
  to an active object executed on that same agent
• Mutual exclusion several classes that need to
  be executed in mutual exclusion share a single
  agent.
• Mini Processing Objects that require only small
  amount of processing share a single agent
• Outside-in
• External requests identify external requests to
  the system, define client processes to handle the
  request
• data integrity use the data integrity and
  constraints of the problem to define the right
  set of servers
• Distribution identify which objects must be
  distributed.

ICS 513 Software Design
21
About Agent Task

• there is an agent task for an active class, with
  some variations
• several agents for a given class to increase
  throughput.
• several classes mapped onto a single agent
  because their operations are infrequently
  invoked.
• its requires a few iterations to get an
  acceptable solution.

ICS 513 Software Design
22
Example Air-traffic Control System
23
Air-traffic Control System

• The flight class is mapped onto a set of flight
  agents
• there are many flights to process,
• a high rate of external requests,
• response time is critical,
• the load must be spread across multiple CPUs.
• The distribution aspects of the flight processing
  are delayed to a flight server, which is
  duplicated for availability reasons.
• A flight profile or a clearance are always
  subordinate to a flight So they share the
  processes of the flight class.
• Sectorization class, which established a
  partitioning of airspace over flights, can be
  handled only by a single agent because of its
  integrity constraints, but can share the server
  process with the flight .
• Locations and airspace and other static
  information are protected objects, shared among
  several classes, rarely updated they are mapped
  on their own server, and distributed to other
  processes.

ICS 513 Software Design
24
The Development View
24
12/25/2009
25
Development view

• This view is used to describe the static
  organization of the software in the development
  environment.
• Development view audience programmers and
  software managers.

ICS 513 Software Design
26
Development view

• Focuses on the actual module organization on the
  software development environment.
• Development architecture is represented by module
  and subsystem diagrams, showing import and export
  relationships.
• Software is packaged in small subsystems.
• Subsystems are organized in a hierarchy of
  layers.
• Development architecture can only be described
  when all the elements of the software have been
  identified.

ICS 513 Software Design
27
Development view

• List of rules that govern the development
  architecture
• Partitioning
• Grouping
• Visibility
• Development architecture takes into account the
  internal requirements related to the ease of
  development, software management, reuse,
  constraints imposed by the programming language.

ICS 513 Software Design
28
Development view

• Development view serves as the basis for
• Requirements allocation
• Team organization
• Cost evaluation and planning
• Monitoring the progress of the work
• Reasoning about software reuse
• Establishing a line of product

29
Notation

• Booch notation

• Rational rose can draw these diagrams.

ICS 513 Software Design
30
Development view style

• Layered style should be adopted for the
  development view.
• Each layer has a well-defined responsibility.
• Design rule a subsystem can only depend on
  subsystems that are in the same layer or in
  layers below.
• Why this design rule? To minimize the development
  of very complex network of dependencies between
  modules and allow simple release strategies layer
  by layer.

ICS 513 Software Design
31
Example of development architecture

• The following figure represents the development
  organization of Air Traffic Control systems
  developed by Hughes Aircraft of Canada.

ICS 513 Software Design
32
From logical to development

• Large classes are decomposed into multiple
  packages.
• Closely related classes are grouped into
  subsystems.
• When we define subsystems, we must consider
  additional constraints
• Team organization
• Expected code
• Degree of reuse
• Strict layering principles
• Configuration management

ICS 513 Software Design
33
From logical to development

• Logical and development views are very close, but
  address different concerns.

• There is no one to one mapping of the class
  categories to the layers.

ICS 513 Software Design
34
The Physical View
34
12/25/2009
35
The Physical Archeticture

• Mapping the software to the hardware
• Takes into account primarily the non-functional
  requirements
• We expect that several different physical
  configurations will be used some for development
  and testing, others for the deployment of the
  system for various sites or for different
  customers.
• The mapping of the software to the nodes
  therefore needs to be highly flexible and have a
  minimal impact on the source code itself.

ICS 513 Software Design
36
Notations
ICS 513 Software Design
37
Example
ICS 513 Software Design
38
1 Scenarios
38
12/25/2009
39
Scenarios

• This view is redundant with the other ones (hence
  the 1), but it serves two main purposes
• as a driver to discover the architectural
  elements during the architecture design
• as a validation and illustration role after this
  architecture design is complete,
• An abstraction of the most iprtant requirements.
• Audience All users of other views and
  Evaluators.
• Addresses System consistency, validity
• Method English, graphical notations, UML use
  cases.
• Authors Advice and Experience. 
• Views are interconnected.
• Start with Logical view (Req. Doc) and Move to
  Development or Process view and then finally go
  to Physical view.
• Concurrency analysis methods (Inside Out and
  Outside In). 

ICS 513 Software Design
40
Example
The notation is very similar to the logical view
for the components, but uses the connectors of
the Process view for interactions between objects.
ICS 513 Software Design
41
Remarks

• Methodology used in the industry
• Industry specific targeted to RT systems
  (aerospace, teleco.). Consider Desktop
  application development
• Complete All other views are reducible to one of
  the 4 views
• No tools to connect the views together. Views
  will suffer from inconsistencies. Problems will
  worsen as we start maintaining the Architecture

ICS 513 Software Design
42
Tailoring the Model
42

• Not all software architecture need the full
  41 views. Views that are useless can be
  omitted from the architecture description, such
  as the physical view, if there is only one
  processor, and the process view if there is only
  process or program. For very small system, it is
  even possible that the logical view and the
  development view are so similar that they do not
  require separate descriptions. The scenarios are
  useful in all circumstances.

12/25/2009
43
ICS 513 Software Design
44
Documenting the Architecture
44
1
2
3
4
5
12/25/2009
45
Conclusion
45

• Problem 
• Arch. documents overemphasize an aspect of
  development or do not address the concerns of all
  customers
• Arch. documents contain complex diagrams 
• Solution 
• Different notation for the different aspects of
  the system 4 Views an architecture
  verification technique 

12/25/2009
46
Logical View

•  
• Audience End-user
• Addresses Functional requirements
• Method OMT notation (object and dynamic models)
   

ICS 513 Software Design
47
Process View

• Audience Integrators
• Addresses Non - functional requirements
  (concurrency,
• performance, scalability)
• Method Garlan and Shaw s Architecture styles
• Uses multiple levels of abstractions
• Major Tasks Arch. relevant tasks (Serial Server)
  
• Minor Tasks Helper tasks. (Input / Output
  Threads)

ICS 513 Software Design
48
Development View

• AKA. (Traditional Design Document)
•  Audience Programmers and Software Mgrs.
• Addresses file layout, production schedule
• Method dependency graphs and Layered diagrams
• It could be in the form of guidelines or
  extremely detailed 

ICS 513 Software Design
49
Physical View

• Audience System Engineers
• Addresses Topology, Communication
• Method English or a simple notation that is over
  the process view diagrams
• Tightly connected to the process view.

ICS 513 Software Design
50
Q A