OORPT Object-Oriented Reengineering Patterns and Techniques 9. Architecture Recovery Prof. O. Nierstrasz

OORPTObject-Oriented Reengineering Patterns and Techniques

9. Architecture Recovery

Prof. O. Nierstrasz

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz

OORPT — Architecture Recovery

10.2

Roadmap

> What is Architecture?> Architecture Extraction> Formal Concept Analysis



10.3

References

> D. D'Souza, A. Wills, Objects, Components and Frameworks with UML, Addison-Wesley, 1999

> F. Buschmann, et al., Pattern-Oriented Software Architecture — A System of Patterns, John Wiley, 1996

> M. Shaw, D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice-Hall, 1996

> C. Riva, View-based Software Architecture Reconstruction, Ph.D. thesis, Technical University of Vienna, 2004.

> H. Gall, Architecture Recovery and Reference Architecture, U Zürich, presentation, 2004

> M. Pinzger, et al., “Architecture Recovery for Product Families,” PFE-5, LNCS 3014, Springer-Verlag, 2004.

> R. Kazman and S. J. Carriere, “Playing detective: Reconstructing software architecture from available evidence.,” Automated Software Engineering, April 1999.



10.4

Roadmap

> What is Architecture?— Viewpoints— Styles— ADLs

> Architecture Extraction> Formal Concept Analysis



10.5

What is Software Architecture?

The architecture of a system consists of:> the structure(s) of its parts

— including design-time, test-time, and run-time hardware and software parts

> the externally visible properties of those parts— modules with interfaces, hardware units, objects

> the relationships and constraints between them

in other words:— The set of design decisions about any system (or subsystem)

that keeps its implementors and maintainers from exercising “needless creativity”

— D’Souza, Wills



10.6

Roadmap





10.7

IEEE 1471-2000

> “A software 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.”

> “A system stakeholder is an individual, team, or organization with interests in, or concerns relative to, a system.”

> “A concern is an interest which pertains to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations as performance, reliability, security, distribution, and evolvability.”

> “A view is a representation of a whole system from the perspective of a related set of concerns.”

> “A viewpoint is a specification of the conventions for constructing and using a views. A pattern or a template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.”



10.9

Architectural Viewpoints

Run-time How are responsibilities distributed amongst run-time entities?

Process How many concurrent threads/processes exist; how do they they communicate and synchronize?

Dataflow How do data and tasks flow through the system?

Deployment How are components physically distributed?

Module How is the software partitioned into modules?

Build What dependencies exist between modules?

File How is the software physically distributed in the file system?



10.10

Roadmap





10.11

Architectural Styles

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.

— Shaw and Garlan



10.12

Some Classical Styles

Layered Elements in a given layer can only see the layer below. Callbacks used to communicate upwards

Client-Server Separate application logic from interaction logic. Clients may be “fat” or “thin”

4-Tier Server is further divided into generic part, business logic and legacy adaptor.

Dataflow Data or tasks strictly flow “downstream”.

Blackboard Tools or applications coordinate through shared repository.



10.13

Product Line Architectures

Reference family architecture

Global style for all the products. Fixes the architecture requirements, rules, patterns, component types, infrastructure etc.

Family architecture Families with similar UI styles, features, standards, hardware generations etc.

Lead product architecture

A reference product implementation, most typical of the family.

Copy product Products “copied” and adapted from the lead product.



10.14

Roadmap





10.15

Architectural Description Languages

> ADLs— Formal languages for representing and reasoning about

software architecture.— Provide a conceptual framework and a concrete syntax for

characterizing architectures.— Some are executable, or implemented in a general-purpose

programming language.



10.16

System

connector

portrole

componentcomponent

Common ADL Concepts



10.17

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.



10.18

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.

http://en.wikipedia.org/wiki/Architecture_Description_Languagehttp://en.wikipedia.org/wiki/Architecture_Description_Language



10.19

Roadmap

> What is Architecture?> Architecture Extraction

— Extract-abstract-present— Rigi, Dali, PBS, …— Reflexion models— Querying and Soul

> Formal Concept Analysis



10.20

Roadmap






10.21

Tilley et al., 1996; Krikhaar 1999

Extract-abstract-present

3. Abstraction

1. Definition of Architectural Concepts2. Data gathering

Develop

Sources of information:- Documentation- Experts- Source Code

ArchitecturallySignifcantConcepts

Extract

Low levelmodel

Source Code

1. Model Refinement2. Composition rules3. View Selection

ArchitecturalModel

DomainKnowledge Hierarchical graphs

UML logical diagramsMessage sequence chartsHTML reports

4. Visualisation

5. Re-document

Analyze & recordrationales

Rationales for design decisions

© Harald Gall, UniZH

