Modeling the Architecture
• Every software system has an architecture (a set of
principal design decisions) that may be captured by
models.
– Architectural “modeling” is the act of reifying (concretizing)
and documenting the design decisions.
– Architectural modeling notation is the language used for
capturing the design decisions.
------ and -----– Architectural model is:
• the artifact that captures all the design decisions, via modeling with
some notations, that comprise a system’s architecture.
Architectural Modeling
• Some “Key” decisions in modeling:
– Which design decisions and concepts should be modeled?
• Which ones are important & importance is based on what
criteria?
– To what level of depth and detail should the decisions be
modeled?
• Should the more important or the more complex or the larger
design decisions be modeled with deeper levels?
– To what level of rigor and formality should the decisions
be modeled?
• Which notation should we use and how formal a notation should
we use?
Remember that this should also includes a “cost-benefit “ tradeoff decision.
Some Modeling Related Concepts to Consider
•
•
•
•
•
Stakeholder-Driven Modeling
Basic architectural entities (concepts)
Elements of architectural styles
Static and dynamic aspects
Functional and non-functional aspects
Stakeholder-Driven Modeling
• It is clear that not every design decision is viewed with
same level of concern. It depends on the stakeholders of
the project and may also vary from project to project.
Thus modeling should be stakeholder driven using a
process (set of steps) such as:
1. Identify (by stakeholders) the relevant aspects of the software
to model
2. Categorize the aspects in terms of importance (based on some
criteria stated by stakeholders)
3. Identify the goals of modeling for each aspect (quality analysis,
ease of use, reduction of complexity, communications, etc.)
4. Select modeling notation (s) --- based on importance & “goal”
of modeling (e.g. UI - modeling language for “ease of use”)
5. Create the model
6. Use the model in a manner consistent with the modeling goals
Basic Architectural Entities (concepts)
• In architectural modeling, we need to include the following
main entities:
– Components
• Describe the basic functional building blocks and what functionality and data
are encapsulated in each component.
– Connectors
• Describe those basic building blocks that facilitate the interaction among the
functional components
– Interfaces
• Describes the points where the components and connectors interact with the
external world such as users, other systems, or other connectors.
– Configurations
• Describes the relations and associations among components and connectors.
– Rationale
• Describes the reasons behind the design decisions and what purpose various
entities serve.
Modeling these entities require some language , and we may have to use different
ones to best represent different entities. For example configuration may be best
expressed with a graph, but rationale may require using natural language.
Elements of Architectural Styles
• Architectural style is a design decision that is 1) applicable to a given
context, 2) constrain the design decisions to that context , and 3)elicit
beneficial properties from that resulting system. Thus architectural
style should be included in modeling because:
–
–
–
–
–
Clarifies about what is allowed and what is not
Makes it easier to distinguish design decisions
Reduces potential future architectural drift and erosion
Helps guide evolution of architecture
Captures cross-cutting (general) concerns (e.g. performance, security, etc.)
• “Style” model includes (some constraints):
– Specific elements (of components, connectors, and interfaces); these may be
facilitated by a modeling template
– “Types” of components, connectors, and interfaces that satisfy certain
system constraint
– Interaction constraints among the elements, such as in client-server
interaction using a prescribed protocol
– Behavioral constraints, including concurrency, on the elements using some
state transition diagram to depict a complete system
Static and Dynamic Aspects
• Static aspect of a system addresses those
characteristics of the system that does not change
over time such as (a) the number of components and
connectors and their structural topology or (b) what a
component is functionally responsible for
• Dynamic aspect of a system addresses the
characteristics of the system that change over time.
– It addresses the behavioral (execution) aspects of the
system and thus is more difficult to model. (e.g. real-time
trigger and process)
– It also addresses how the overall system (state) itself
changes over time.
Functional and Non-functional Aspects
• Functional aspects of a system captures what services
or functionalities are provided by the system. [comes
pretty naturally from stakeholder requirements]
• Non-functional aspects of a systems describes what
properties the system must have and how the
functionalities are delivered (e.g. performance,
security, reliability, etc.) [not easily transformed from
requirements]
*Note that sometimes a functional component is developed to satisfy a
non-functional aspect. (e.g. accessing the system needs to be secure --leading to a functional aspect of checking for user id and password or
putting access control on tables in database.)
Potential “Problems” of Architectural Models
• An architecture is a set of principal design decisions
made about the system; thus in a sense it is an
abstraction of the system. Thus, in capturing or
modeling the architecture, we need to be cognizant
of potential problems:
–
–
–
Ambiguity
Accuracy (correctness)
Precision (exactness)
Ambiguity
• Since architecture only captures the “principal”
design decisions ------- it may not be i) complete or
ii) deep enough, causing the architecture model to
be ambiguous.
– A model is ambiguous if it is open to more than one
interpretation.
• An architectural model that admits multiple
interpretations will lead to ambiguity and potential
errors in design.
1.This problem is often addressed through design inspections, and clarifications
should be provided in the design rationale section in a cost effective manner.
2. Beware that some architectural modeling notation (language) admits ambiguity.
Accuracy and Precision
• The architectural model should be, but may not be, accurate and precise
since it is an abstraction of the sytem.
– A model is accurate if it is correct (conforms to fact) or deviates from
“correctness” in a limited manner
– A model is precise if it is detailed, specific and exact
• Note that we can be wrong and be very detailed and exact (precise). Thus
between accuracy and precision, one should strive for accuracy before
precision.
e.g. Conversion rate between US. Dollar to Japanese yen on 3/5/2015:
$1 = 98.45 yen (accurate and precise) Assuming that 98.45
$1 = 98 yen (accurate but imprecise)
is the conversion rate
$1 = 365 yen (inaccurate and imprecise)
$1 = 365.78 yen (inaccurate but precise)
Modeling Complexity: Multiple Views & Mixed Content
• No single approach can capture all aspects of an architecture; thus different
aspects of architecture (functional, nonfunctional, structural, physical, etc.)
may need to be modeled using different approaches or perspective.
– An architectural view is a set of design decisions related by some common concern
– An architectural viewpoint is the perspective from which a view is taken
• A view is an instance of a viewpoint of a system, where a viewpoint is
associated with one common concern. Examples of viewpoints are:
–
–
–
–
–
Logical viewpoint : system entities and their relationships
Physical viewpoint: hardware entities and their relationship to system
Deployment viewpoint: logical entities mapped to physical entities
Behavioral viewpoint: system states and processing characteristics
Concurrency or parallelism viewpoint: concurrency and threading control
Comparing to Kruchten’s 4 + 1 ?
Krutchen
Logical
-----Process -----Physical -----Development
and Scenarios
authors
logical
behavioral; concurrency
physical; deployment
Views and Viewpoint
• Architectural Views and Viewpoints provide advantages such as:
– Limit the presentation to a cognitively manageable subset of the architecture
(the old decompose/separation of concern/modularity idea)
– brings related concepts together (old cohesion idea)
– Tailors to the needs of specific stakeholders
– Displays the information at various levels of abstraction within the viewpoint
• Views and viewpoints which contain the same information must be
consistent. Potential inconsistencies include:
– Two views or viewpoints directly contradict each other
– Two refinements of the same view or viewpoint contradict each other
– The static versus the dynamic aspects of the view or viewpoint contradict
each other
– Functional versus non-functional aspects of views do not meet the same
needs or contradict each other.
– Dynamic aspects of two views contradict each other.
Modeling Techniques and Languages (Notations)
• There are many different ways to model and many different notations to
use to capture the model, ranging from natural language to the highly
popular UML for OO design.
• In evaluating modeling technique and language one should consider the
following points:
–
–
–
–
–
–
–
–
–
–
Scope and purpose of the technique/language
Basic elements or concepts that are modeled
Styles of architecture that are supported or not supported
Extent of static and dynamic aspects of the architecture supported
Support for changes and reflecting dynamic changes of the architecture
How well is non-functional aspects supported, assuming functional aspects
are supported
How much support is there in checking for ambiguity and accuracy
How detailed can the system architecture be modeled to suffice precision
There probably
What viewpoints are supported
is not a one
How much view and viewpoint consistency is checked
modeling
technique/notati
on that can
satisfy all these
Wide Spectrum of Architectural/Design Modeling Languages
•
General:
–
–
•
Natural language (e.g. English)
Boxes and Lines (e.g. Power Point , vision tools)
OO based and most popular today:
–
Unified Modeling Language (UML) which includes 13 different diagrams:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Class diagram,
component diagram,
composite structure diagram,
deployment diagram,
object diagram,
package diagram;
activity diagram,
state transition diagram,
use case diagram;
communication diagram,
interaction diagram,
sequence diagram,
timing diagram-a specific kind of interaction diagram.
Architectural Description Languages
•
Some Architectural Description Language (ADL) which modeled components,
connectors, interfaces, and configurations:
– Darwin: for distributed or interconnected architecture modeling (Imperial College)
– Rapide: a language framework that contains a type language, arch def. language,
specification constraint language, and concurrent programming language used to
support large distributed systems (Stanford U.)
– Wright: component interface language that allows for interface checking (CMU)
– Koala: models consumer electronic domain-specific designs (Philips electronics)
– Weaves: a language for modeling concurrent, communicating components called “tool
fragments” (Aeorspace Corporation)
– AADL: models real-time, embedded system for avionic, automotive, and other
industries; outgrowth of Honewell’s MetaH (Honeywell, SEI-CMU, US Army)
– Acme: An extensible modeling language that allows modeling extensions to its 7
baseline constructs of components, connectors, ports, roles, attachments, systems, and
representations. Extensibility is provided via properties which are decorations applied to
one of the seven basic constructs (CMU and USC)
– ADML: XML based architecture description language whose syntax is derived from
Acme
– xADL: also an XML based language where extensions are introduced as first class
entities, not just as extensions to the basic constructs
DARWIN
• One of the “early” general-purpose ADL focused on:
– Components
– Interfaces
– Configuration (Composition)
• Darwin notation allows the modeling of
“interconnected components” and primarily
provides a structural description
Darwin Syntax Example
Component DataStore {
provide x-values;
}
Component Calculation {
require x-values;
provide calc-results;
}
Component UserInterface{
require x-values;
require calc-results;
}
Component AppSWE6653{
inst
UI: UserInterface;
C: Calculation;
D: DataStore;
bind
C.x-values - - D.x-values;
UI.x-values - - D.x-values;
UI.calc-results - - C.calc-results;
}
Darwin Graphical Representation
AppSWE6653
x-values
x-values
DataStore
UserInterface
calc-results
calc-results
x-values
Calculation
= requires
Note: that any component may be further decomposed
= provides
Acme
(another Architecture Description Language - ADL)
•
•
Primary Purpose: Provide an interchange format
for architectural development tools and
environment
Primary goals:
1. Provide a representational scheme that will permit
development of new tools --- for analyzing and
visualizing architectural structures
2. Provide foundation for developing new, possibly domain
specific ADL
3. Serve as a vehicle for creating conventions and standards
for architectural information
4. Provide expressive descriptions that are easy for human
to read and write.
Acme’s Basic Types of Entities
•
Acme’s 7 basic elements:
1.
2.
3.
4.
5.
6.
Component
Connector
3 Primary Types
System
Port – interfaces of the components
Roles – interfaces of the connectors
Representations – lower level description of
component/connector
7. Representation Maps – a mapping between more
detailed internal representation and an external
representation
Graphical Acme
system
component
connector
component
c1
c2
representations
role
port
Re-Map 1
Re-Map 2
Representation- maps
Acme in text form
System simple_one = {
component c1 = { port send-request }
component c2 = { port receive-request}
connector call1 = { roles {caller, receiver} }
attachments : { c1.send-request to call1.caller;
c2.receive-request from call1.receiver}
Architecture Analysis & Design Language (AADL)
• This design modeling language was initially targeted for the
description and analysis of systems for the avionic industry.
• It has expanded to facilitate a wide variety of systems; it is not
bound to any specific industry.
• The “fundamental” element in this language is the Component
which has a :
– unique name,
– set of properties,
– interface to other components and
– subcomponents
AADL Component
• Component is identified via its “type” & there are 3
categories of 10 predefined “types” of components
1. Application software:
•
•
•
•
•
Thread
Thread group
Process
Data
Subprogram
2. Execution platform:
•
•
•
•
Processor
Memory
Device
Bus
3. Composite:
• System
Graphical Representation of AADL Component types
data
process
thread
group
thread
device
bus
memory
processor
subprogram
Application Software
Execution Platform
system
Composite
Simple Example of a Component
Process Component
features
Flows
Properties
Component Implementation
subcomponents connections
call sequence
flows
modes
properties
AADL Component Type & Component Implementation
Component type &
identifier
- Features
- Flows
- Properties
Component Type is one of the
previous 10 types
- declares the interfaces & I/O via
Features (e.g. ports that are
synchronous calls, data queued, etc)
- declares specific info transfer
channels via Flow
- declares externally observable
properties via Properties (e.g.
“thread” type may execute
periodically, aperiodic event-driven,
in background, or with some timing
constraint, or with a device, etc.)
Component implementation
identifier
- Subcomponents
- Calls
- Connections
- Flows
- Modes
- Properties
-Subcomponents, Calls and Connections provide
the composition of the Component
-Flows specify end-to-end flow across subcomponents
-Modes indicate alternative operational flow, alternative
configuration, or alternative properties (e.g. normal,
backup-recovery, novice/expert, etc.)
-Properties specify properties that apply to all instances
of this component (e.g. must run on Apple OS)
More clauses in AADL Component and
Implementation
• “Extends” clause may be used in Component and
Implementation declarations to inherit characteristics
of another, original Component
– If used in Implementation declaration, Extends may be used
to specify multiple implementation for the same
component (e.g. implementation on MS OS, Unix, Apple OS
may have different performance, difference security, etc.)
• “Refine” clause may be used in Implementation
declaration to complete a partially specified
implementation (e.g. an implementation template)
Additional ADDL features
• Packages – allows declaration of groups of
components to be organized into separate units with
their own names (e.g. search methods)
• Property Set – allows a definition of a named group
of related sub-properties (e.g. DB security levels)
• Annex – allows the declaration of extensions to the
core language such as a Fault-Tree model for
reliability analysis