Vistas Arquitectonicas

SOFTWARE ARCHITECTURE
Tema 3
Vistas Arquitectónicas
OVERVIEW
 What is it, why bother?

 Architecture Design
www.wileyeurope.com/college/van vliet
©2008 John Wiley & Sons Ltd.
 Viewpoints and view models
 Architectural styles
 Architecture asssessment
 Role of the software architect
2
SOFTWARE DESIGN IN UML
 Class diagrams, state diagrams, sequence
diagram, etc
 Who can read those diagrams?
 Which type of questions do they answer?
 Do they provide enough information?
3
WHO CAN READ THOSE DIAGRAMS?
 Designer, programmer, tester, maintainer, etc.
 Client?
 User?
4
WHICH TYPE OF QUESTIONS DO THEY
ANSWER?
 How much will it cost?
 How secure will the system be?
 Will it perform?
 How about maintenance cost?
 What if requirement A is replaced by
requirement B?
5
ANALOGY WITH BUILDING ARCHITECTURE
 Overall picture of building (client)
 Front view (client, “beauty” committee)
 Separate picture for water supply (plumber)
 Separate picture for electrical wiring (electrician)
 etc
6
ARCHITECTURE PRESENTATIONS IN
PRACTICE
 By and large two flavors:

 Powerpoint slides – for managers, users,
consultants, etc
 UML diagrams, for technicians
 A small sample …
7
8
9
10
11
12
SO, …
 Different representations
 For different people
 For different purposes
 These representations are both descriptive and

prescriptive
13
VIEWS AND VIEWPOINTS
 Generally, it is not feasible to capture everything
we want to model in a single model or document
 The model would be too big, complex, and confusing
 So, we create several coordinated models, each
capturing a subset of the design decisions
 Generally, the subset is organized around a
particular concern or other selection criteria
 We call the subset-model a ‘view’ and the concern
(or criteria) a ‘viewpoint’
14
VIEWS AND VIEWPOINTS EXAMPLE
Deployment view of a 3-tier Deployment view of a

application Lunar Lander system
Both instances of the 15
deployment viewpoint
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
COMMONLY-USED VIEWPOINTS
 Logical Viewpoints
 Capture the logical (often software) entities in a
system and how they are interconnected.
 Physical Viewpoints
 Capture the physical (often hardware) entities in a
system and how they are interconnected.
 Deployment Viewpoints
 Capture how logical entities are mapped onto
physical entities.
16
COMMONLY-USED VIEWPOINTS (CONT’D)
 Concurrency Viewpoints
 Capture how concurrency and threading will be
managed in a system.
 Behavioral Viewpoints
 Capture the expected behavior of (parts of) a system.
17
18
IEEE MODEL FOR ARCHITECTURAL DESCRIPTIONS
(2000)
IEEE MODEL FOR ARCHITECTURAL DESCRIPTIONS
(2011)
©2008
SE, Software Architecture, Hans van Vliet,
19
SOME TERMS (FROM IEEE STANDARD)
 System stakeholder: an individual, team, or
organization (or classes hereof) with interests in,
or concerns relative to, a system.
 View: a representation of a whole system from
the perspective of a related set of concerns.
 Viewpoint: A viewpoint establishes the purposes
and audience for a view and the techniques or
methods employed in constructing a view.
20
STAKEHOLDERS
 Architect
 Requirements engineer
 Designer (also of other systems)
 Implementor
 Tester, integrator
 Maintainer
 Manager
 Quality assurance people
21
VIEWPOINT SPECIFICATION
 Viewpoint name
 Stakeholders addressed
 Concerns addressed
 Language, modeling techniques
22
KRUCHTEN’S 4+1 VIEW MODEL
End-user Programmers
Functionality Software management
Implementation
Logical
Viewpoint
Viewpoint
Scenarios
Process Deployment
Viewpoint Viewpoint
Integrators System engineers

