Michel Chaudron Universiteit Leiden - TU/ejohanl/educ/2II45/2010/TUE... · Michel Chaudron...

Assessing Architecture QualityAssessing Architecture QualityAssessing Architecture QualityAssessing Architecture Quality

Michel ChaudronMichel ChaudronUniversiteit Leiden

With slides from Lethbridge and Laganiere

Introducing ….� Michel Chaudron

� Ph.d. Leiden (Computer Science)

� 2 years at IT company (RWS & MinDef)

� 10 years at TU Eindhoven (SAN)

� 2 years in Leiden � 2 years in Leiden

program director M.Sc. ICT & Business

� Research Interests

� Software Architecture / Enterprise Architecture:

� Quality of Architecture, UML-metrics, Impact on Productivity/Agility, Use of Architecture in Offshoring

2MRV ChaudronSheet 2

Leiden

3MRV ChaudronSheet 3

Agenda

� What is Quality

� Requirements & Quality

� Software Metrics

� Metrics for Architecture Quality

4

MRV Chaudron

Sheet 4

� Metrics for Architecture Quality

� Measure quality of architecture/design

� Feel free to raise questions during the lecture (raise your hand)

What is quality?

5

Now for software

Perspectives on quality

� Manufacturing-based (conformance to specs)

� Product-based (based on attributes of the software)

� User-based (“fitness for use”)

©2008 John Wiley & Sons Ltd.www.wileyeurope.com/college/van vliet 6

� Transcendent

(“I really like this program”)

� Value-based (balancing time and cost vs profits)

What is Quality of Software?

7

MRV Chaudron

Sheet 7

What is Quality of Software?

� Absence of defects?

� program does not crash

� computes correct output Formal

Methods

8

MRV Chaudron

Sheet 8

� We cannot establish the absence of defects, only their presence.

� We can count the number of defects we find after X hours of testing

ISO 9216 Quality Model

9

MRV Chaudron

Sheet 9

Quality ModelsExisting models

Boehm McCall

ISO 9126 Dromey

…

� Decomposition of characteristics� Bottom level: metrics

� Differences in � Relations between

characteristics

� Vocabulary

Boehm’s Quality Model

McCalls Quality Factors and Criteria

11

MRV Chaudron

Sheet 11

Boehm’s Quality tree

12

MRV Chaudron

Sheet 12

� Do it yourself: Goal-Question-Metric

SW-CMMMIL-Q -9858

Trillium Baldrige

IEEE Stds. 730,828829, 830,1012,1016

1028,1058,1063ISO 15504*(SPICE)

People CMM

IPD-

SDCCR

SCE

NATO AQAP1,4,9

BS

MIL-STD-498

DOD-STD-2167A

DOD-STD -7935A

SDCE

EIA/IEEE

MIL-STD-1679

EQA

CMMI*

PSP

SA-CMM

DOD-STD-2168

FAA-iCMM

SW-CMM

Frameworks for Software Quality

13

MRV Chaudron

Sheet 13Also see www.software.org/quagmire

TrilliumIPD-CMM*

DODIPPD

SECAMAF IPD Guide

BS5750

MIL-STD-499B*

ISO/IEC12207

IEEE1220

ISO 10011

SE-CMMSECM*(EIA/IS 731)

EIA/IS632

ISO 9000Series

EIA/IEEEJ-STD-016

IEEE/EIA12207

EIA 632*

IEEE 1074

TickITSSE-CMM

ISO 15288*

* Not yet released

Q9000

quag14d: 5 June 1998

iCMM

DO-178B

Courtesy Sarah Sheard, SPC

Software Quality Attributeshttp://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.html

14

MRV Chaudron

Sheet 14

Feasibility study

The waterfall model with QA

User Requirements

System Design

Analysis

QA

QA

QA

QA = Quality Assurance

Corrections

15

MRV Chaudron

Sheet 15

System Design

Coding

Operation

Testing

Program Design

QA

QA

QA

Corrections

Corrections

Corrections

CorrectionsProject Management- Planning and control- Risk Management- People Management

Problems with standards / QA� They may not be seen as relevant

and up-to-date by software engineers.

� They often involve too much bureaucratic form filling.

� If they are unsupported by software� If they are unsupported by softwaretools, tedious manual work is often involved to maintain the documentation associated with the standards.

