3. Software Architecture
• The fundamental organization of a system,
embodied in its components, their relationships to
each other and the environment, and the principles
governing its design and evolution
ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural
Description of Software-Intensive Systems
• Hundreds of definitions on CMU page:
www.sei.cmu.edu/architecture/definitions.html!
4. 1471 simplified
identifies
Stakeholder Architectural
concerns 1..* description
selects
addressed by consists of
1..* 1..* conforms to 1..*
Viewpoint 1
View
consists of
establishes methods for
1..*
1..* Model
5. Discuss
What are the elements of a software architecture?
What are the main operations on an architecture?
How can we decide that a system model is conform
to an architecture (or to an architectural style)?
11. Architectural description languages
• ADL: Overloaded acronym
I. The enterprise modeling meaning
II. The system engineering meaning
III. The software engineering meaning
• Examples
I. Archimate
II. SysML (UML profile for System Engineering)
III. ACME, Darwin, Wright
14. UML as an architectural language
• UML 1.* was based mostly on Classes and Objects
– Behavioral diagrams were not well linked to structure
• UML 2.* models enterprises and architectures in a much more
expressive and refined way
– Structural Models – Behavioral Models
– Architectural Models – Deployment Models
• UML 2.* is a powerful notational technology:
– Static and dynamic modeling elements include internal structure,
components, ports, behavioral features
– Behavioral diagrams all derive from a common behavioral model
– All features are designed to scale to large systems
– The new capabilities serve methodologists, enterprise modelers,
language designers, and tool builders
16. Models and views
• UML is a language to describe systems;
its main concepts are models and views
• A view is a perspective on the system by some
stakeholder; it is made of a number of different
diagrams, grouped in one ore more models
• A model is a container of three things:
classifiers, events, and behaviors; each of
them represents individuals in some view of the
system being modeled
17. UML Models
• A model contains classifiers, events, and behaviors
– A classifier describes a set of objects; an object is an
individual thing with a state and relationships to other
objects
– An event describes a set of possible occurrences; an
occurrence is something that happens that has some
consequence within the system
– A behavior describes a set of possible executions; an
execution is the performance of an algorithm according
to a set of rules
• UML models do not contain objects, occurrences, and
executions, because those things are the subject of
models, not their content
18. Example: a model for chess
chessboard
player position piece
K Q R B N P
19. Views on the chess model
• Player view • Architectural view?
• Designer view • Standard view?
• Tester view • Platform view?
• Coder view • Cost view?
• Deployer view • Service view?
• Maintenance view • Metamodeling view?
20. Metamodeling (or conformance) view
conformsTo
Chess Game
2 * *
player chessboard Agent board
32 *
chesspieces pieces
21. (4+1) Architectural View Model
I. Design (or logical) View: shows the structural view of a system.
This gives an idea of what a given system is made up of. Class,
object, communication, sequence diagrams form this view
II. Process View: shows the dynamic behavior of a system. The state,
activity, sequence, and collaboration diagrams are used in this view
III. Development (or implementation) View: shows the modules of a
given system and their dependencies modeled using the package
and component diagrams
IV. Physical (or deployment) View: is used to identify the deployment
modules for a given system
• Scenario (or Use case) View: Use case diagrams are used to view
a system as a set of functions, distinct activities or transactions
22. Architecture & 4+1 Views
Architecture - set of significant decisions concerning:
Organization of a software system
Selection of structural elements & interfaces from which a system is composed
Behavior or collaboration of elements
Composition of structural and behavioral elements
Architectural style guiding the system
vocabulary system assembly
functionality Design View Implementation View configuration mgmt.
behavior Use Case View
system topology
performance distribution
scalability Process View Deployment View delivery
throughput installation
23. Use Case View Logical View Physical View Deployment V.
Focus Expression of Expressing Representing Implementing Deployment of
requirements Behavior Structure Objects and Classes Executable Code
use case statechart class
diagrams diagrams diagrams
component
Diagram
object diagrams
sequence deployment
diagrams
diagrams diagrams
collaboration activity
diagrams diagrams
Actors Objects Modules Nodes
Use cases Classes Subroutines Modules
Element Classes Collaborations Tasks Main Programs
Collaborations Interactions Subsystems
Categories
UML diagrams model a system from different perspectives
24. Use case view
• Use Case Analysis is a technique to capture a
set of functional requirements or a business
process from some stakeholder’s perspective
• The use case view encompasses the system
behavior as seen by users, analysts, and testers
• It specifies the forces that shape the architecture
• The static aspects are depicted in use case
diagrams; the dynamic aspects in sequence and
activity diagrams
25. Design view
• The design view encompasses classes,
interfaces, and collaborations that define the
vocabulary of a system
• It supports the main data structures and the
functional requirements of the system
• Static aspects in class and object diagrams,
sometimes some packages are added; dynamic
aspects in interaction diagrams, especially
sequence diagrams
26. Implementation View
• The implementation view encompasses the
sources, components, and files used to compile,
assemble, and release a physical system
• It addresses configuration management
• Static aspects in package diagrams, including
dependency relationships; runtime issues and
interfaces in component diagrams
27. Process view
• The process view encompasses the threads and
processes defining concurrency and
synchronization inside an implemented system
• It addresses non functional requirements like
performance, scalability, and throughput
• Static aspects captured as in design view but
also with component diagrams; dynamic issues
in activity diagrams
28. Deployment view
• The deployment view encompasses the nodes
that form the system hardware topology
• It addresses the distribution, delivery, and
installation of a software product
• Static aspects in deployment diagrams;
dynamic aspects in interaction diagrams
29. Architectural Modeling in UML
Logical View Implementation View
id Business Entity (Client)
cd Users
«Include»
Business Entities::Employee dsXxx.i
+ Address: CHARACTER includes - DEFINE DATASET <dataset-def>:
+ City: CHARACTER
+ email: CHARACTER
includes
- EmployeeLanguage: CHARACTER
Architecture Entities::User + employmentEndDate: DATETIME-TZ
+ employmentStartDate: DATE
- UserEmail: CHARACTER + FirstName: CHARACTER «Program»
Architecture Entities:: «include»
- UserLogin: CHARACTER 1 1 + LastName: CHARACTER Language «includes» ClientXxx.p «includes» «Include»
- UserPassword: CHARACTER + MobilePhoneNumber: CHARACTER ttContext.i
etXxx.i
+ Notes: CHARACTER 1 - Description: CHARACTER
Use Case View
0..*
+ PhoneNumber: CHARACTER - Language: CHARACTER includes
0..* + Position: CHARACTER
+ PostCode: CHARACTER
+ createEmployee() : void
+ deleteEmployee() : void «Include»
+ findEmployee() : void proSIproxyStart.i
1
+ isAvailable() : LOGICAL
+ updateEmployee() : void ud Manage Employees - NEW GLOBAL SHARED VARIABLE ghProxySIproc:
Architecture Entities::UserGroups
+ validateEmployee() : void
- UserGroupDescription: CHARACTER AutoEdge System «realize PERSISTENT»
- UserGroupName: CHARACTER
Brow se Employees «Program»
proSIproxy.p
- NEW GLOBAL SHARED VARIABLE ghttProxySIproc: HANDLE
«use»
+ fetchWhere(CHARACTER, HANDLE, DATASET-HANDLE*) : void
Delete Employee
+ saveChanges(CHARACTER, HANDLE, CHARACTER*) : void
«use»
Dynamic View Deployment View
Update Employee
Manager
(from Actors)
«include»
sd Login
Create Employee Create User
«extend»
Client Server Gateway Security Session Context
dd Integration
Request("Security", "Login", ...)
HQ System
isValidUser(Login, password)
ValidUser
Sonic
[if Valid User]: createSession
Sonic Sonic Sonic Sonic
sessionID
Dealer Dealer Dealer Dealer
System 1 System 2 System 3 System n
[if valid user]: sessionID
(from Architecture Components) (from Architecture Components) (from Architecture Components) Architecture Components)
(from
Philippe Krutchen
30. Architectural analysis and design
• Architectural analysis involves organizing
analysis classes into packages
– Use cases
– Analysis classes
– Use case realisations
• Architectural design involves refining the
model elements of a package
– Design classes
– State machine diagrams
– Deployment diagrams
31. Architectural View
Veterans’ City Medic
Hospital Fire Dept Alert
VPN
City Internet Friendly
Hospital HMO
Patriot Acme Dr. Jones’
Ambulance Home Care Office
32. Zoomed, Still Architectural
Veterans’ Hospital MedicAlert®
Patient Customer
Database Database
Internet
Emergency Web
Room App Interface
Radiology Telecomms
Dept App Folks’ App
33. Enterprise Architecture View
Veterans’ Hospital Internal
Connectivity
Patient Emergency Detail
Database Room App Suppressed
Server
Radiology ER’s
Dept App Patient DB
Firewall
Radiology’s Pharmacy
Patient DB Database
Admitting Admitting’s Internet
Dept App Database
Billing Accounting
Dept App App & DB
34. Application Model
Emergency Room App
Triage Component
ER Patient DB
ER’s
Access Component
Firewall
ER Billing
Component
35. Component Model
Triage Component Then MDA
Generates
Triage Class 1 the application
Triage Class 1 and its connectivity
Attributes from this
detailed model
Triage Class 1
Operations So you know
that the application
Triage Operations conforms to the
Behaviors model,
connectivity works,
and changes to
Triage Class 2 any level model
work in the
real world
36. Static vs. dynamic models
• Static model
– Describes the static structure of a system
– Consists of a set of objects (classes) and their
relationships
– Represented as class diagrams
• Dynamic model
– Describes the dynamic behavior of a system, such as
its state transitions and interactions (message sends)
– Represented as statechart, activity, sequence, and
communication diagrams
38. Packages and components
• Packages organize model elements, but
have no realisation in the modeled system
• A package primarily provides a namespace
• Component diagrams describe black-box
(emphasizing interfaces) or white box
(emphasizing internal functions) model
architectures
39. Models, Views, and Diagrams
A model is a complete
Static views
description of a system
from a particular
perspective
Models Component
Diagrams
Interactions
Dynamic views
40. A package modeling a view
A model captures a view of a system, with a certain
purpose. It is a complete description of those
aspects of the system relevant to the purpose of the
model, at the appropriate level of detail
41. Models are documented by diagrams
Diagrams make up the
Use Case documentation of a model
Model
Design
Model
Remark: models are seldom shown in
diagrams
42. Example: analysis and design views
Use Case
Model
Analysis
Model Component
Diagrams Incl. subsystem e
package
Design
Model
Depl.
Model
Impl.
Model
Test
Model
43. Example: deployment and implementation models
Use Case
Model
Analysis
Model Component
Diagrams
Design
Model
Include classi e
componenti attivi
Depl.
Model
Impl.
Model
Test
Model
45. Example: Test model
Use Case
Model
Analysis
Model Component
Diagrams
Design
Model
The testing model
Depl. refers to all other
Model models and uses
their diagrams
Impl.
Model
Test
Model
48. Core Concepts
Construct Description Syntax
Model A view of a system, with a certain
purpose determining what aspects Name
of the system are described and at
what level of detail
Trace A dependency connecting model
«trace»
elements that represent the same
concept within different models.
Traces are usually non-directed
50. The use of models
• To give different views of a system to
different stakeholders
• To focus on a certain aspect of a system
at a time
• To express the results of different stages
in a software development process
• To describe other models
(eg metamodeling)
51. 4+1 architectural metamodel
Architectural
description
selects
consists of
1..4 validates 1..*
View 1..* Use Case
Logical Implementation Process Deployment
View View View View
53. Architectural modeling with UML
• Motivations
– Accessibility
– Use of UML tools
– Compatibility with design models
– Standardization
• An architectural model encompasses different views:
logical, dynamic, deployment
• All UML diagrams can be useful to describe aspects of
an architectural model
• Some UML diagrams are particularly effective for
architectural modeling:
– Package diagrams
– Component diagrams
– Deployment diagrams
54. Modeling software architectures
in UML: structural aspects
• Using basic modeling elements
– Classes
– Objects
– Packages
– Components
• Using special UML extensions
– Built-in
– Custom
56. UML for sw architectures
• UML is a well known industrial standard
• However, it has not been invented for
depicting architectures, so it may need
additional features
• UML can be extended
– Exploiting the built-in extension mechanisms
– Changing its metamodel
57. Extensions to model
architectures
• Strategy 1: use UML “as it is”
• Strategy 2: use UML built-in extension
mechanisms
– Eg. UML architectural profile
• Select meta-class semantically close to architectural
abstractions
• Define a stereotype and apply it to metaclass instances
• Define and use specific architecttural style composition rules
• Strategy 3: extend the UML metamodel
– Eg. Exploit a model driven approach
58. Strategy 1: “plain” UML
• Analysis of architectural requirements
• Develop a UML model
• Develop an informal architectural diagram
• Map domain classes to architectural
components
• Design component interfaces
• Model connectors
• Model architectures using class, object
and communication diagrams
60. A generic architecture (packages)
interface
User interface System interface
function
model
technical platform
ui-system dbms network
61. Strategy 2: Extending UML
Define a profile!
• Exploit existing constructs
– Eg. component, connector, subsystem, etc.
• Define stereotypes for new constructs to
model structural aspects of architectures
• Describe the behavioral semantics of the
new constructs using OCL and dynamic
diagrams
62. Strategy 2: Profiles
• A profile is a generic extension mechanism
for customizing UML models for particular
domains and platforms
• Profiles are defined using stereotypes,
tagged values, and constraints
• A profile is a collection of such extensions
that customizes UML for a particular
domain (eg. aerospace, healthcare,
financial) or platform (eg. J2EE, .NET)
68. Some important profiles
• CORBA www.omg.org/technology/documents/formal/profile_corba.htm
• EDOC (profiles for Java and EJB) www.omg.org/technology/documents/formal/edoc.htm
• MARTE (Modeling and Analysis of Real-Time and Embedded Systems) www.omgmarte.org
• SysML (profile for system engineering with UML) www.sysml.org
• RUP profile for Business Modeling www.ibm.com/developerworks/rational/library/5167.html
• SOAML (UML profile for SOA) www.omg.org/spec/SoaML
• UPDM Unified Profile for DoDaf/MoDaf www.updm.com
Some profiles are “officially” endorsed by OMG
See the list of OMG profiles in www.omg.org/technology/documents/profile_catalog.htm
70. A profile for SOA
www.ibm.com/developerworks/rational/library/05/419_soa/
71. OMG Service Oriented Architecture
• Participants provide and use service contracts via ports
• Participants can “play roles” in multiple services
architectures, defining their external requirements
• Each service contract they are bound to must interact
through a compatible port
• Participants are the types of “participant roles” in the services
architecture
72. Strategy 3
Change the metamodel!
• Add to the metamodel new architectural
constructs and constraints
• Define their architectural semantics
• Then follow an approach similar
– to Strategy 1 to model architectures
– to Strategy 2 to model architectural styles
74. From objects to models
Superclass Metamodel
inheritsFrom conformsTo
Class Model
instanceOf representedBy
Instance System
75. The UML metamodel
• The UML infrastructure describes the
UML metamodel
• OMG defined MOF (Meta Object Facility),
a standard technology for defining
metamodels
• The MOF has been primarily used for the
UML metamodel, but it is also the basis for
Model Driven Engineering
78. Summary
• Profiles can capture either domain knowledge or
architectural knowledge: they extend the metamodel
• UML is defined by a metamodel, that is it is defined
using UML itself
• In UML2.0 the metamodel is called “the infrastructure”
• The metamodel includes the definitions for views,
diagrams, and modeling elements
• UML can be extended to support architectures via
profiles (avoiding to change the metamodel)
• When based on metamodeling, architectural
specification can exploit “Model-driven Architecting”
79. Exercise
• Define a profile for a domain you know, eg
for soccer, for music, for a computer or an
operating system
80. Self test questions
• What is a model in UML?
• What is a profile?
• What is a metamodel?
• Using UML, how can we deal with
architectural issues?
81. References
• OMG, UML Infrastructure 2.3, 2010
• Cheesman & Daniels, UML Components A Simple Process for
Specifying Component-Based Software, Addison Wesley, 2000
• Garland & Anthony, Large-Scale Software Architecture. A Practical
Guide using UML, Wiley 2003
• Altunbay and others, Model Driven Development of Board Games,
TMODELS, 2009
• Cabot and Gomez, A simple yet useful approach to implementing
UML Profiles in current CASE tools, 2003