Performance Topology
Scalability Communications
23
4 + 1: LOGICAL VIEWPOINT
 The logical viewpoint supports the functional
requirements, i.e., the services the system should provide
to its end users.
 Typically, it shows the key abstractions (e.g., classes and
interactions amongst them).
 The system is decomposed into a set of key abstractions,
taken (mostly) from the problem domain, in the form of
objects or object classes.
 They exploit the principles of abstraction, encapsulation,
and inheritance.
 This decomposition is not only for the sake of functional
analysis, but also serves to identify common mechanisms
and design elements across the various parts of the system
24
4 + 1: PROCESS VIEWPOINT
 Addresses concurrent aspects at runtime (tasks,
threads, processes and their interactions)
 It takes into account some nonfunctional
requirements, such as performance, system
availability, concurrency and distribution,
system integrity, and fault-tolerance.
 It represents how the main abstractions from the
logical view fit within the process architecture—
on which thread of control is an operation for an
object actually executed.
25
 The process architecture can be described at several levels of
abstraction, each level addressing different concerns.
At the highest level, the process architecture can be viewed

as a set of independently executing logical networks of
communicating programs (called “processes”), distributed
across a set of hardware resources connected by a LAN or a
WAN.
 A process is a grouping of tasks that form an executable unit.
Processes represent the level at which the process
architecture can be tactically controlled (i.e., started,
recovered, reconfigured, and shut down).
 The software is partitioned into a set of independent tasks. A
task is a separate thread of control, that can be scheduled
individually on one processing node. 26
 We can distinguish then: major tasks, that are the
architectural elements that can be uniquely addressed and
minor tasks, that are additional tasks introduced locally for
implementation reasons (cyclical activities, buffering, time-
outs, etc.).
 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, etc. Minor tasks may communicate by
rendezvous or shared memory.
 Major tasks shall not make assumptions about their
collocation in the same process or processing node.
 Flow of messages, process loads can be estimated based on
the process blueprint. 27
4 + 1: IMPLEMENTATION VIEWPOINT
 The implementation viewpoint focuses on the
organization of the actual software modules in
the software-development environment.
 The software is packaged in small chunks-
program libraries or subsystems-that can be
developed by one or more developers.
 The subsystems are organized in a hierarchy of
layers, each layer providing a narrow and well-
defined interface to the layers above it.
28
4 + 1: DEPLOYMENT/PHYSICAL VIEWPOINT
 The deployment viewpoint defines how the various
elements identified in the logical, process, and
implementation viewpoints-networks, processes, tasks,
and objects-must be mapped onto the various nodes.
 It takes into account the system's nonfunctional
requirements such as system availability, reliability (fault-
tolerance), performance (throughput), and scalability.
29
4 + 1: SCENARIO VIEWPOINT
 The scenario viewpoint consists of a small subset
of important scenarios (e.g., use cases) to show
that the elements of the four viewpoints work
together seamlessly.
 This viewpoint is redundant with the other ones

(hence the "+1"), but it plays two critical roles:
 it acts as a driver to help designers discover architectural
elements during the architecture design;
 it validates and illustrates the architecture design, both on
paper and as the starting point for the tests of an
architectural prototype.
30
CONSISTENCY AMONG VIEWS
 Views can contain overlapping and related design
decisions
 There is the possibility that the views can thus
become inconsistent with one another
 Views are consistent if the design decisions they
contain are compatible
 Views are inconsistent if two views assert design
decisions that cannot simultaneously be true
 Inconsistency is usually but not always indicative of
problems
 Temporary inconsistencies are a natural part of
exploratory design 31
 Inconsistencies cannot always be fixed

EXAMPLE OF VIEW INCONSISTENCY
32
COMMON TYPES OF INCONSISTENCIES
 Direct inconsistencies
 E.g., “The system runs on two hosts” and “the system
