6. Architectural Extraction
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.1
Roadmap
• Definitions
• Modeling software architecture with
UML
• Architectural Description
Languages
• Reflexion Models
• Source-code Views
• Conclusion and references
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.2
Software Architecture is
about…
• High-level design of the software
• Arrangements of larger parts of the
system.
• (subsystems, large components)
instead of classes and objects.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.3
Preliminary Definitions
• A system is a set of components that accomplishes a
specific function.
• 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.
• A component is an independently deliverable unit of
software that encapsulates its design and
implementation and offers interfaces to the out-side,
by which it may be composed with other components
to form a larger whole.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.4
Some Definitions
• [Shaw&Garlan] A Software Architecture
defines a system in terms of computational
components and interactions amongst those
components.
• Provides a design plan — a blueprint of the
system, and that is an abstraction to help
manage the complexity of the system. …The
purpose of the software architecture is not
only to describe the important aspects for
others, but to expose them so that the
architect can reason about the design.
Architecture.5
• …
© S. Demeyer, S. Ducasse, O. Nierstrasz
Standardization: IEEE 1471
Definitions
• Architecture is the fundamental organization of a
system embodied in its components, their
relationships to each other, and to the environment,
and the principles guiding its design and evolution.
• Architectural description is a set of products that
document the architecture.
• Architectural View is a representation of a particular
system or part of a system from a particular
perspective.
• Architectural viewpoint is a template that describes
how to create and use an architectural view. It
includes a name, stakeholders, concerns addressed
by the viewpoint, and the modeling and analytic
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.6
conventions.
Architectural Descriptions
• Make the architecture explicit
• Can be used for:
Training
Making
modifications
Helping Testers
Verification of requirements
Project Management
Operating a system
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.7
Architectural Patterns
• Capture solution to recurring
architectural design problems.
• Define a general set of element types
and their interactions.
• Examples:
Model-View-Controller
Reflection
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.8
Architectural Style
• [Shaw&Garlan] An Architectural Style defines
a family of systems in terms of a pattern of
structural organization. More specifically, an
architectural style defines a vocabulary of
components and connector types, and a set
of constraints on how they can be combined.
• Dominant architectural pattern = architectural
style.
• Examples:
 pipes
and filters
 layered architecture
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.9
Summary
•
•
•
•
Lots of definitions
Open for interpretation
Sometimes contradictory
Does not matter as long as:
Make
it explicit
Assign semantics
Describe as much as possible
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.10
Roadmap
• Definitions
• Modeling software architecture
with UML
• Architectural Description
Languages
• Reflexion Models
• Source-code Views
• Conclusion and references
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.11
Using UML to model
architectures
• Remember: models are not the end
goal, the deployed software system is!
• Models are for
Design
exploration: understanding existing
or creating new parts of the system.
Documentation: communication between
new and existing team members.
• Do not get stuck in ‘analysis paralysis’.
• Top-down approach.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.12
Using UML to model
architectures
• Key issue: managing complexity
 Use
case focused modeling: focus on use case or scenario.
 Element focused modeling: create views from the
perspective of a particular model element.
 Level of detail: should be ‘right’: not too abstract, certainly
not too detailed.
 Controlling the number of models: difference between
exploratory models and documentation models. Extract
detailed documentation models from code with tools.
 Use supplemental textual information: diagrams are not
always enough. Complement them with textual descriptions.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.13
Architectural Viewpoint
• Template for creating views
• Representation of an architecture that can be used to
guide construction, manage, explore, train personnel,
test, …
• Use it for:
 Capturing
design decisions.
 Capturing information about the runtime environment.
 Providing constraints on lower-level design.
 Providing input to the structure of the development
organization.
 Designing the system to meet non-functional requirements.
 Facilitating communication.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.14
Architectural Viewpoint Structure
• Name
• Purpose: what is modeled, and what for?
• When applicable: in what phase of the lifecycle can
it be used?
• Stakeholders: what is the audience for this
viewpoint?
• Modeling conventions: what kind of
diagram/technique type is used for the model?
• Scalability: How is the diagram used to be scalable?
• Relation to other views: what other views have to
remain consistent?
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.15
List of Viewpoints
• Like catalogs of design patters, architectural
viewpoints can be collected.
• Lists of viewpoints to help with specific
architectural development tasks.
• Split in different tables:
 Conceptual
and analysis viewpoints: highly
abstracted software descriptions.
 Logical design viewpoints: describe the
software design.
 Environment/Physical viewpoints: focus on the
