© S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.1 6. Architectural Extraction.

© S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.1

6. Architectural Extraction


Roadmap•Definitions• Modeling software architecture

with UML• Architectural Description

Languages• Reflexion Models• Source-code Views• Conclusion and references


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.


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.


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.

• …


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 conventions.


Architectural Descriptions• Make the architecture explicit• Can be used for:

TrainingMaking modificationsHelping TestersVerification of requirementsProject ManagementOperating a system


Architectural Patterns• Capture solution to recurring

architectural design problems.• Define a general set of element

types and their interactions.• Examples:

Model-View-ControllerReflection


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


Summary• Lots of definitions• Open for interpretation• Sometimes contradictory• Does not matter as long as:

Make it explicitAssign semanticsDescribe as much as possible


Roadmap• Definitions•Modeling software

architecture with UML• Architectural Description



Using UML to model architectures

• Remember: models are not the end goal, the deployed software system is!

• Models are forDesign 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.


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.


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.


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?


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.


Conceptual and analysis viewpoints

ViewpointUML

diagramDescription

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.


Logical design viewpoints

ViewpointUML

diagramDescription

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 inter-face dependency

Class subsystem dependencies and interfaces.


Environmental/Physical Viewpoints

ViewpointUML

diagramDescription

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.


Example Viewpoint: Context Viewpoint

PurposeModel the set of actors with which the system interacts and the interfaces between the system and these entities.

When applicable

Throughout the project lifecycle. Primarily prepared during the first stages of design and analysis, but is updated as information about external interfaces changes.

Stakeholders

Software Architecture Team, Software Systems Engineering Team, Subsystem Design Leads, Developers, Testers, System Engineers, Marketing, or others who are interested in or negotiate external interfaces.


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.


Example view using Context Viewpoint

«System»BankingSystem

«External»Other banking

SystemsATM Teller

Web Customer

Other branchLoan OfficerSysadmin

Backup system

Phone/Pagercustomer


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.


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.


Roadmap• Definitions• Modeling software architecture

with UML•Architectural Description



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 general-purpose traditional programming language.


Common ADL Concepts Depicted

System

connector

portrole

componentcomponent


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 describe architectural structure.


Some ADLs• Darwin: focuses on supporting distributed

applications. Components are single-threaded 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.


Example: WrightConfiguration SimpleSimulation

Component WorldModel(map: Function)Port Provide <provide protocol>Computation <provide world model>

Component VehicleModelPort Environment <value protocol>Computation <Vehicle behavior>

Connector UpdateValues(n : 1.. )

Role Model1..n <1 model’s protocol>Glue <data from one model to another>

InstancesEnvt : WorldModel(<map>)V : VehicleModelCn : UpdateValues(2)

Envt

Cn

V


Example: Wright Connector (CSP)

(open request newVal?y

update!xclose

where Operate =

Operate Operate

§

§

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

[] §

Connector UpdateValues(n : 1.. )Role Model1..n =

Glue =

Operate)


Summary: ADLs• Formal approach.• Real languages with semantics.• Domain specific, depending on

their formal background.• ADLs do not integrate well

(different languages).




Languages•Reflexion Models• Source-code Views• Conclusion and references


QuoteAutomated 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]


Problem Description• Given:

Source codeHigh-Level model of that source code

• Then: How to help an engineer check that model against the source code?


Solution: Reflexion Model• Reflexion Reflection!• Semi-automated approach• Repeat

Define/Update high-level model of interestExtract a source modelDefine/Update declarative mapping

between high-level model and source modelSystem computer a software reflexion

model Interpret the software reflexion model.

Until ‘happy’


Reflexion Approach

Source Code

Extraction Tool

Source Model

Reflexion ModelTools

Mapping

High-Level Model

Reflexion Model

Extraction Specification


High-Level ModelDescribes boxes and arrows model of system.

Memory

HardwareTrans

KernelFaultHandler

Pager

FileSystem

VirtAddressMaint

User

VMPolicy


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\.c mapTo=VMPolicy ]


Source Model• Particular information extracted from

source code• Calculated with Lightweight Source

extraction:Specifications easy to writeFlexible: few constraints on sourceTolerant: source code can be incomplete, not

compilable, …