Some more examples of *ilitiesAccessibility, Administrability, Understandability, Generality,

Operability, Simplicity, Mobility, Nomadicity, Portability,

Accuracy, Efficiency, Footprint, Responsiveness, Scalability,

Schedulability, Timeliness, CPU utilization, Latency,

Throughput, Concurrency, Flexibility, Changeability,

Evolvability, Extensibility, Modifiability, Tailorability,

17

MRV Chaudron

Sheet 17

Evolvability, Extensibility, Modifiability, Tailorability,

Upgradeability, Expandability, Consistency, Adaptability,

Composability, Interoperability, Openness, Integrability,

Accountability, Completeness, Conciseness, Correctness,

Testability, Traceability, Coherence, Analyzability, Modularity,

Reusability, Configurability, Distributeability, Availability,

Confidentiality, Integrity, Maintainability, Reliability, Safety,

Security, Affordability, Serviceablility, …

Design is a balancing act

Resource use

Performance

Reliability

Timeliness

SystemSystemSystemSystem

Security

… …

…

18MRV ChaudronSheet 18

Resource useCPU, Mem, Netw

Essential system engineering problem:

� a plurality of contradictory goals

� a plurality of means (tactics, technology, process)

each of which provides a varying degree of help or hindrance in

achieving a given goal

Engineering is constrained in resources

QUALITY

QUANTITY

OF FUNCTIONALITY

‘SIZE’SCHEDULE /

TIME

MRV Chaudron

Sheet 19

‘SIZE’ TIME

These factors are closely related to each other

Faster time to market � reduce quality or quantity

Increase features � allow more time or reduce quality

Improve quality � allow more time or reduce quantity

Why Care about Quality during Design?

As a project progresses,more and more workdepends on earlier decisions.

Cost of Defect Repair

Cost of repair increases exponentially

MRV Chaudron

Sheet 20

Defects should be eliminated as soon as possible after their introduction

Economic Model for Cost of Quality

From: H. Krasner, Cost of Quality, 1998

Perfection is not economical

Requirements and Quality

A system is of good quality when it meets its requirements

22MRV ChaudronSheet 22

Why Software Projects Fail

MRV Chaudron

Sheet 23

Related to

Requirements

Engineering

Related to

Requirements

Engineering

Essentially lack of defining goals!

Requirements on Requirements

SSSS SpecificSpecificSpecificSpecific

To-the-point, precise

MMMM MeasurableMeasurableMeasurableMeasurable

Quantifiable and verifiable

AAAA AcceptableAcceptableAcceptableAcceptable (to the stakeholders)

MRV Chaudron

Sheet 24

AAAA AcceptableAcceptableAcceptableAcceptable (to the stakeholders)

Accessible, understandable (for the user)

Achievable (technically/planning/economically)

RRRR RealisticRealisticRealisticRealistic

Deducible to the real business drivers

TTTT TestableTestableTestableTestable

Quality of Requirements

� Complete ?

� Consistent ?

� Fixed ?

� Prioritized ?� Prioritized ?

� Traceable ?

� Managed change

� versioning?

25MRV ChaudronSheet 25

Software Metrics

� Metrics and Models in Software Quality Metrics and Models in Software Quality Metrics and Models in Software Quality Metrics and Models in Software Quality

EngineeringEngineeringEngineeringEngineering (2nd edition)

Stephen H. Kan

Addison Wesley, 2002

26

MRV Chaudron

Sheet 26

� Software Metrics Software Metrics Software Metrics Software Metrics A Rigorous & Practical ApproachA Rigorous & Practical ApproachA Rigorous & Practical ApproachA Rigorous & Practical Approach

Norman E. Fenton & Shari Lawrence Pfleeger, 2nd ed. International Thomson Computer Press, 1997

If you cannot measure it, then it is not scienceIf you cannot measure it, then it is not scienceIf you cannot measure it, then it is not scienceIf you cannot measure it, then it is not science

In physical science the first essential step in the direction of learning any subject is to find principles of numerical reckoning and practicable methods for measuring some quality connected with it. I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it;

but when you cannot measure it, when you cannot express it in numbers, your knowledge cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Science, whatever the matter may be.