environment and physical aspects of the software.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.16
Conceptual and analysis
viewpoints
Viewpoint
UML diagram
Description
Analysis Focused Class
Describe system entities in
response to a scenario.
Analysis
Interaction
Interaction
Interaction diagram between
objects for analysis.
Analysis Overall
Class
Combination of all classes
from all focused analysis
viewpoints.
Context
Use Case
Show the external system
actors and the system under
design.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.17
Logical design viewpoints
Viewpoint
UML diagram
Description
Component
Component
component communications.
Component
Interaction
Interaction
Interaction among
components.
Component State
State
Component(s) State
transitions.
Layered
Subsystem
Package
layering and subsystems
design.
Logical Data
Class
Critical data views for
integration.
Subsystem interface dependency
Class
subsystem dependencies
and interfaces.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.18
Environmental/Physical
Viewpoints
Viewpoint
UML
diagram
Description
Deployment
Deployment
Mapping of software to
hardware for distributed
systems.
Physical Data
Deployment
Physical view of a particular
database.
Process
Deployment
Show the processes of a
particular system instance.
Process State
State
Show the dynamic states of a
process.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.19
Example Viewpoint: Context
Viewpoint
Purpose
When
applicable
Model the set of actors with which the system
interacts and the interfaces between the system
and these entities.
Throughout the project lifecycle. Primarily
prepared during the first stages of design and
analysis, but is updated as information about
external interfaces changes.
Software Architecture Team, Software Systems
Engineering Team, Subsystem Design Leads,
Stakeholders Developers, Testers, System Engineers,
Marketing, or others who are interested in or
negotiate external interfaces.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.20
Example Viewpoint: Context
Viewpoint
Scalability
The system should always be located in the
middle of the view. The external actors should
be surrounding the system. If the number of
actors become too large, they may need to be
grouped into higher-level actors. Multiple
Context Views should only be used as a last
resort.
Relation to
other views
Should be consistent with other static views that
show external interfaces. For example, the
subsystem interface, component, process, or
deployment views.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.21
Example view using Context
Viewpoint
«External»
Other banking
Systems
ATM
Teller
«System»
Banking
System
Backup system
Web Customer
Phone/Pager
customer
Sysadmin
© S. Demeyer, S. Ducasse, O. Nierstrasz
Loan Officer
Other branch
Architecture.22
Example view using Context
Viewpoint
• Model complemented with table
containing actor descriptions.
• Table can also contain more
information, such as the estimated data
throughput for an actor, critical time
periods, …
• Model + table are combined in a
software architecture document.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.23
Summary: Using UML
• Models are not the goal!
• Use architectural viewpoints to create
architectural views relevant for your system.
• Do not use informal notations, but stick to the
UML diagram type appropriate for that
Viewpoint.
• Use Case tools or drawing tools to help
making and maintaining the diagrams.
• Augment models with textual descriptions that
can be more detailed.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.24
Roadmap
• Definitions
• Modeling software architecture with
UML
• Architectural Description
Languages
• Reflexion Models
• Source-code Views
• Conclusion and references
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.25
Architectural Description
Languages
ADLs
• formal languages for representing and
reasoning about software architecture.
• provide a conceptual framework and a
concrete syntax for characterizing
architectures.
• executable, or implemented in generalpurpose traditional programming
language.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.26
Common ADL Concepts Depicted
System
connector
component
component
role
port
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.27
Common ADL Concepts
• Component: unit of computation or
data store. Typically contains interface
(ports) and formal behavioral
description.
• Connector: architectural building block
used to model interactions among
components. Typically contains
interface (roles) and formal behavioral
description.
• Configuration: connected graphs of
components and connectors that Architecture.28
describe architectural structure.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Some ADLs
• Darwin: focuses on supporting distributed
applications. Components are singlethreaded active objects.
• Wright: underlying model is CSP, focuses on
connectivity of concurrent components.
• C2: component- and message-based
architectural style with concurrent
components linked together by connectors in
accordance with a set of style rules.
• Rapide: focuses on developing a new
technology for building large-scale,
distributed multi-language systems.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.29
Example: Wright
Configuration SimpleSimulation
Component WorldModel(map: Function)
Port Provide <provide protocol>
Computation <provide world model>
Component VehicleModel
Port Environment <value protocol>
Computation <Vehicle behavior>
Connector UpdateValues(n : 1.. )
Role Model1..n <1 model’s protocol>
Glue <data from one model to another>
Instances
Envt : WorldModel(<map>)
V : VehicleModel
Cn : UpdateValues(2)
© S. Demeyer, S. Ducasse, O. Nierstrasz
Envt
V
Cn
Architecture.30
Example: Wright Connector
(CSP)
Connector UpdateValues(n
: 1.. )
Role Model1..n = (open  Operate)  §
where Operate = request  newVal?y  Operate
 update!x  Operate
 close  §
Glue = Statev where Statev =
[] i:1..n  Modeli.open  Statev
[] [] i:1..n  Modeli.request  Modeli.newVal!v
 Statev
