Transcript Architectural Design

Material from:
Software Engineering 8, Sommerville
Software Architecture, Shaw and Garlan
ARCHITECTURAL VIEWS &
STYLES
This work is licensed under a Creative Commons
Attribution-Noncommercial 2.5 Canada License
Neil Ernst (slides from Eric Wohlstadter, Emerson Murphy-Hill and
Gail Murphy)
Architectural Design
Focus on separate component development = modularity
 Templates of common patterns used by programmers to
build systems
 Helps managers handle mapping of developers to work
items
 Compared to OO design patterns




Less focus on modeling requirements of program features
More focus on integration of sub-systems
System analysis
affect important non-functional requirements
Most systems are hybrid
broken down into sub-systems with different architectural styles at
different levels of abstraction and different views
Quality Attributes Affect Architecture
Performance
Minimize communication between components
Reduce resource contention and maximize concurrency
Security
Reduce access paths to critical resources
Safety
Localize safety critical operations in a single module
Availability
Provide redundant access paths
Maintainability
Reduce dependencies, make components self-contained
Often in conflict with ease of development
Theme of this part of the course!
Doom 3 Overview
Architectural Views



A view is a sub-set of an architecture related to a specific set of
requirements
Different views derived from different stakeholders
Four common views:
 Logical – object design model (e.g. classes)
 Development – archived component organization (e.g. jars)
 Process – concurrency and synchronization aspects (e.g. threads)
 Physical – mapping of software onto hardware (e.g. machines)
5
Logical View


Supports functional requirements
Follows an object-oriented approach:
 Components:
 Class,
Class Utility (static class), Parameterized Class, Class
Category (package)
 Connectors
 Association,
Aggregation, Usage, Inheritance, Instantiation
6
Development View




Software module organization
Module and subsystem diagrams showing export
and import relationships
Example: JAR files, other libraries (.DLL)
Components:
 Module,

Library, Subsystem, Layer
Connectors:
 Linkage
(compilation/linking dependency)
7
Development View

Why is this different then Logical Architecture?
 Describes
units which are physically developed and
distributed separately
 Consider Java packages
 Same
package can be spread over multiple JAR files
 JAR file is unit of distribution (development architecture)
 Package is unit of design (logical architecture)
8
Process View





Supports some non-functional requirements (e.g.,
performance, availability)
Considers concurrency and distribution
Process is a grouping of tasks that form an executable
unit (can be started, recovered, reconfigured and shut
down)
Task is a separate thread of control
Components:


Process, threads
Connectors:

RPC, Streams, Locks, Transactions
9
Physical View




Considers (more) non-functional requirements:
availability, reliability (fault-tolerance), performance
(throughput), scalability
Mapping of networks, processes, tasks, and objects
onto processing nodes
Different mappings for different modes: deployment
versus testing
Components:


Processor, Machine
Connectors:

Communication line, Network, Bus
10
Recall: Architectural Styles
An architectural style consists of:

a set of component types (e.g. process, procedure) that perform
some function at runtime





How do the developers of components relate to each other?
What is the concurrency between components?
What data is managed by a component?
a configuration of the components showing their runtime
relationships

What is the topological layout?

How can components be added to the system?
a set of connectors (e.g. data streams, sockets) that mediate
communication among components


Synchronous or asynchronous?
Are there constraints on the data interface?
Architectural Topology

Formed from the dependency (usage) graph of
components
 Components
are nodes
 Directed edges indicate that a component uses services
of another component
 Sometimes edges are implied in visual diagrams

Fan-out
 The

# of components used by one component
Fan-in
 The
# of components that use one component
Example:
Linux Architecture Topology
ftp://ftp.oreilly.com/pub/poster/oreilly_linux_poster.pdf
Architectural Topology


Many architectures are DAGs
 No cycles in dependency graph
Cycles inhibit independent evolution
Architectural Topology
Other architectures usually DAGs at higher-levels of abstraction
1. Identify clusters of cyclic dependencies and abstract them
into a single node
1.
e.g. use a tool such as “Structure 101”
2. Architect must justify strong dependency between clustered
components
 e.g. Components in a cluster are developed by one team
3. Clusters members considered as a single component
Fan-In and Fan-out


Architect must justify fan-in/fan-out
Fan-out tradeoffs
Good: Component leverages software reuse
Bad: Component is at risk to changes in many of
components

Fan-in tradeoffs
Good: Component provides high return on initial
development investment
Bad: Very difficult to evolve component without affecting
many consumers
Common Style Categories

Language-influenced



Layered



Virtual Machines
Client-server
Dataflow-styles



Main program and sub-routine
Object-oriented
Batch-sequential
Pipe-and-filter
Shared Memory

Blackboard




Pull-style (repository)
Push-style (publish-subscribe)
Rule-based
Others ….
Layered Styles
Organize system as a stack of consumers and
providers of functions
 Layers
can be both consumer and provider
Each layer only knows about one other layer
Synchronous communication through function calls
Virtual Machine Style

Layers are decomposed into increasing levels of
abstraction
My Web App
Servlet API
JDK
Operating System
Hardware Drivers
Virtual Machine Consequences
+ Easy to extend system by inserting new layer which
provides same interface
– Structuring layers can be difficult as layers may require
services of non-adjacent layers
– Performance can suffer since requests must pass through
many layers
Client-Server Style

Consists of two layers and a network:
A
set of servers
 A set of clients
 A network that allows clients access to servers
Client-Server Consequences

Consequences:
+ Easy to add new servers
 Scalability
is easy to achieve
- Servers cannot initiate contact with clients
- Clients cannot communicate directly with each other
- Servers usually have no shared data format
 Clients
which use multiple servers must take on data format
conversion responsibilities