— Sir William Thompson, Lord Kelvin (1824Sir William Thompson, Lord Kelvin (1824Sir William Thompson, Lord Kelvin (1824Sir William Thompson, Lord Kelvin (1824----1907) 1907) 1907) 1907) From 'Electrical Units of Measurement', a lecture delivered at the Institution of Civil Engineers, London (3 May 1883), Popular Lectures and Addresses (1889), Vol. 1, 73. Quoted in American Association for the Advancement of Science, Science (Jan-Jun 1892), 19191919, 127.

Why measure?

Gilb’s principle of fuzzy targets:

Projects without clear goals

will not achieve goals clearly

Tom DeMarco

You can neither predict nor control

what you cannot measure

• Measure:Measure:Measure:Measure: A quantitative indication of the extent, amount, dimension, capacity or size of some attribute of a product or process.• A single data point (e.g. number of defects from a single

review)

• Measurement:Measurement:Measurement:Measurement: The act of determining a measure

Measurement, Metrics, IndicatorsMeasurement, Metrics, IndicatorsMeasurement, Metrics, IndicatorsMeasurement, Metrics, Indicators

maat

meten

29

MRV Chaudron

Sheet 29

• Measurement:Measurement:Measurement:Measurement: The act of determining a measure

• Metric:Metric:Metric:Metric: A measure of the degree to which a system, component or process possesses a given attribute.• Metrics relate measures (e.g. Average number of defects

found in reviews)

• Relate data points to each other

• Indicator:Indicator:Indicator:Indicator: A metric or series of metrics that provide insight into a process, project or product.

meting

Why Measure?

� Understanding

� Controlling

� Comparing

Predicting

Improvement

� Predicting

� Metrics are

�objective

�(often) automatically collectable

Motivation for Metrics� Estimate the cost & schedule of projects

Bidding

� Evaluate the productivity impacts of tools and techniques

Establish productivity trends over time� Establish productivity trends over time

� Monitor/Improve software quality

� Forecast future staffing needs

� Anticipate and reduce future maintenance needs

Metrics Domains� processprocessprocessprocess

� duration or effort of tasks,

� no. of changes in requirements

� resourcesresourcesresourcesresources� no. of staff working on a task;

� staff overturn� staff overturn

� staff experience/skills

� productproductproductproduct� requirements document

� architecture document

� design document

� implementation (code, libraries)

• size (lines of code)

• complexity

• functionality

Project MetricsProject MetricsProject MetricsProject Metrics

• Effort/time per SE task

• Defects detected per review hour

• Scheduled vs. actual milestone dates

• Changes (number) and their characteristics

Distribution of effort on SE tasks

33

MRV Chaudron

Sheet 33

• Distribution of effort on SE tasks

Example Process MetricDistribution of effort over different activities in development

Product MetricsProduct MetricsProduct MetricsProduct Metrics

• focus on the quality of deliverables

• measures of analysis model

• complexity of the design

• internal algorithmic complexity

architectural complexity

35

MRV Chaudron

Sheet 35

• architectural complexity

• data flow complexity

• code measures (e.g., Halstead)

• measures of process effectiveness

• e.g., defect removal efficiency

Algorithmic Complexity

• McCabe’s Cyclomatic Complexity

is based on number of paths through a flow graph (explained later in testing lectures)

• Relationship between complexity and defects

36

MRV Chaudron

Sheet 36

• Relationship between complexity and defects and maintainability (tf. time to repair defects)

Size and Complexity Metrics II

� McCabe’s cyclomatic number

�Measures Complexity of a module

�Heuristic: should be <10G is control flowgraph

e edges and n nodes

37

MRV Chaudron

Sheet 37

e edges and n nodes

V(G) = e – n + 2

(number of linearly independent paths in G)

Here: V(G) = 12 – 10 + 2 = 4

More simply, d is number of decision nodes

V(G) = d + 1

Quality Metrics

What: Testability, extensibility, maintainability, error-proneness, …

How:� Coupling, Cohesion

� Complexity

38

MRV Chaudron

Sheet 38

� Complexity

� Inheritance metrics

Design Principles

� Simplicity

� Separation of Concerns

� Information Hiding

� Modularity� Modularity

� Keep things that belong together in a single place

How to assess?

39MRV ChaudronSheet 39

Separation of Concerns

� Separate What from How

