Software Views

Software Architecture Design
Views of Software Architecture

Matthew Dailey
Computer Science and Information Management
Asian Institute of Technology
Matthew Dailey (CSIM-AIT) Views 1 / 31
Readings
Readings for these lecture notes:
- Arlow and Neustadt (2005), UML 2 and the Unied Process, 2nd
edition, Addison-Wesley, Ch. 1.
- Garland and Anthony (2002), Large-Scale Software Architecture: A
Practical Guide using UML, Wiley.
- Bass, Clements, and Kazman (2003), Software Architecture in
Practice, 2nd edition, Addison-Wesley, Ch. 12.
Some material c Arlow and Neustadt (2005); Garland and Anthony
(2002), Bass et al. (2003).
Outline
1
Introduction
2
Krutchens 4+1 views
3
Garland and Anthonys viewpoints
4
Bass et al.s architectural views
5
Architectural view summary
Introduction
Views of architecture
The architecture design will always need to be shown from multiple
perspectives or viewpoints for dierent stakeholders in the software
development process.
Here well consider two variants based on UML, both consistent with the
UP:
Krutchens 4+1 views
Well also take a look at Bass et al.s (non-UML) classication of
architectural structures.
What views you choose as an architect will depend on the specic project,
processes in place in your organization, and who you need to communicate
with.
Introduction
Why views?
Seeing architecture from a variety of perspectives is necessary:
Runtime behavior and logical structure within the same system are
very dierent.
A high-level architectural design provides constraints for lower-level
architectures.
The architecture needs to be considered in structuring the
development organization.
The architecture needs to be evaluated in its ability to meet
non-functional requirements (reliability, performance, and so on).
Architecture views facilitate communication between teams.
Dierent architecture views are necessary inputs for developers,
testers, integrators, and so on.
Introduction
What do views tell us?
Architectural specications tell stakeholders many things:
What are the subsystems or components of the software?
What are the repsonsibilities of a component?
What interfaces are provided and used by a component?
What subsystems would be aected by a particular change?
How much retesting would be required after this change?
What components are involved in installing this change?
How are parts of the system to be physically distributed?
How will a change impact the performance of the system?
What development teams are impacted by a change to this interface?
How much eort is involved in the development of this functionality?
Diagrams
Architectures will often be represented by diagrams, UML or otherwise.
But dont get bogged down in the details of the diagramming technique.
Always thing about what your diagram is trying to say:
What is the nature of the elements being shown?
What is the responsibility of each element?
What is the signicance of the connections?
What is the signicance of the layout?
Introduction
Architectural elements
The elements in an architecture could be any useful decomposition of the
system:
Software modules
Classes and objects
Processes or threads
Data repositories
Hosts in a distributed system
Processors and communication channels
Files
Development teams
And so on...
Some of these element decompositions are static, and some are dynamic.
Introduction
Externally visible properties
In an architecture, we care about the externally visible properties, i.e., are
the assumptions other elements can make about an element, including
Input/output behavior
Real time characteristics
Concurrency constraints
And so on...
Introduction
Documenting vs. creating
Todays well look mostly at how architectures are documented
(understanding an architectural document is important for everyone on a
software project).
After that well look at how architectures are analyzed (being able to
analyze an architecture is important for technical leads).
Then well spend the rest of the semester on how architectures are created
(being able to create an architecture is important for members of the
architecture team).
Outline
1
Introduction
2
Krutchens 4+1 views
3
4
5
Krutchens 4+1 views
Kruchtens Four Plus One view of software architecture is popular in the
OO model-driven development community.
Arlow and Neustadt, Fig. 1.13
Krutchens 4+1 views
The 4+1 views:
The design or logical view: the classes, interfaces, and collaborations
forming the vocabulary of the problem and its solution.
The interaction or process view: how control ows across the static
classes at run time.
The implementation view: the organization of the software modules
in the development environment.
The deployment view: A mapping of elements onto processing and
communication nodes.
Uses cases cut across the views. They capture the systems functional
requirements for the system and help nd conicts.
Krutchens 4+1 views
The use case view
The use case view (the +1 view) unies the four primary views by
describing stakeholder functional requirements.
Weve begun to look at use case modeling in lab:
Use case diagrams model static relationships with actors.
Interaction diagrams, state diagrams, and activity diagrams model
dynamic aspects of the use cases.
The focus is on externally visible behavior, but the use case model will
inuence the system architecture.
Krutchens 4+1 views
The design view
The design view of the architecture
Captures the vocabulary of the problem domain as a set of classes
and objects.
Primarily supports the functional requirements of the system.
Static aspects are captured by class and object diagrams.
Dynamic aspects are captured by interaction diagrams, state
diagrams, and activity diagrams, focusing on sequential behavior and
responsibilities.
The design view is a way of looking at the design model, which evolves
from the business model and analysis model, and is iteratively rened.
Krutchens 4+1 views
The interaction view
The interaction view of the architecture
Captures the behavior of the processes executing in the system.
Shows the ow of control on top of the design view.
Documents concurrency and synchronization mechanisms.
Uses the same diagram types as the design view, with focus on the
active classes controlling the system and messages owing between
them.
The interaction view, like the design view, is a way of looking at the
design model, but the focus is on processes, threads, synchronization,
concurrency, and message passing.
Krutchens 4+1 views
The implementation view
The implementation view of the architecture
Describes the artifacts used to assemble and release the physical
system.
Examples include les, libraries, documents, executables.
Static aspects are captured in artifact diagrams.
Dynamic aspects can be captured in interaction, state, and activity
diagrams.
Krutchens 4+1 views
The deployment view
The deployment view
Desribes the nodes that form the systems hardware topology and the
network connections between them.
Documents what parts of the system execute where.
Static aspects are captured in deployment diagrams.
Dynamic aspects can be captured in interaction, state, and activity
diagrams.
Outline
1
Introduction
2
Krutchens 4+1 views
3
4
5
Garland and Anthony (2002) have a dierent perspective from the OMG.
Over years of experience on extremely large projects in banking,
telecommunications, and so on, the authors came up with a dierent set
of ways to describe and design architectures for large-scale systems.
Like 4+1, they advocate the UML, but use the diagrams more as aids to
design than for model-driven development.
Note that the terms view in 4+1 and viewpoint here are talking about
the same thing.
Though approaches to documenting architecture may be dierent
according to dierent processes, note that the principles and best practices
are compatible!
Categories of viewpoints
The viewpoints are broken into three categories:
Conceptual and analysis viewpoints describe the problem domain
more so than the solution domain.
Logical design viewpoints describe the software design, from the
runtime, static, and data model points of view.
Environment/Physical viewpoints focus on the physical deployment of
software, databases, and processes, along with the dynamic states of
processes.
Conceptual and analysis viewpoints
The conceptual and analysis viewpoints include:
Analysis focused: a UML class diagram describing system entities in
response to a specic scenario. Some times called view of
participating classes (VOPC).
Analysis interaction: a UML interaction diagram involving analysis
classes.
Analysis overall: a UML class diagram combining all the classes from
all the analysis focused viewpoints.
Context: a UML use case diagram showing external actors and the
system under design.
Logical design viewpoints
The logical design viewpoints include:
Component: a UML component diagram illustrating component
communications.
Component interaction: a UML iteraction diagram describing
interactions among components.
Component State: a UML state or activity diagram for a component.
Layered Subsystem: a UML package diagram illustrating layering and
subsystems design.
Logical Data: a UML class diagram showing critical data views.
Subsystem Interface Dependency: a UML class diagram illustrating
dependencies and interfaces between subsystems.
Environment/Physical viewpoints
The environment/physical viewpoints include:
Deployment: a UML deployment diagram mapping software to
hardware in a distributed system.
Physical data: a UML deployment diagram showing a physical view of
a particular database.
Process: a UML deployment diagram showing how processes are
distributed for an instance of the system.
Process state: the dynamic states of a process.
Outline
1
Introduction
2
Krutchens 4+1 views
3
4
5
Characterizing software structures
Bass et al. document many dierent ways of looking at a software
systems structure.
Module-based structures: the elements are software modules (the
implementation units). Includes decomposition, uses, layered, class.
Component-and-connector structures: the elements are run-time
components. Includes process communication, concurrency
(parallelism), shared data production and consumption, and
client-server communication.
Allocation structures: the elements are deployment (onto hardware
and communication components), implementation (in terms of the
le system), and work assignment (breakdown according to
development teams).
Structure Relations Useful for
Decomposition Is a submodule of;
shares secrets with
Resource allocation and
project structuring and
planning; information
hiding; encapsulation;
conguration control
Uses Requires the cor-
rect presence of
Engineering subsets;
engineering extensions
Layered Requires the cor-
rect presence of;
uses the service
of; provides ab-
straction to
Incremental develop-
ment; implementing sys-
tems on top of virtual
machines; portability
Class Is an instance
of; shares access
methods of
In object-oriented design
systems, producing rapid
almost-alike implemen-
tations from a common
template
Client-server Communicates
with; depends on
Distributed operation;
separation of concerns;
performance analysis;
load balancing
Process Runs concur-
rently with; may
run concurrently
with; excludes;
precedes; etc.
Scheduling analysis; per-
formance analysis
Concurrency Runs on the same
logical thread
Identifying locations
where resource con-
tention exists, where
threads may fork, join,
be created, or be killed
Shared data Produces data;
consumes data
Performance, data in-
tegrity, modiability
Deployment Allocated to; mi-
grates to
Performance, availabil-
ity, security analysis
Implementation Stored in Conguration control,
integration, test activi-
ties
Work assign-
ment
Assigned to Project management,
best use of expertise,
management of com-
monality
Outline
1
Introduction
2
Krutchens 4+1 views
3
4
5
The bottom line: there is no single best way to describe a software
architecture design.
The architect must determine what is the right communication method for
the particular project at hand, building on established best practices.
It is also important what tools, processes, and customs are already in place
in your organization.
Regardless of your method, always consider what youre trying to
communicate and which stakeholders youre trying to communicate to.

Software Views

Uploaded by

Document Information

Original Title

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

Software Views

Uploaded by

Copyright:

Available Formats

Software Architecture Design

Views of Software Architecture

You might also like