©Medvidovic, Van Vliet, Mejia-AlvarezSlide 1 Architectural Design l Establishing the overall...
-
Upload
lizbeth-harper -
Category
Documents
-
view
214 -
download
1
Transcript of ©Medvidovic, Van Vliet, Mejia-AlvarezSlide 1 Architectural Design l Establishing the overall...
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 1
Architectural Design
Establishing the overall structure of a software system
Objectives• To introduce architectural design and to discuss its
importance• To explain why multiple models are required to
document a software architecture• To describe types of architectural model that may be
used
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 2
What is Architecture? A high-level model of a thing
• Describes critical aspects of the thing
• Understandable to many stakeholders
• Allows evaluation of the thing’s properties before it is built
• Provides well understood tools and techniques for constructing the thing from its blueprint
Which aspects of a software system are architecturally relevant? How should they be represented most effectively to enable
stakeholders to understand, reason, and communicate about a system before it is built?
What tools and techniques are useful for implementing an architecture in a manner that preserves its properties?
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 3
What is Software Architecture? A software system’s blueprint
• Its components• Their interactions• Their interconnections
Informal descriptions• Boxes and lines• Informal prose
A shared, semantically rich vocabulary• Remote procedure calls (RPCs)• Client-Server• Pipe and Filer• Layered• Distributed• Object-Oriented
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 4
From Requirements to Architecture From problem definition to requirements specification
• Determine exactly what the customer and user want
• Specifies what the software product is to do From requirements specification to architecture
• Decompose software into modules with interfaces
• Specify high-level behavior, interactions, and non-functional properties
• Consider key tradeoffs» Schedule vs. Budget
» Cost vs. Robustness
» Fault Tolerance vs. Size
» Security vs. Speed
• Maintain a record of design decisions and traceability
• Specifies how the software product is to do its tasks
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 5
Another View:The Twin Peaks Model
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 6
Focus of Software Architectures Two primary foci
• System Structure, Behavior, Interactions, Topology, Data, and key Properties
• Correspondence between requirements and implementation
A framework for understanding system-level concerns
• Global rates of flow
• Communication patterns
• Execution Control Structure
• Scalability
• Paths of System Evolution
• Capacity
• Throughput
• Consistency
• Component Compatibility
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 7
Why Software Architecture? A key to reducing development costs
• Component-based development philosophy• Explicit system structure
A natural evolution of design abstractions• Structure and interaction details overshadow the choice of algorithms
and data structures in large/complex systems Benefits of explicit architectures
• A framework for satisfying requirements• Technical basis for design• Managerial basis for cost estimation & process management• Effective basis for reuse• Basis for consistency, dependency, and tradeoff analysis• Avoidance of architectural erosion
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 8
aTruck aShip aAirplane theWarehouseCo llecti on
theVehicleCollection
UML-A Generated Dependency Class:theRouter Dependency (1.0)
theStorage
aVehicle
UML-A Generated Dependency Class:theRouter Dependency (0.5)
availableVehicleCollection
UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Genera ted As socia tion C lass: theVehicleC ollec tion Genera lization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML- A Generated Ass ociati on Cl ass:theVehi cleCo llection Generali zation (1.0 )UML-A Generated Association Class:theVehicleCollection Generalization (1.0)
UML-A Generated Dependency Class:theRouter Dependency (1.0)
availableGoods
aPort
aPortC ollec tion
aSurp lus aDifficiency
theTimeNeeded
theGoods
UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:availableGoods Association (0.5)
aRouteCollection
UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)
UML-A Generated Dependency Class:theRouter Dependency (0.5)UML-A Generated Dependency Class:theRouter Dependency (1.0)
UML-A Generated Dependency Class:theRouter Dependency (1.0)
theAWT
aVehiceDialog aWarehouseDialog aPortDialog aRouterDialog
aWarehouse
UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)
UML-A Generated Association Class:aDifficiency Association (1.0)U ML-A Generated Association Class:aD ifficiency Associ ation (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)U ML-A Generated Association Class:aD ifficiency Associ ation (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Genera ted Associ ation C lass:aSurp lus Associ ation (1.0)UML-A Generated Association Class:aSurplus Association (0.5)
UML-A Generated Associ ation Class:aRoute Association (0.5)
aLocation
UML-A Generated Association Class:aNavPoint Association (1.0)
UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:aNavPoint Association (0.5)
UML-A Generated Association Class:aNavPoint Association (0.5)UML-A Generated Association Class:aNavPoint Association (0.5)
UML-A Generated Association Class:aWarehouse Association (0.5)aNavPoint
UML-A Generated Association Class:aWarehouse Association (1.0)
UML-A Generated Association Class:aWarehouse Association (0.5)UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:aRoute Association (0.5)
aRoute
UML-A Genera ted Dependency C lass :aRou teCol lection Ass ociation (0.25)
UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (0.5)
UML-A Generated Association Class:aWarehouse Association (1.0)
UML-A Generated Dependency Class:aRouteCollection Association (0.5)
UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)
UML-A Generated Association Class:aNavPoint Association (0.25)UML-A Generated Association Class:aNavPoint Association (0.25)
UML-A Generated Association Class:aNavPoint Association (0.25)
UML-A Generated Dependency Class:theRouter Association (0.25)
UML-A Generated Association Class:aNavPoint Association (0.25)
theCargoRouter
UML-A Generated Association Class:theRouter Association (0.25)
UML-A Genera ted As socia tion C lass: theWarehouseCo llection Dependency ( 0.25)
UML-A Generated Association Class:theRouter Association (0.25)
UML-A Generated Association Class:theRouter Association (0.25)
t heRou ter
UML-A Generated Association Class:theWarehouseCollection Dependency (0.5)
UML-A Generated Association Class:theWarehouseCollection Dependency (0.5)
UML-A Genera ted Dependency Class :aRouteCollection Ass ociation (0.5)UML-A Generated Association Clas s:theWarehouseCollec tion Dependency (0.5)
UML-A Generated Association Class:theVehicleCollection Dependency (0.5)UML-A Generated Association Class:availableVehicleCollection Dependency (0.5)UML- A Generated Generaliz ation Class :avail ableVehicleCollection Dependenc y (1.0 )
UML-A Generated Dependency Class:theRouter Association (0.25)
UML-A Generated Dependency Class:theRouter Association (0.5)UML-A Generated Dependency Class:theRouter Association (1.0)
UML-A Generated Dependency Class:theRouter Association (0.5)
UML-A Generated Dependency Class:theWarehouseCollection Dependency (1.0)
UML-A Generated Dependency Class:theRouter Association (1.0)UML-A Generated Dependency Class:theRouter Association (1.0)
What is the Problem?This is a simple
software system!
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 9
aTruck aShipaAirplane
availableVehicleCollection
theAWT
aVehiceDialogaWarehouseDialog
aPortDialog
aRouterDialog
aRouteCollection
aVehicle
theVehicleCollection
theCargoRouter
theRouter
theTim eNeeded
aRoute
aDeficiency
theWarehouseCollection
aNavPoint
theStorage
RefrigeratedStorage
RegularStorage
availableGoods
aPortCollection
aLocation
theGoods
aWarehouse
aSurplus
aPort
The Usual Tool: Design Abstraction
We have to do better!
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 10
VehicleDel iveryPort
CargoRouter
RouterConn
GraphicsBinding : GraphicsBinding
GraphicsConn
Warehouse
ClockConn
Clock : Clock
10: notification9: notification
5: request
3: request4: request
2: notification
1: request
7: request
6: notification
8: request
Architectural Abstraction
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 11
What is Software Architecture? Definition:
• A software system’s architecture is the set of principal design decisions about the system
Software architecture is the blueprint for a software system’s construction and evolution
Design decisions encompass every facet of the system under development• Structure
• Behavior
• Interaction
• Non-functional properties
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 12
Other Definitions of Software Architecture Perry and Wolf
• Software Architecture = { Elements, Form, Rationale }what how why
Shaw and Garlan• Software architecture [is a level of design that] involves
» the description of elements from which systems are built, » interactions among those elements, » patterns that guide their composition, and » constraints on these patterns.
Kruchten• Software architecture deals with the design and implementation of the high-
level structure of software.• Architecture deals with abstraction, decomposition, composition, style, and
aesthetics.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 13
Architectural design process System structuring
• The system is decomposed into several principal sub-systems
• Communications between these sub-systems are identified
Control modelling• A model of the control relationships between the different parts
of the system is established
Modular decomposition• The identified sub-systems are decomposed into modules
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 14
Key Architectural Concepts Three canonical building blocks
• components• connectors• configurations
A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems
A module is a system component that provides services to other components but would not normally be considered as a separate system
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 15
Components A component is a unit of computation or a data store Components are loci of computation and state
• clients• servers• databases• filters• layers• ADTs
A component may be simple or composite• composite components describe a (sub)system• an architecture consisting of composite components describes a system
of systems
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 16
Components Elements that encapsulate processing and data in a system’s
architecture are referred to as software components Definition
• A software component is an architectural entity that
» encapsulates a subset of the system’s functionality and/or data
» restricts access to that subset via an explicitly defined interface
» has explicitly defined dependencies on its required execution context
Components typically provide application-specific services
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 17
Software components In most engineering disciplines, systems are
designed by composing existing components that have been used in other systems
Software engineering has been more focused on original development
It is now recognized that to achieve • better software• more quickly • at lower cost
we need to adopt a design process that is based on systematic reuse
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 18
Components Components provide a service without regard to
where the component is executing or its programming language• A component is an independent executable entity that
can be made up of one or more executable objects
• The component interface is published and all interactions are through the published interface
Components can range in size from simple functions to entire application systems
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 19
A software component: Implements some functionality
Has explicit dependencies through provided and required interfaces
Communicates through its interfaces only
Has structure and behavior that conforms to a component model
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 20
LEGO analogy Set of building blocks in different shapes and
colors Can be combined in different ways Composition through small stubs in one and
corresponding holes in another building block LEGO blocks are generic and easily
composable LEGO can be combined with LEGO, not with
e.g. MEGA Bloks
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 21
Component abstractions Functional abstraction
• The component implements a single function such as a mathematical function
Casual groupings • The component is a collection of loosely related entities that might be data
declarations, functions, etc.
Data abstractions • The component represents a data abstraction or class in an OO language
Cluster abstractions • The component is a group of related classes that work together
System abstraction • The component is an entire self-contained system
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 22
Why CBSE?
CBSE increases quality, especially evolvability and maintainability
CBSE increases productivity
CBSE shortens development time
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 23
Hiding of component internals
Black box: only specification is known Glass box: internals may be inspected, but not
changed Grey box: part of the internals may be inspected,
limited modification is allowed While box: component is open to inspection and
modification
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 24
Development process in CBSE
Two separate development processes:• Development of components
• Development of systems out of components
Separate process to assess components
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 25
CBSE system development process
Requirements: also considers availability of components (as in COTS)
Analysis and design: very similar to what we normally do Implementation: less coding, focus on selection of
components, provision of glue code Integration: largely automated Testing: verification of components is necessary Release: as in classical approaches Maintenance: replace components
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 26
Component assessment
Find components
Verify components
Store components in repository
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 27
Component development process Components are intended for reuse
Managing requirements is more difficult More effort required to develop reusable
components More effort in documentation for consumers
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 28
Component development process Requirements: combination of top-down (from
system) and bottom-up (generality) Analysis and design: generality is an issue,
assumptions about system (use) must be made Implementation: largely determined by
component technology Testing: extensive (no assumptions of usage!),
and well-documented Release: not only executables, also metadata
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 29
Software Connector Architectural element that models
• Interactions among components• Rules that govern those interactions
Simple interactions• Procedure calls• Shared variable access
Complex & semantically rich interactions• Client-server protocols• Database access protocols• Asynchronous event multicast
Each connector provides• Interaction duct(s)• Transfer of control and/or data
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 30
Where are Connectors in Software Systems?
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 31
Benefits of First-Class Connectors
Separate computation from interaction Minimize component interdependencies Support software evolution
• At component-, connector-, & system-level
Potential for supporting dynamism Facilitate heterogeneity Become points of distribution Aid system analysis & testing
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 32
An Example of Explicit Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 33
An Example of Explicit Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 34
Software Connector Roles
Communication Coordination Conversion Facilitation
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 35
Connector Types Procedure call Data access Event Stream Linkage Distributor Arbitrator Adaptor
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 36
A Framework for Classifying Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 37
Procedure Call Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 38
Event Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 39
Data Access Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 40
Linkage Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 41
Stream Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 42
Arbitrator Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 43
Adaptor Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 44
Distributor Connectors
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 45
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
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 46
Configurations/Topologies An architectural configuration or topology is a connected
graph of components and connectors that describes architectural structure
• proper connectivity
• concurrent and distributed properties
• adherence to design heuristics and style rules
Composite components are configurations
C3 C4 C5
A
B C
D
C2C1
C7C6
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 47
Scope of Software Architectures Every system has an architecture. Details of the architecture are a reflection of system
requirements and trade-offs made to satisfy them Possible decision factors
• Performance• Compatibility with legacy software• Planning for reuse• Distribution profile
» Current and Future
• Safety, Security, Fault tolerance requirements• Evolvability Needs
» Changes to processing algorithms» Changes to data representation» Modifications to the structure/functionality
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 48
Example Architecture – Compiler
Lexer
Parser
Semantor
Optimizer
CodeGenerator
Lexer Parser Semantor
InternalRepresentation
OptimizerCode
Generator
Sequential Parallel
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 49
CASE toolset architecture
Projectrepository
Designtranslator
Programeditor
Designeditor
Codegenerator
Designanalyser
Reportgenerator
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 50
Version management system
Operatingsystem
Database system
Object management
Version management
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 51
Packing robot control systemVisionsystem
Objectidentification
system
Armcontroller
Grippercontroller
Packagingselectionsystem
Packingsystem
Conveyorcontroller
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 52
Film and picture library
Catalogueserver
Catalogue
Videoserver
Film clipfiles
Pictureserver
Digitizedphotographs
Hypertextserver
Hypertextweb
Client 1 Client 2 Client 3 Client 4
Wide-bandwidth network
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 53
Architecture in Action: Product Line
Motivating example• A consumer is interested in a 35-inch HDTV with a built-in
DVD player for the North American market.
Such a device might contain upwards of a million lines of embedded software.
This particular television/DVD player will be very similar to a 35-inch HDTV without the DVD player, and also to a 35-inch HDTV with a built-in DVD player for the European market, where the TV must be able to handle PAL or SECAM encoded broadcasts, rather than North America’s NTSC format.
These closely related televisions will similarly each have a million or more lines of code embedded within them.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 54
Growing Sophistication of Consumer Devices
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 55
Families of Related Products
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 56
The Necessity and Benefit of PLs Building each of these TVs from scratch would
likely put Philips out of business Reusing structure, behaviors, and component
implementations is increasingly important to successful business practice • It simplifies the software development task
• It reduces the development time and cost
• it improves the overall system reliability
Recognizing and exploiting commonality and variability across products
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 57
Reuse as the Big Win Architecture: reuse of
• Ideas
• Knowledge
• Patterns
• engineering guidance
• Well-worn experience
Product families: reuse of • Structure
• Behaviors
• Implementations
• Test suites…
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 58
Added Benefit – Product Populations
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 59
The Centerpiece – Architecture
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 60
Analogies to Software Architecture
Hardware architecture• small number of design elements
• scale by replication of (canonical) design elements
Network architecture• focus on topology
• only a few topologies considered» e.g., star, ring, grid
Building architecture• multiple views
• styles
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 61
Architectural models Different architectural models may be produced
during the design process Each model presents different perspectives on the
architecture• Static structural model that shows the major system components
• Dynamic process model that shows the process structure of the system
• Interface model that defines sub-system interfaces
• Deployment model shows the relationship between system elements and hosts
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 62
An Example Static Model
Deployment Strategies Repository
Simulation Agent
Sym
me
tric
C_DataRepository
C_Troops Manager
C_Display Manager
C_AppManager
Deployment Advisor
Strategy Analyzer
Asymmetric
Asymmetric
Display Manager
Asymmetric
Asymmetric
S_Troops Manager
S_Display Manager
Asymmetric
Asymmetric
Asymmetric
Offensive Strategy
Defensive Strategy
Decision Module
DataRepository
Sym
me
tric
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 63
An example Deployment Model
Headquarters
Commander
Deployment Strategies Repository
Simulation Agent
Sym
met
ric
C_DataRepository
C_Troops Manager
C_Display Manager
C_AppManager
Deployment Advisor
Strategy Analyzer
Asymmetric
Asymmetric
Display Manager
Distributed Asymmetric
Distributed Asymmetric
Asymmetric
Asymmetric
Dis
trib
uted
S
ymm
etric
Soldier
S_Troops Manager
S_Display Manager
Distributed Asymmetric
Asymmetric
Distributed
S
ymm
etric
Asymmetric
Asymmetric
Offensive Strategy
Defensive Strategy
Decision Module
DataRepository
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 64
Key points The software architect is responsible for deriving
a structural system model, a control model and a sub-system decomposition model
Large systems rarely conform to a single architectural model
Key architectural concepts are components, connectors, and configurations
©Medvidovic, Van Vliet, Mejia-Alvarez Slide 65
Bibliography The material of this class come from the Software
Engineering class of Ian Sommerville, Nenad Medvidovic, and Han Van Vliet.