� The interface of a component exposes what

function it can perform, not how.function it can perform, not how.

� The ‘how’ is the information-hiding ‘secret’

40MRV Chaudron

Sheet 40

Dependency: Coupling

Coupling is the degree

of interdependence between modules

Heuristic: minimize coupling between modules

high coupling low coupling

What is a dependency?

� Component A requires B for it to work�Functional coupling

� A change in module B requires change in module A

Run-time

42

MRV Chaudron

Sheet 42

A change in module B requires change in module A

� Implementation coupling

�Typically requires: re-testing A & B

Development-time

� There is coupling between two classes AAAA and BBBB if:

�AAAA has an attribute that refers to (is of type) BBBB.

�AAAA calls on services of an object BBBB. �AAAA calls on services of an object BBBB.

�AAAA has a method which references BBBB

(via return type or parameter).

�AAAA is a subclass of (or implements) class BBBB.

43Chapter 9: Architecting and designing software

This is not an exhaustive definition

Dependency: Cohesion

Cohesion is concerned with the interactions

within a module

Heuristic: Keep things together that

belong together.

High cohesion within a

module is good

low cohesionhigh cohesion

Coupling and CohesionCoupling and CohesionCoupling and CohesionCoupling and Cohesion

� CouplingCouplingCouplingCoupling is the degree of interaction between modules.

� CohesionCohesionCohesionCohesion is a measure of the coherence of a module amongst the pieces of that module.module amongst the pieces of that module.

� You want high cohesion and low coupling

45MRV ChaudronSheet 45

� Modulariteit = Isolatie

� wat binnen zit, moet binnen blijven

46MRV ChaudronSheet 46

Spaghetti – absence of structure

47MRV ChaudronSheet 47

An edge running from the node aaaa to the node bbbbrepresents a call of function bbbb from function aaaa

Belang van modulariteit

� Software qualities

�Correctheid, robuustheid, betrouwbaarheid e.d

⇒ goede requirements specification

Onderhoudbaarheid, uitbreidbaarheid, �Onderhoudbaarheid, uitbreidbaarheid, herbruikbaarheid en interoperability

⇒ goede software architectuur

� Software architectuur

�Modulaire structuur (modules en relaties)

Benefits of Low Coupling/Dependencies1. Modules are easier to replace

2. fewer interconnections between modules reduce

time needed for understandingunderstandingunderstandingunderstanding the modules and

interactions

3. fewer interconnections between modules reduce the 3. fewer interconnections between modules reduce the

chance that changeschangeschangeschanges in one module cause problemsproblemsproblemsproblems

in other modules, which enhances reusability

4. fewer interconnections between modules reduce the

chance that a fault in one module will cause a failurefailurefailurefailure

in other modules, which enhances robustness

49Chapter 9: Architecting and designing software

Page-Jones, M. 1980. The Practical Guide to Structured Systems Design. New York, Yourdon Press, 1980.

. x x x x x

x . x x x x x x x x x

Drive x x . x x x

System x x x . x x x x x x x x

x x . x

x x x x . x x x

x x x . x x

x x x . x x x x

x x x . x x x x x

Main x x x . x x x

Board x x x x x x x x . x x x x x

x x x x x . x x

x x x x x x . x x x

x x x . x

Design Structure Matrix Map of a Laptop Computer

Dependencies between subsystems

Relates to

architecture

conformance

50Chapter 9: Architecting and designing software©

Lethbridge/L

x x x . x

x x x . x x x

x x x x . x x x x

LCD x x x . x x

Screen x x x x . x x x

x x x x x x x . x x x

x x x . x

x x x x . x x x x

x x x . x x x x

x x x x x . x x x

Packaging x x x x . x x

x x x x x . x x

x x x x . x x

x x x x x .

x x x x x .

Graphics controller on Main Board or not?

If yes, screen specifications change;

If no, CPU must process more; adopt different interrupt protocols

Design Structure Matrix Map of a Modular System

. x x x x

x . x x

Design x . x x Design Rules Task Group

Rules x x . x

x x x .

x . x x x

x x . x x x

Drive x x x x . x

System x x x x x . x x Hidden Modules

x x x . x many Task groupsx x x x .

x . x x

x x x x x . x x

x x . x x x x

Main x x x x x . x x

Board x x x x x x x . x x