Architecture Reconstruction



10.23

Extracting Architecture

> Various techniques— Human experts— Recognizing known patterns— Static and dynamic analysis— Clustering and data mining— Comparing products within a family



10.24

Roadmap






10.25

Rigi

Programmable reverse engineering environment—C parser; relational data import—Visualization of hierarchical typed

graphs—Graph manipulation, filtering, layout—Tcl-programmable—www.rigi.csc.uvic.ca/

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

http://www.rigi.csc.uvic.ca/



10.26

Dali Workbench

> Workbench built on Rigi, PostgreSQL, perl scripts …> Three techniques used:

— Architectural extraction from source artifacts— User-defined patterns— Visualization



10.27

Software Bookshelf

> A web-based paradigm for presentation and navigation of large software systems— PBS (Portable Bookshelf) is one implementation

> Extract-abstract-present— C fact extractor generates Rigi Standard Format (RSF) files— Reconstructors define tree-structure by assigning files to

subsystems— GROK relational calculator determines high-level relations and

visualizes as graphs

> Applications to Linux, Apache and Mozilla— swag.uwaterloo.ca/pbs/

http://swag.uwaterloo.ca/pbs/





10.28

Extraction AnalysisSource Code facts factsManipulation

facts

pictures, text, etc

SWAGkit

> Toolkit to extract, abstract and present Software Architectures— Pipeline architecture based on PBS and GROK— Mainly used to reconstruct module views— swag.uwaterloo.ca/swagkit/

http://swag.uwaterloo.ca/swagkit/






10.29

SWAGkit tools

Three categories of tools:> Fact extractors

— cppx - C++ fact extractor based on GNU g++ compiler. – One output file (TA) generated for each source file.

> Fact manipulators— Several grok scripts and C++ programs used to manipulate the

facts into a form that can be meaningfully analyzed – linking, abstracting, layout, containment

> Fact analyzers— lsedit - visualize system as navigable “box and arrow” diagrams.— Sgrep - query facts via a command line interface



10.30

GUPRO

> Integrated workbench of program understanding tools— Based on extract-abstract-present— Graph-based source model

– Graph querying, manipulation and browsing

— www.uni-koblenz.de/~ist/gupro.en.html

http://www.uni-koblenz.de/~ist/gupro.en.html







10.31

Roadmap






10.32

Reflexion models

> Semi-automated approach> Repeat

—Define/Update high-level model of interest—Extract a source model—Define/Update declarative mapping between high-level model

and source model—System computes a software reflexion model—Interpret the software reflexion model.

Until “happy”



10.33

Reflexion Approach

Source Code

Extraction Tool

Source Model

Reflexion ModelTools

Mapping

High-Level Model

Reflexion Model

Extraction Specification



10.34

Memory

HardwareTrans

KernelFaultHandler

Pager

FileSystem

VirtAddressMaint

User

VMPolicy

High-Level Model

> Describes boxes and arrows model of system.



10.35

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 ]



10.36

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



10.37

Source Model Specification Example

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

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

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

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



10.38

Software Reflexion Model

> Indicates where the source model and high-level model differ:— Convergences— Divergences— Absences

> Has to be interpreted by developer.



10.39

Software Reflexion Model Example

Memory

HardwareTrans

KernelFaultHandler

Pager

FileSystem

VirtAddressMaint

User

VMPolicy

convergence

divergence

absence



10.40

Roadmap






10.41

Soul

> Express source-code views and relations as logic programming queries

> 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



10.42

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



10.43

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

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

intention(soulPredicates,byHierarchy,?class) if…



10.44

Software Tomography

> Repository-based toolset— Detects and checks architectural layers— Uses metrics and graph-based queries to detect “bad smells”

and architectural violations— www.software-tomography.com

http://www.software-tomography.com/

Software Tomography

© Software Tomography GmbH, 2003, 2004



10.46

Feature-oriented analysis

> Select a feature and a use case> Step through scenarios and collect traces> Combine the traces with the high-level static view to

generate the feature view> Abstract the feature view by detecting interaction

patterns

The Dynamic Analysis Process

Visualisation

Static Model

Execute ascenario

Instrumentedsystem

Traces

Extract/Filter Abstract Present

A B C

M5

M6

M7

M8

M1-M4

M9-M12

Vertical abstraction

AB C

M1-M4

M7

M9-M12

abstractions

A B C

M1M2

M3M4

M9M10

M11

M12

M5

M6

M7

M8

Original MSC

Horizontal and Veritcal

AB C

Horizontal abstraction

M10

M11

M7

M2

M3


An Example of Feature ViewMSC_COMMANDS

FILE

CANVAS

DIALOGS

DATA_STRUCTURES

EXECUTION

GUI

msc_env_get

exec_initializeMsc

