1 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Software Architecture Completeness Analysis Interim Presentation Christian

1

Software Architecture Completeness Analysis

Christian Lange Eindhoven, 6-6-03


Interim Presentation

Christian Lange

TU/e

2



Overview

Introduction Software Architecture Analysis Survey Completeness Rules & Metrics Outlook Questions

TU/e

3



Introduction

“Technische Informatica” TUE since 1998

Since December 2002 final year project at Océ Technologies (Venlo)

Supervisor Michel Chaudron Advisor Eric Dortmans (Océ) Lou Somers

TU/e

4



Introduction

Extension of SAAT Software Architecture Analysis Tool (Johan

Muskens)

Completeness of Architecture Introduced by Océ architecture specialists

TU/e

5



Question / Goal

What is

Software Architecture Completeness ?

Development of techniques to assess a model’s completeness to identify “incomplete spots” (tool supported)

Validation of techniques in practice

TU/e

6



SW Architecture

4+1 Views of Philippe Kruchten

TU/e

Logical view Development view

Process view Physical view

Scenarios

End- user functionality

Integrators, Performance, Scalability

Programmers software management

Topology,

Communications

7



SW Architecture Analysis

Maintainability, Extensibility, Testability,… SAAM, ATAM

Specialist work, qualitative

Metrics, SAAT, other toolsCohesion, couplingAutomated supportQuantitative

Completeness, Consistency This project

Automated supportQuantitative

TU/e

Existing

New

8



Survey

Web-based survey To get insight in the way practitioners are using the UML for

architecture To investigate practitioners

needs To get feedback on the

ideas so far

Published In newsgroups Within Océ Sent to known experts

20 questions (multiple choice, comments possible) 2 month, 80 responses (20 Océ, 30 CGEY, 30 other) Aimed audience

TU/e

9



Survey conclusions

To what degree do you follow the UML standard?

TU/e

Following UML Standard

0

5

10

15

20

25

30

35

40

not at all very loosely loosely strict very strict

10



Survey conclusions

What criteria do you use to stop modelling?

TU/e

Stop Criteria

05

1015202530354045

Effo

rt S

pent

Pas

sing

revi

ew/in

spec

tion

Sch

edul

e /

Dea

dlin

e

Com

plet

enes

s

not known

>99 man years

10-98 man years

<10 man years

Project size

11



Other survey conclusions

Logical and Scenario view mostly used

Most practitioners encountered incompleteness problems

Consistency is important

Metrics usage in early stage expected to be useful

Use of dedicated case tools (XMI export)

TU/e

12



Completeness

Intuition: Has the maturity of the architecture model

reached a level, such that we are ready to start implementing?

Definition: An architecture model is complete if and only

if it entirely describes and specifies the system that exactly fulfills all requirements and the model contains all necessary information that is needed to implement that desired model

TU/e

13



Completeness

Decomposition

TU/e

Tracing

SemanticsSyntax

Completeness

A model must be syntactically correct, i.e. it must be consistent with respect to different views and different levels of abstraction.

A model must reach a good "score" for the non-functional quality attributes

A model must necessarily reflect all functional requirements of the desired system

14



Consistency

Dimensions of consistency Differs from “completeness”

TU/e

Time

Views

Abstraction level

15



Scope of Completeness TU/eRequirements

R1 R2 R3 ...

UC1 UC2 UC3 UC4

Model

...

SC1 SC2 SC3 SC4 ...

U se C ases

S cenarios

SD1 SD2

...

S tateD iagram s

Class1

Class2

Class3

Class4

Class5

C lasses

Implementation

Class1

Class2

Class3

Class4

Class5

?

?

?

16



Meta Model

Logical View Class diagram

Class interfaces associations, dependencies, inheritance

State diagram

Scenario View Message sequence charts

Objects, messages

Use Case diagrams Use cases, Actors associations, dependencies, inheritance, instantiations

TU/e

17



Meta Model

Subset of Logical and Scenario View

TU/e

Objects

Use Cases

Classes

Scenarios

Actors

Attributes

M essages

StateM achines

M ethodsStates

1..n

1..n

1 1..n

1

1..n

1..n

11

1..n

1

1..n

0..1

1has

dascribes

1..n

1

has

belongs to

1..n

1..nbelongs to

has

1..n

1..n

has

1 1

has

has

consists of

callercalleecan change

to

0..n

0..1

calls

has

predecessor

18



Rules & Metrics

Size of Use Case

TU/e

Operation Operation

T he U se C ase has the s ize o f:2 scenarios, 5 ob jects and 6 m essages

19



Rules & Metrics

Dynamicity

TU/e

Operation

:B:A

Operation

:B:A :B

D ynam ic ity o f C lass A = 5 (2 out, 3 in)D ynam ic ity o f C lass B = 6 (3 out, 3 in)

20



Rules & Metrics

Examples (Rules, 18 so far) Objects must have a name Abstract classes should have abstract

superclasses Classes have at most one state diagram Classes with a high dynamicity have a state

diagram

Examples (Metrics, 20 so far) (shown before)

TU/e

21



The tool TU/e

Order

+get()

-val : int

item

-m e : string

client product

Queries (rules & metrics)

Database

XMI representationof model

UML representationof model

HTML output

22



Outlook

Rules and metrics set Dependencies

Rule A Rule B #Scenarios = 0 NOT objects need name/type, dynamicity,…

Classification abstraction level, phase

TU/e

Requirements Analysis Design Implementation

Rule A X X

Rule B X X X

Rule C X

Rule D X X X X

23



Outlook

Case studies for validation Tool vendor examples, literature examples

Assumed to be completeFault injectionSmall

Case studies evaluated by JohanVarious domainsCompare results

Real-world projects (Océ, …)Large projectsArchitects available for evaluation, discussionSubsequent versionsProblem tracking data availableImplemented code available (e.g. compare design with reverse-

engineered model)

TU/e

24



Ongoing case study

Context Controller, embedded system, Printer / scanner

Size: 103 Use cases 135 classes 109 scenarios

TU/e

25



Ongoing case study

Identified: oversized use case

14 scenarios vs. 1 - 5533 messages vs. 3 – 90

High level scenarios vs. low level logical viewOnly actors in MSCs, messages without method relation

(wrong) interpretation of “Actor” 1 god class vs. 97 empty classes God class is abstract but subclass of non-

abstract class

TU/e

26



Questions

?

TU/e

Documents

1 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Software Architecture Completeness Analysis Interim Presentation Christian