x x x x x . x

51Chapter 9: Architecting and designing software©

Lethbridge/L

x x x x x . x

x x x x x x . xx x x x x .

x x . x x x

x x x . x x x

LCD x x x . x

Screen x x x x x . x x

x x x x x . xx x x x x x .

x x . x x x x

x x x . x x x x

x x x . x x x

Pack- x x x x x x . x x

aging x x x . x x

x x x x x . x x

x x x x x .x x x x x x .

x x x x x x . x x x xSystem x x x x x x x x . x x System

Testing x x x x x x x x x . x x x Integration

& Integ- x x x x x x x x x x x x and Testing

ration x x x x x x x x . x Task Groupx x x x x x x x x x x .

DSM of Mozilla before and after redesign

number

of files

52Chapter 9: Architecting and designing software©

Lethbridge/L

Formerly Mozilla was the commercial Netscape Navigator, then released into open source.

From: Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code, Alan MacCormack, John Rusnak, Carliss Baldwin, Harvard Business School, draft October 1st 2005

1.3 dependencies per KSLOC2.4 dependencies per KSLOC

Architecture / Design Metrics

� Weighted Methods per Class (WMC)

� Depth of Inheritance Tree (DIT)

� Number of Children (NOC)

� Coupling between Objects (CBO)� Coupling between Objects (CBO)

� Response for a Class (RFC)

� Lack of Cohesion in Methods (LCOM)

Metrics Suite by Chidamber & Kemerer (1993)

Object-oriented metrics

Object-oriented

metric

Description

Depth of inheritance

tree

This represents the number of discrete levels in the inheritance tree where sub-

classes inherit attributes and operations (methods) from super-classes. The

deeper the inheritance tree, the more complex the design. Many di fferent object

classes may have to be understood to understand the object classes at the leaves

of the tree.

Method fan-in/fan-

out

This is directly related to fan-in and fan-out as described above and means

essentially the same thing. However, it may be appropriate to make a

distinction between calls from other methods within the object and calls from

external methods.

Weighted methods

per class

This is the number of methods that are included in a class weighted by the

complexity of each method. Therefore, a simple method may have a complexity

of 1 and a large and complex method a much higher value. The larger the value

for this metric, the more complex the object class. Complex objects are more

likely to be more difficult to understand. They may not be logically cohesive so

cannot be reused effectively as super-classes in an inheritance tree.

Number of

overriding

operations

This is the number of operations in a super-class that are over-ridden in a sub-

class. A high value for this metric indicates that the super-class used may not be

an appropriate parent for the sub-class.

Example: Before Refactoring

CouplingDynamic Coupling

Method Calls

Saat 7 10 25

55

MRV Chaudron

Sheet 55

Saat 7 10 25

Stat.-Filter 0 3 0

Stat.-Calculator 0 3 0

Analyser 0 4 0

DB-Checker 0 2 0

DB-Filler 0 5 0

DB-Creator 0 2 0

Parser 0 3 0

Example: After Refactoring

CouplingDynamic Coupling

Method Calls

Saat 2 2 2

56

MRV Chaudron

Sheet 56

Stat.-Filter 1 2 1

Stat.-Calculator 0 2 0

Analyser 3 3 12

DB-Checker 0 1 0

DB-Filler 1 4 10

DB-Creator 0 1 0

Parser 0 1 0

Façade pattern

Façade

Clientclasses

57

MRV Chaudron

Sheet 57

Note the effect on the fan-in/coupling of the component

Distribution of Coupling ?

nu

mb

er o

f cl

ass

es

coupling

nu

mb

er o

f cl

ass

es

System of 100+ classes

Distribution of Coupling

150

200

250

num

ber

of

cla

sses

59

MRV Chaudron

Sheet 59

0

50

100

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49

coupling

num

ber

of

cla

sses

System of about 140 classes

Selective QA: Use thresholds� Heuristic (e.g. DIT < 7)

� Mean + 2 * StDev

� Distribution dependent

140

160

Number of Methods per Class

60

MRV Chaudron

Sheet 60

0

20

40

60

80

100

120

1 8 15 22 29 36 43 50 57 64 71

Façade pattern

Façade

Clientclasses

61

MRV Chaudron

Sheet 61

Note the effect on the fan-in/coupling of the component