[] [] i:1..n  Modeli.update?x  Statex
[] [] i:1..n  Modeli.close  Statev
[] §
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.31
Summary: ADLs
• Formal approach.
• Real languages with semantics.
• Domain specific, depending on their
formal background.
• ADLs do not integrate well (different
languages).
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.32
Roadmap
• Definitions
• Modeling software architecture with
UML
• Architectural Description
Languages
• Reflexion Models
• Source-code Views
• Conclusion and references
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.33
Quote
Automated tools and build systems are
an essential part of creating large
systems. These systems often provide
the ability to analyze and understand
the details of the implementation far
better than UML diagrams.
— [Garland&Anthony]
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.34
Problem Description
• Given:
Source
code
High-Level model of that source code
• Then: How to help an engineer check
that model against the source code?
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.35
Solution: Reflexion Model
• Reflexion  Reflection!
• Semi-automated approach
• Repeat
 Define/Update
high-level model of interest
 Extract a source model
 Define/Update declarative mapping between highlevel model and source model
 System computer a software reflexion model
 Interpret the software reflexion model.
Until ‘happy’
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.36
Reflexion Approach
Reflexion Model
Mapping
High-Level Model
Reflexion
Model
Tools
Extraction
Specification
Source
Code
© S. Demeyer, S. Ducasse, O. Nierstrasz
Extraction
Tool
Source
Model
Architecture.37
High-Level Model
Describes boxes and arrows model of system.
Memory
HardwareTrans
VirtAddressMaint
User
VMPolicy
© S. Demeyer, S. Ducasse, O. Nierstrasz
KernelFaultHandler
Pager
FileSystem
Architecture.38
Mapping
• Relates source model entities to high-level
model entities.
• Example:
[ file= .*pager.*
mapTo=Pager ]
[ file= vm_map.*
mapTo=VirtAddressMaint ]
[ file=vm_fault\.c
mapTo=KernelFaultHandler ]
[ dir=[un]fs
mapTo=FileSystem ]
[ dir=sparc/mem.*] mapTo=Memory ]
[ file=pmap.*
mapTo=HardwareTrans ]
[ file=vm_pageout\.cmapTo=VMPolicy ]
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.39
Source Model
• Particular information extracted from source
code
• Calculated with Lightweight Source
extraction:
 Specifications
easy to write
 Flexible: few constraints on source
 Tolerant: source code can be incomplete, not
compilable, …
• Lexical Approach
• Intrinsically Approximate
• For every Source Model, a new scanner is
generated
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.40
Source Model Specification
Example
• Writing out C calls
[ <type> ] <functionName> \( [ { <formalArg> }+ ] \)
[ { <type> <argDecl> ; }+ ] \{
<calledFunction>
@ write ( functionName, “ calls “, calledFunction ) @
\( [ { <parm> }+ ] \) ( \) | ; )
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.41
Software Reflexion Model
• Indicates where the source model and
high-level model differ:
Convergences
Divergences
Absences
• Has to be interpreted by developer.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.42
Software Reflexion Model
Example
convergence
Memory
divergence
absence
HardwareTrans
VirtAddressMaint
User
VMPolicy
© S. Demeyer, S. Ducasse, O. Nierstrasz
KernelFaultHandler
Pager
FileSystem
Architecture.43
Summary: Reflexion Models
• Reflexion model shows where a highlevel model and a source model agree.
• Semi-automatic process
• Models involved
Source
model
High-level model
Reflexion model
• Fast
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.44
Roadmap
• Definitions
• Modeling software architecture with
UML
• Architectural Description
Languages
• Reflexion Models
• Source-code Views
• Conclusion and references
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.45
Source-code Views
• Goal: expressing architectures at a
sufficiently high-level of abstraction without
losing the ability to perform automated
conformance checking.
• How?
 Source-code
views
 Relations between views
 Tool to verify views and relations against source
code
• Source-code views and relations are
expressed in a logic programming language.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.46
Example: Soul’s rule-based
architecture
Working
Memory
Input
Knowledge
Base





creates
uses
uses
uses
uses

Results


creates
© S. Demeyer, S. Ducasse, O. Nierstrasz




Query
Interpreter
Rule
Selection
uses*


Architecture.47
Example: Subarchitectures
Query Interpreter
Working
InterMemory
pretation
Input

uses



© S. Demeyer, S. Ducasse, O. Nierstrasz
uses
Knowledge
SubstiBase
tution

creates
uses*
uses

Query
Interpreter
creates


 
uses
Results





uses*

Rule
Selection
Architecture.48
Source-code Views
• A source-code view
 Is
a set of source-code entities that address a
same concern
 One view can contain many entities
 Views may crosscut dominant implementation
decomposition
• A source-code entity
 Can
be any tangible language construct: method,
class, variable, …
 One source-code entity can reside in multiple
source-code views
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.49
Defining Source-code views
• Structure
 Name
 Comments
 Definition(s)
 Default