TREE_CREATE

HASH_CREATE

guisel_initBindings

exec_Command

file_loadUseCase

ADD_PARTICIPANTS

ADD_MESSAGES

exec_initialDraw

gui_initialDraw

exec_getVisibleParticipants

tree_children

DRAW_PARTICIPANTS

exec_getVisibleMessages

tree_children

exec_filterMessagesToDisplay

FILTERING_MESSAGES

DRAW_MESSAGES

gui_scaleCanvasToFit

exec_getVisibleMessages

tree_children

exec_filterMessagesToDisplay

FILTERING_MESSAGES

exec_getVisibleParticipants

tree_children

msc_env_set

GUI

CANVAS

DIALOGS

FILE

DATA_STRUCTURES COMMANDS

EXECUTION




10.49

Roadmap


— Detecting implicit patterns



10.50

Identifying Design Patterns

Template MethodLook for protected and abstract methods being overridden in subclasses (hook methods). The caller is often a template method.

Proxy, DecoratorLook for interfaces implemented by classes in different hierarchies. Look for delegation to instance variables of the same type.

Composite Look for instance variables whose type is the superclass.

Observer Look for methods “update” and “notify”.

Visitor Look for an “accept*” method.



10.51

ConAn: Detecting hidden contracts

> Concept analysis— Identify groups of entities (software artifacts) with common

properties (contracts)

> X-Ray Views— Understanding the internals of a class

> Inheritance Patterns — Analysing behavioral dependencies in a class hierarchy

> Collaboration Patterns— Detecting structural relationships in an object oriented systems

Gabriela Arévalo, “High Level Views in Object-Oriented Systems using Formal Concept Analysis,” Ph.D. thesis, University of Berne, 2005. Gabriela Arévalo, “High Level Views in Object-Oriented Systems using Formal Concept Analysis,” Ph.D. thesis, University of Berne, 2005.



10.52

Specification of Elements and Properties

Concept: Maximal groups of elements based on their common properties

Lattice: partial order over the concepts

{Pierre}, {Jazz, Pop, Rap}

Bottom

Top

{Houari, Petko}, {Rock, Jazz}

{Houari, Petko, Pierre}, {Jazz}

Concept Analysis: Definitions

Rock Jazz Pop Blues Rap

Houari True True

Petko True True

Yann-Gael True True

Pierre True True True

Mohamed True True

Gaby True True



10.53

Element: <add:>

Property: access: #firstIndex

Class: Ordered Collection

firstIndex

add:

attribute

defines

Code Representation

Abstraction of the lattice

Concept Analysis

CA Pre-Filters

CA Mapping

Source Code

Keep one access to an attribute in a method

Identify groups

X-Ray Views

Software Patterns

Inheritance Patterns

ConAn: Tool Architecture



10.54

Roadmap


— Detecting implicit patterns



10.55

P

Abstract A

Abstract X

B C

Y Z

T

DCollaboration Patterns: Common structural aspects between classes

Collaboration Patterns



10.56

(1,2)Sub (3,2)Sub (1,2)Acc (3,2)Acc (2)Abs

(C,A,P) True True True True

(C,A,B) True True True True

(Z,X,Y) True True True

(Z,X,P) True True True True

Tup

les

of c

lass

es

A

C P

2

1 3

A B C P X Y Z: all classes in a system

Elements: tuples of classes

Properties: relationships over the tuples. (i,j)relation and (i)feature

Using CA to detect Patterns



10.57

A A

A A

A A

Order = 3 Order = 4 Order = 3 Order = 4

A A

Order = 3 Order = 4 Order = 3 Order = 4

Subclass Star Attribute Star

CompositeBridge

Found Collaboration Patterns



10.58

License

> http://creativecommons.org/licenses/by-sa/2.5/

Attribution-ShareAlike 2.5You are free:• to copy, distribute, display, and perform the work• to make derivative works• to make commercial use of the work

Under the following conditions:

Attribution. You must attribute the work in the manner specified by the author or licensor.

Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one.

• For any reuse or distribution, you must make clear to others the license terms of this work.• Any of these conditions can be waived if you get permission from the copyright holder.

Your fair use and other rights are in no way affected by the above.

Attribution-ShareAlike 2.5You are free:• to copy, distribute, display, and perform the work• to make derivative works• to make commercial use of the work

Under the following conditions:

Attribution. You must attribute the work in the manner specified by the author or licensor.

Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one.

• For any reuse or distribution, you must make clear to others the license terms of this work.• Any of these conditions can be waived if you get permission from the copyright holder.

Your fair use and other rights are in no way affected by the above.

Documents

OORPT Object-Oriented Reengineering Patterns and Techniques 9. Architecture Recovery Prof. O. Nierstrasz