Complexity: Fan-in & Fan-out

Fan-in = no. of ingoing dependencies

Fan-out = no. of outgoing dependencies

Heuristic: a high fan-in/fan-out indicates a high complexity

MetricView: Graphical Tool forDeveloper Feedback

http://www.win.tue.nl/empanada/metricview/

MRV Chaudron

Sheet 63

UML model

Visualization of model + metricsQuality Metrics/Rules• Completeness• Consistency• Conventions

Analysis ToolAnalysis ToolAnalysis ToolAnalysis Tool

MetricView video http://www.win.tue.nl/empanada/metricview/

http://www.youtube.com/watch?v=G3HJ_QR9EG4

Relation between level of detail in

Sequence diagrams and defects in implementation

Strengths and Weaknesses of Metrics

StrenghtsStrenghtsStrenghtsStrenghts� Objective

� Incremental

� Fast results (if automated)

� Require little effort (if automated)Require little effort (if automated)

WeaknessesWeaknessesWeaknessesWeaknesses� Interpretation is not straigtforward

� Rather than black-white: use as indicator for weak spots

Summary

� Get stakeholders involvement in the

definition & maintenance of requirements

� Get feedback early and often

� Establish your schedule, cost, quality

prioritiespriorities

� Know & apply your design principles

� Quality Metrics can be applied early and

cost-effectively

“Not everything that is important can be measured, and not everything that can be measured is important.“

Albert Einstein

Software Architecture Design Process

FunctionalRequirementsFunctionalRequirements

Extra-FunctionalRequirementsExtra-FunctionalRequirements

DomainRequirementsDomainRequirements

UserRequirementsUserRequirements

Select Select

MRV Chaudron

Sheet 69

RequirementsRequirements RequirementsRequirements

Group Functionalityin subsystemsGroup Functionalityin subsystems

Design approach forrealizing extra-functional quality properties

Design approach forrealizing extra-functional quality properties

Select •Architectural Style•Reference Architecture•Architecture Tactics

Select •Architectural Style•Reference Architecture•Architecture Tactics

SynthesizeSynthesize

Analyze Analyze

refine

Architecture Design Principles

� Dependencies direct in the direction of stability

A

70MRV Chaudron

Sheet 70

B

B is less likely to change than A

«layer»

Business Layer

«layer»

Common Elements«layer»

Presentation and Dialogue Layer

«subsystem»P

«subsystem»D

«subsystem»M

«subsystem»F

«subsystem»C

«subsystem»M

«subsystem»Client / Browser

«subsystem»E

«subsystem»

«subsystem»S

«subsystem»Client Authentication

71

MRV Chaudron

Sheet 71

«layer»

Persistence Layer

«subsystem»P

«subsystem»M

«subsystem»F

«subsystem»D

«subsystem»C

«subsystem»M

«subsystem»P«subsystem»

M

«subsystem»F

«subsystem»D«subsystem»

C

«subsystem»M

«subsystem»Apache

«subsystem»RC

«subsystem»JR

«subsystem»PL

«subsystem»Data Security

Generic Design Principles

� Keep things that belong together at a single place

e.g. in OO: data and e.g. in OO: data and

the operations on that data

� Don’t replicate functionality

72MRV ChaudronSheet 72

Architecture Design Principles

� No Circular Dependencies

73MRV ChaudronSheet 73

Callers depend on callee, not vice versa

� Separation of Concerns ( = Decomposition)

� Zaken die niet bij elkaar horen moeten in verschillende eenheden (componenten /

procedures / .. ) worden behandeld

Generic Design Principles

74MRV ChaudronSheet 74

procedures / .. ) worden behandeld

Example Separation of Concern PrincipleTelecom Domain:

Separate the encoding/decoding of a message from the handling of a message, so

handle

encode/decode

75

MRV Chaudron

Sheet 75

message, so

� decode1 ; decode2 ; decode3 ;

action1 ; action2

And not

� decode1 ; action1 ; decode2 ;

action2 ; decode3

decode

handle &encode/decode

Aspect Orientation

Design & maintain concerns in isolation

Automatically construct implementation

by ‘weaving’ concerns

76

MRV Chaudron

Sheet 76

What is Modularity?

� We can “see it” via a � Design Structure Matrix (DSM) Map