definition
• Definition can be defined
 Extensionally
= by explicit enumeration of their elements
 Intentionally = by declaratively describing their elements
• All definitions
 Should
yield the same extension
 This can be checked automatically
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.50
Source-code view example
view(soulPredicates,<byCategory,byHierarchy>).
viewComment(soulPredicates,
['This intentional view contains ALL classes that implement SOUL
predicates (i.e., Prolog-like predicates that may use Smalltalk code due
to language symbiosis).']).
default(soulPredicates,byCategory).
intention(soulPredicates,byCategory,?class) if
category(?category),
name(?category,?name),
startsWith(?name,['Soul-Logic']),
classInCategory(?class,?category).
include(soulPredicates,byCategory,[Soul.TestClassifications]).
intention(soulPredicates,byHierarchy,?class) if
…
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.51
Source-code view maps to source
code
Architecture
Mapping
Implementation

Rule
Selection
SOULBasicClause
qsfdxgf
SOULClauses
SOULQuery
qsfdxgf
uses*


creates
SOULCachedRule
SOULFact
qsfdxgf

uses

SOULRule
qsfdxgf


Knowledge
Base
uses*
SOULClause
Query
Interpreter
uses 
SOULGeneratePredicate
creates


Result
s
Input

uses


Working
Memory

SOULAbstractTerm
classifiedAs(method(’interpretation’), Method) :classifiedAs(class('soul'), Class),
interpretingProtocolName(ProtocolName),
protocolName(Protocol, ProtocolName),
methodInProtocol(Class, Protocol, Method).
SOULNamedTerm
SOULTerm
SOULTrueTerm
qsfdxgf
SOULSmalltalkConstantTerm
SOULTerms
qsfdxgf
SOULAdvancedSmalltalkTerm SOULCachedSmalltalkTerm
qsfdxgf
© S. Demeyer, S. Ducasse, O. Nierstrasz
qsfdxgf
SOULAndTerms
SOULOrTerms
qsfdxgf
Architecture.52
Software Views Relationships
• Binary relations between views
• Two parts:
 predicate:
the kind of relation that holds between
the elements, for example ‘uses’, ‘creates’,
‘accesses’, …
 Quantifier: how many elements should satisfy the
relation
• Are mapped to lower-level implementation
relationships.
• Can be simple (e.g. ‘uses’) or complex (e.g.
‘creates’ or ‘usesTrans’).
• Can be used in multiple ways (verificative,
Architecture.53
generative)
© S. Demeyer, S. Ducasse, O. Nierstrasz
Relationship Example

Rule
Interpreter
r 1
Asks
1
Clause
Selector
2
forall
exists
methodFilter
ruleInterpreter

methodFilter
asks_M_M
clauseSelection
forall(filteredIsClassifiedAs(ruleInterpreter, methodFilter,X1),
exists(filteredIsClassifiedAs(clauseSelector, methodFilter,X2),
asks_M_M(X1,X2)))
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.54
Differences with Reflexion
Models
• More complex relationships
• More complex mapping between
architectural components and the
implementation
• Abstraction facilities
• But — slower:
logic
programming slower than regular
expressions
Full parser versus lexical approach
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.55
Summary: Software Views and
Soul
• Express software architectures at high
level of abstraction
• Supports conformance check between
software architecture and source code
• Uses logic programming language to
obtain
Expressiveness
Abstraction
© S. Demeyer, S. Ducasse, O. Nierstrasz
facilities
Architecture.56
Roadmap
• Definitions
• Modeling software architecture with
UML
• Architectural Description
Languages
• Reflexion Models
• Source-code Views
• Conclusion and references
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.57
Conclusion
• Do not make meaningless boxes-andarrows diagrams: add semantics to
them.
• Automated tools and build systems are
an essential part of creating large
systems.
• Tools and techniques exist - invest time
in using them
UML-based
solutions
Architectural description languages
Reverse engineering tools (softwareArchitecture.58
reflexion models, views)
© S. Demeyer, S. Ducasse, O. Nierstrasz
References & further reading
• [Shaw&Garlan] M. Shaw and D. Garlan, Software Architecture:
Perspectives on an Emerging Discipline, Prentice-Hall, 1996.
• [Garland&Anthony] J. Garland, R. Anthony, Large-Scale
Software Architecture - A practical guide using UML, John Wiley,
2003.
• [Murp95a] G. Murphy, D. Notkin, K. Sullivan, Software Reflexion
Models: Bridging the gap between Source and High-Level
Models, Proceedings of SIGSOFT'95, 1995.
• [Mens99a] K. Mens, R. Wuyts, T. D'Hondt, Declaratively
Codifying Software Architectures using Virtual Software
Classifications, TOOLS-Europe 99, 1999.
© S. Demeyer, S. Ducasse, O. Nierstrasz
Architecture.59