• Lexical Approach• Intrinsically Approximate• For every Source Model, a new scanner is

generated


Source Model Specification Example

• Writing out C calls[ <type> ] <functionName> \( [ { <formalArg> }+ ] \)

[ { <type> <argDecl> ; }+ ] \{

<calledFunction>@ write ( functionName, “ calls “,

calledFunction ) @ \( [ { <parm> }+ ] \) ( \) | ; )


Software Reflexion Model• Indicates where the source model

and high-level model differ:ConvergencesDivergencesAbsences

• Has to be interpreted by developer.


Software Reflexion Model Example

Memory

HardwareTrans

KernelFaultHandler

Pager

FileSystem

VirtAddressMaint

User

VMPolicy

convergence

divergence

absence


Summary: Reflexion Models

• Reflexion model shows where a high-level model and a source model agree.

• Semi-automatic process• Models involved

Source modelHigh-level model Reflexion model

• Fast




Languages• Reflexion Models•Source-code Views• Conclusion and references


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 viewsRelations between viewsTool to verify views and relations against source

code

• Source-code views and relations are expressed in a logic programming language.


Example: Soul’s rule-based architecture

Input

Query Interprete

r

Working Memory

Knowledge Base

Results

Rule Selection

uses

creates

usesuses

uses*

usescreates


Example: Subarchitectures

Query Interprete

r

Knowledge Base

InputWorkin

g Memory

Results

Rule Selectio

ncreatesuses*

usescreates

uses*usesuses

Inter-pretation

Substi-tution

Query Interpreter

uses


Source-code Views• A source-code view

Is a set of source-code entities that address a same concern

One view can contain many entitiesViews may crosscut dominant

implementation decomposition

• A source-code entityCan be any tangible language construct:

method, class, variable, …One source-code entity can reside in

multiple source-code views


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


Source-code view exampleview(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) ifcategory(?category),name(?category,?name),startsWith(?name,['Soul-Logic']),classInCategory(?class,?category).

include(soulPredicates,byCategory,[Soul.TestClassifications]).

intention(soulPredicates,byHierarchy,?class) if…


Source-code view maps to source code

classifiedAs(method(’interpretation’), Method) :- classifiedAs(class('soul'), Class), interpretingProtocolName(ProtocolName), protocolName(Protocol, ProtocolName), methodInProtocol(Class, Protocol, Method).

classifiedAs(method(’interpretation’), Method) :- classifiedAs(class('soul'), Class), interpretingProtocolName(ProtocolName), protocolName(Protocol, ProtocolName), methodInProtocol(Class, Protocol, Method).

ImplementationSOULClause

SOULCachedRule

SOULBasicClause

SOULQuerySOULClauses SOULRule

SOULFact

SOULAbstractTerm

SOULTermSOULGeneratePredicate SOULTrueTerm

SOULSmalltalkConstantTermSOULNamedTerm SOULTerms

SOULAndTerms SOULOrTermsSOULAdvancedSmalltalkTerm SOULCachedSmalltalkTerm

qsfdxgf

qsfdxgf qsfdxgf

qsfdxgf

qsfdxgf qsfdxgf

qsfdxgf

qsfdxgf qsfdxgf

Architecture Mapping

Inp

ut

Qu

ery

In

terp

rete

r

Work

ing

M

em

ory

Kn

ow

led

ge B

ase

Resu

lts

Ru

le

Sele

cti

on

cre

ate

su

ses*

uses

cre

ate

su

ses*

uses

uses


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, generative)


Relationship Example

forall(filteredIsClassifiedAs(ruleInterpreter, methodFilter,X1),

exists(filteredIsClassifiedAs(clauseSelector, methodFilter,X2),

asks_M_M(X1,X2)))

ruleInterpreter clauseSelection

forall exists

asks_M_M

RuleInterpreter

ClauseSelector

rrAsks1

methodFilter methodFilter

1 2


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


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 obtainExpressivenessAbstraction facilities




Languages• Reflexion Models• Source-code Views•Conclusion and references


Conclusion• Do not make meaningless boxes-and-

arrows 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 themUML-based solutionsArchitectural description languagesReverse engineering tools (software

reflexion models, views)


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.1 6. Architectural Extraction.

Documents