1

Formal Specification of O-O Software Architecture

Amnon H. EdenTel Aviv University and Ericsson Research

Yoram HirshfeldTel Aviv University

The 2nd Nordic Workshop on Software Architecture -- NOSA’99

2

Contents

Problem: Informal Specifications– Existing Solutions and their flaws

Two Separate contributions– Observations

– Specification language

Applications– Proofs on relations between patterns

– Tool support

3

Elements of O-O Architecture

Different abstraction levels– Architecture

• Models: Layered Architecture, Client-Server, ...

– Design• Design Patterns (or rather, the abstraction of their solutions)

– Programming• Classes, objects, methods• Interactions

4

Reminder: Design Pattern

abstract-factory

factory-1

factory-2

factory-n. . .

5

Specification of Architecture

Existing means are:– Informal specifications (natural language)

• Ambiguous• Lead to confusions, debates• Prevent tool support, e.g., automated validation

– Specific examples• Not general• Programming language idiosyncrasy

Problem!

6

Wanted: A Formal Specification Language

Desired properties:– Formal, precise

• Delivering accurate and unambiguous specifications

– Expressive• Can account for models in existence

– Concise• Easy to use and read

– Promote tool support• Formulae implemented easily

7

Existing Solutions I

Allan & Garlan [94, 97]; Garlan & Shaw– Specification of dynamic invariants

– Extending process calculi (CSP)

– Flaws:• Focus on behavior, not on the static structure• Little relevance to OOP, no mapping to OOP constructs• Implementation is not trivial• Complete verification is often impossible• Validation requires separate run-time agents

8

Existing Solutions II

Extensions of -Calculus – Specification of the semantics of OOP programs

• E.g.: System-F with subtyping (also F<:), Cardeli, Mitchell

– Flaws:• Wrong abstraction level: Elements of programs• Inexpressive

– Operational semantics

• Hard to prove properties, reason, implement

9

Existing Solutions III

Pattern specification languages– E.g.: Mikkonen [98], Bosch [96], Lauder & Kent

[98]

– Focus on the Gang of Four catalog

– Flaws: • Not concise• Require language extension• Do not account for the observations made• Inexpressive

10

Two Separate Contributions

Observations: Recurring motifs in O-O architecture– Building blocks for design patterns– Sets, correlations, isomorphisms

LePUS: A specification language– Express the building blocks– Calculus for combining them– Calculus for relations between patterns– Formal, expressive, concise, promote tool support– With a graphic equivalent

11

Observations

Recurring motifs in O-O Architecture

Building blocks & correlations

12

Sets

Uniform collections

Motif-window

Windows 95-window

PM -window

window

PM -creator

Windows 95 -creator

Motif-creator

Creator

13

Sets of Sets: Classes

Windows95-Window-factory-

method(pos)

Motif-Window-factory-

method(pos)

PM -Window-factory-

method(pos)

Motif-window

Windows 95 -window

PM -window

PM -creator

Windows 95 -creator

Motif-creator

defined-in

defined-in

defined-in

Windows95-button-

factory-method

Motif-button-factory-method

PM -button-factory-method

Motif-button

Windows 95 -button

PM -button

defined-in

14

Sets of Sets: Methods

Windows95-Window-factory-

method(pos)

Motif-Window-factory-

method(pos)

PM -Window-factory-

method(pos)

Motif-window

Windows 95 -window

PM -window

PM -creator

Windows 95 -creator

Motif-creator

defined-in

defined-in

defined-in

Windows95-button-

factory-method

Motif-button-factory-method

PM -button-factory-method

Motif-button

Windows 95 -button

PM -button

defined-in

15

defined-in

)PM -

window-creator

Windows95-Window-creator

Motif-window-creator

defined-in

defined-in

Isomorphisms I

Windows95-Window-factory-method

Motif-Window-factory-method (pos)

PM2-Window-factory-method (pos)

Motif-window

Windows95-window

PM -

window

16

Isomorphisms II

Windows95-Window-factory-

method(pos)

Motif-Window-factory-

method(pos)

PM -Window-factory-

method(pos)

Motif-window

Windows 95 -window

PM -window

PM -creator

Windows 95 -creator

Motif-creator

defined-in

defined-in

defined-in

Windows95-button-

factory-method

Motif-button-factory-method

PM -button-factory-method

Motif-button

Windows 95 -button

PM -button

defined-in

17

Class Hierarchies

18

LePUS

Ground Variables Ground Relations

Set VariablesSet Relations

19

Computation Model

Program: Model (“structure”) describing a collection of entities and relations

Pattern: A set of constraints – Distinguishes which programs conform

Specification Language: A compact subset of higher order monadic logic

20

Variables

Ground Variables:

Set Variables:

Hierarchies:

cls-varfnc-varfnc-var F, cls-var C

fuc-setF, cls-setCcls-setfnc-set

Creators ProductsCreators ä, Products 2ä

21

Relations I

Ground Relations

factory-method

product

creator

Defined-In(factory-method, creator)

Return-Type(factory-method, product)

Creates(factory-method, product)

22

Relations II

Isomorphisms

factory-method

product

creator

Defined-In(factory-method, creator)

Return-Type(factory-method, product)

Creates(factory-method, product)

23

Abstract Factory

Creators

Factory-Methods

ProductsProducts

Graphic version

Textual version

Variables declaration

Isomorphisms

Commutativity

24

Applications

Reasoning With Patterns

Tool Support

25

Reasoning: Refinement

When is pattern p1 a “special-case-of” p2? The Multicast vs. Observer Debate

– Authors cannot agree if Multicast is a special case of Observer.

• Reported in: “Multicast”, John Vlissides. C++ Report, Sep. 97. SIGS Publications.

Solution: Define Refinement– Given the formulae , , we say that refines iff

.

26

Refinement (continue)

subject

Observers

Update(subject )

attach(observers )

detach(observers )

notify

concrete-subject

get-state

Set-State

Observer (existing)

Messages

Receivers

receive(Messages)

Senders

multicast

Registry

register(Receivers)

Multicast (proposal)

Messages

Receivers

receive(Messages )

Senders

multicast

Typed Message (final)

Multicast (Refinement) Typed Message

27

Reasoning: Projection

Hitherto unobserved relation Intuitively:

– Pattern occurs as an unbounded set in

Example:

Creators

Factory-Methods

ProductsProducts

Abstract Factory

Products

Creators

factory-methods

Products

Factory Method

28

Tool Support

Automating:– Validation

– Application

– Recognition

– (?) Discovery

Implementation in PROLOG

FactoryMethod(hierarchy_structure (Creators_root, Creators_Leaves), hierarchy_structure (Products_root, Products_Leaves), FactoryMethods) :- clan(FactoryMethods,[Creators_root|Creators_Leaves]), isomorphic(production, FactoryMethods, [Products_root|Products_Leaves]).

FactoryMethod(hierarchy_structure (Creators_root, Creators_Leaves), hierarchy_structure (Products_root, Products_Leaves), FactoryMethods) :- clan(FactoryMethods,[Creators_root|Creators_Leaves]), isomorphic(production, FactoryMethods, [Products_root|Products_Leaves]).