runs on three hosts.”
 Refinement inconsistencies
 High-level (more abstract) and low-level (more
concrete) views of the same parts of a system conflict
 Static vs. dynamic aspect inconsistencies
 Dynamic aspects (e.g., behavioral specifications)
conflict with static aspects (e.g., topologies)
33
COMMON TYPES OF INCONSISTENCIES (CONT’D)
 Dynamic vs. dynamic aspect inconsistencies

 Different descriptions of dynamic aspects of a system
conflict
 Functional vs. non-functional inconsistencies
34
ARCHITECTURAL VIEWS FROM BASS ET AL
(VIEW = REPRESENTATION OF A STRUCTURE)
 Module views
 Module is unit of implementation
 Decomposition, uses, layered, class
 Component and connector (C & C) views
 These are runtime elements
 Process (communication), concurrency, shared data
(repository), client-server
 Allocation views
 Relationship between software elements and environment
 Work assignment, deployment, implementation
35
MODULE VIEWS
 Decomposition: units are related by “is a
submodule of”, larger modules are composed of
smaller ones
 Uses: relation is “uses” (calls, passes information
to, etc). Important for modifiability
 Layered is special case of uses, layer n can only
use modules from layers <n
 Class: generalization, relation “inherits from”
36
COMPONENT AND CONNECTOR VIEWS
 Process: units are processes, connected by
communication or synchronization
 Concurrency: to determine opportunities for
parallelism (connector = logical thread)
 Shared data: shows how data is produced and
consumed
 Client-server: cooperating clients and servers
37
ALLOCATION VIEWS
 Deployment: how software is assigned to
hardware elements
 Implementation: how software is mapped onto
file structures
 Work assignment: who is doing what
38
ROLE AND CHALLENGE OF SOFTWARE
CONNECTORS
How do we enable
components
Attach adapter to A A and B to Separate
Introduce interact?B’s
or B“essence”
from its packaging
intermediate form
PublishProvide
abstraction
B with
Transform
of A’s on the converter
form
import/export fly
Maintain multiple Negotiate to find
Changeversions
A’s form AWhat
ofto is the
B’scommon
form right
form for Aanswer?
and BMake B multilingual
39
HOW DOES ONE SELECT A CONNECTOR?
 Determine a system’s interconnection and interaction needs
 Software interconnection models can help
 Determine roles to be fulfilled by the system’s connectors
 Communication, coordination, conversion, facilitation
 For each connector
 Determine its appropriate type(s)
 Determine its dimensions of interest
 Select appropriate values for each dimension
 For multi-type, i.e., composite connectors
 Determine the atomic connector compatibilities
40
PROCEDURE CALL CONNECTORS REVISITED
41
HOW TO DECIDE ON WHICH VIEWPOINTS
 What are the stakeholders and their concerns?
 Which viewpoints address these concerns?
 Prioritize and possibly combine viewpoints
42
43
DECISION VISUALIZATION
44
VIEWPOINT
BUSINESS
A CAVEAT ON QUALITY
 A view can be used to assess one or more quality
attributes
 E.g., some type of module view can be used to
assess modifiability
 It should then expose the design decisions that
affect this quality attribute
45

Vistas Arquitectonicas

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vistas Arquitectonicas

Uploaded by

Copyright:

Available Formats

SOFTWARE ARCHITECTURE

 What is it, why bother?

 Which type of questions do they answer?

 Do they provide enough information?

 How much will it cost?

 Overall picture of building (client)

 By and large two flavors:

 For different purposes

 These representations are both descriptive and

Deployment view of a 3-tier Deployment view of a

Both instances of the 15

Integrators System engineers

 The implementation viewpoint focuses on the

 This viewpoint is redundant with the other ones

 Inconsistencies cannot always be fixed

 Dynamic vs. dynamic aspect inconsistencies

 What are the stakeholders and their concerns?

 Prioritize and possibly combine viewpoints

 A view can be used to assess one or more quality

You might also like