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

OORPTObject-Oriented Reengineering Patterns and Techniques

9. Architecture Recovery

Prof. O. Nierstrasz

OORPT — Architecture Recovery

Roadmap

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

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.

Roadmap

> What is Architecture?— Viewpoints— Styles— ADLs

> Architecture Extraction> Formal Concept Analysis

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

Roadmap

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

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?

Roadmap

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

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.

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.

Roadmap

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.

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.

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

Roadmap

> What is Architecture?> Architecture Extraction

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

> Formal Concept Analysis

Roadmap

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

Architecture Reconstruction

Extracting Architecture

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

Roadmap

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.

Dali Workbench

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

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

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/

Extraction AnalysisSource Code facts factsManipulation

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/

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

> 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

Roadmap

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”

Reflexion Approach

Source Code

Extraction Tool

Source Model

Reflexion ModelTools

Mapping

High-Level Model

Reflexion Model

Extraction Specification

Memory

HardwareTrans

KernelFaultHandler

FileSystem

VirtAddressMaint

VMPolicy

High-Level Model

> Describes boxes and arrows model of system.

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

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:— Convergences— Divergences— Absences

> Has to be interpreted by developer.

Software Reflexion Model Example

Memory

HardwareTrans

KernelFaultHandler

FileSystem

VirtAddressMaint

VMPolicy

convergence

divergence

absence

Roadmap

> 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

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 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…

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

Software Tomography

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

M9-M12

Vertical abstraction

M9-M12

abstractions

Original MSC

Horizontal and Veritcal

Horizontal abstraction

An Example of Feature ViewMSC_COMMANDS

CANVAS

DIALOGS

DATA_STRUCTURES

EXECUTION

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

CANVAS

DIALOGS

DATA_STRUCTURES COMMANDS

EXECUTION

Roadmap

— Detecting implicit patterns

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.

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.

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

{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

Element: <add:>

Property: access: #firstIndex

Class: Ordered Collection

firstIndex

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

Roadmap

— Detecting implicit patterns

Abstract A

Abstract X

DCollaboration Patterns: Common structural aspects between classes

Collaboration Patterns

(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

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

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

Subclass Star Attribute Star

CompositeBridge

Found Collaboration Patterns

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.

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

Documents

OORPT Object-Oriented Reengineering Patterns and Techniques 1. Introduction Prof. O. Nierstrasz

1 Object-Oriented Reengineering © S. Demeyer, S.Ducasse, O. Nierstrasz Lecture 8 Radu Marinescu Quality-Driven Code Restructuring

Reengineering agile

Oscar Nierstrasz | Curriculum Vitˆscg.unibe.ch/download/oncv/oncv.pdfOscar Nierstrasz | Curriculum Vitˆ October 4, 2019 1 Personal Data Name Oscar Marius Nierstrasz Residence Fluhmattweg

OORPT Object-Oriented Reengineering Patterns and Techniques X. CHAPTER Prof. O. Nierstrasz

Reengineering helpdesk

Travel reengineering

OORPT Object-Oriented Reengineering Patterns and Techniques 5. Software Visualization Prof. O. Nierstrasz

Software Reengineering & Evolution Serge Demeyer Stéphane Ducasse Oscar Nierstrasz

Reengineering

Oscar Nierstrasz - Portal

OORPT Object-Oriented Reengineering Patterns and Techniques 12. Analyzing Dynamic Behavior Orla Greevy & Adrian Lienhard

OORPT Object-Oriented Reengineering Patterns and Techniques 10. Testing and Migration Prof. O. Nierstrasz

Reengineering - 5

OORPT Dynamic Analysis

© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.1 5. Software Visualization Introduction SV in a Reengineering Context Static Code Visualization

© S. Demeyer, S. Ducasse, O. Nierstrasz Intro.1 1. Introduction Goals Why Reengineering ? Lehman's Laws Object-Oriented Legacy Typical Problems common

Mindset reengineering

Business Reengineering

Software reengineering