UML Formalization: A Position Paper

Kenneth Baclawski Northeastern University

Scott DeLoach AFIT

Mieczyslaw Kokar Northeastern University

Jeffrey Smith Northeastern University/Sanders

Why Formalize UML?

• inconsistent specification• shell sw only

Computer-aidedformally-developedspec/sw

CASE-basedspec/sw

• complex, diverse and unsupported tools• complex languages/math• lack of trained engineers• unproven scalability

• provably correct software• code generation• code refinement• theorem proving• spec/sw composition

• uniform graphical user interface• modern SE methodo- logies (OO, state, etc)• reverse engineering• common large-scale dev. paradigm

- Formalize common CASE spec language (UML),

- Automate transformation from UML to formal representation

disadvantages disadvantagesadvantagesadvantages

Math Foundation Alternatives

Algebraic Logic

Hidden sorted algebras Algebraic/transformational (objects are terms)

Dynamic and entity algebras Categorical/reactive (objects are theories)

Processes

Projection spaces

Competing mathematical theories ReferenceCategory theory S. DeLoach, “Formal Transformations from Graphically-Based OO

Representations to Theory Based Specifications”

Stream theory R. Breu, U. Hinkel, “Towards a Formalism of UML”-calculus or process algebra G. Overgaard,”The Semantics of UML - Tutorial”Algebraic approaches R. Bourdeau, B. Cheng,”A Formal Semantics for Object Model

Diagrams”

Category Theory chosen because:• Successful application to

– Modal/temporal logic-based specs– Formalization of OO techniques

• CASE support for software refinement, composition and code generation• Ability to compose new formalizations form existing or created set

Theory-based Object ModelComponents of UML

Domain Theory

sort

class type

class sort

abstract class

concrete class

attribute

object valued attribute

method

operation

axiom

state attribute

state sort

state invariant

event

class set

class event

Meaning

collection of values

structure of object and response to stimuli

all possible value representation of objects of the class

class with no direct instances

blueprint for instances

function that returns data values/objects - observable class characteristic

class attribute whose sort is set of objects

function that modifies attribute values

function that do not modify attribute values

class attribute value invariant and semantic of functions

function mapping from class to state sort

current state of an object

constraint on class attribute in a given state

function that invokes methods, generates events and modifies state atttributes

class whose class sort is previously defined objects (include class event)

definition of each original class event

Theory-based exampleclass PERSON isimport Sex, Naturalclass sort Personsorts Person-Stateoperations person-attr-equal: Person, Person Booleanattributes age: Person Integer gender: Person Sexstate-attributes person-state: Person Person-Statemethods create-person: Sex Person increment-age: Person Personstates old, young: Person-Stateevents new-person: Sex Person birthday: Person Personaxioms old young; person-state(a) = young age(a) < 30; person-state(a) = old age(a) 30; person-attr-equal(p, p1) gender(p) = gender(p1) age(p) = age(p1); age(create-person(s)) = 0 gender(create-person(s)) = s; age(increment-age(p)) = age(p) + 1 gender(increment-age(p)) = gender(p); person-attr-equal(birthday(p), increment-age(p)); person-attr-equal(new-person(s), create-person(s))end-class

Inheritance

Extension - add attributes/operations Restriction - constrain attributes/operations

Liskov substitution property - If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.

In theory-based object model - When specification morphism from superclass to subclass and subclassclass sort is a sub-sort of the superclass class sort.

• In O-Slang, implemented with import

• For multiple inheritance, combine superclasses (with colimit), then import

Aggregation• Part-of relationship between components and assemblies

• Modeled through object-valued attributes

• Aggregate class combines component classes via colimit, unifying component sorts and functions

Integer

Set Set Set

Acct-Class Cust-Acct Cust-Class

Bank

C C C

{E Acct, Set Acct-Class}

{E Customer, Set Cust-Class}{E Account,

Set Accounts}{E Customer, Set Customers}

{E CA-Link, Set Cust-Acct}

Association

• Models relationship between potentially aggregate components

• Link - Connection between object instances - class (with link attributes and operations) using object-valued attributes to reference other objects • Association - Set of links

• Multiplicities - number of links object can participate in - constructed by axioms defining link constraints

Object Communication

• Objects aware of own sending/receiving event set• Generated and broadcast to entire system• Event theory ~ generating class sort, parameter sorts and event signature

Receiving class or class set Event parameter sorts Receiving class event signature

• Colimit between generating and receiving classes unify events and sort so invoking generating class corresponds to invoking receiving event(s)

UML Core Package

UML to Slang Translation Rules

UML SlangAggregation diagram with colimit & ops (parts belong to whole)Association ops at next higher level (parts belong to diagram)Generalization morphismOCL axioms defining constraints at next higher levelComponent specUML Diagram spec of specsCollective of UML diagrams diagram of spec of specs

Core Translation Example

spec Namespace issort nameop unique: name, name Booleanaxiom unique is (not (equal (n1 n2)))

end-spec

spec ModelElement is; add provision, requirement and namespace op/axiomsend-spec

morphism ModelElement-to-Namespace:ModelElement Namespace is {n name}

spec Constraint issort bodyop: wellformed Boolean

end-spec

spec GeneralizableElement issort gnop isAbstract: gn Boolean

op isLeaf: gn: Booleanop isRoot: gn Boolean

end-spec

morphism GeneralizableElement-to-Namespace:GeneralizableElement Namespace is {n gn}

spec Parameter issorts defaultValue, kind, in, out, inout, returnsort-axiom kind = in | out | inout | returnop type: pn Classifier

end-spec

spec Classifier issort crn

end spec

morphism Classifier-to-GeneralizableElement:Classifier GeneralizableElement is {crn -> gn}

spec Feature issorts ownerScope, instance, classifier, fnamesort-axiom ownerScope = instance | classifiersorts visibility, public, protected, privatesort-axiom visibility = public | protected | privateop owner: fname classifier

end-spec

morphism Feature-to-ModelElement:Feature ModelElement is {fname name}

Core Translation Example (cont.)

diagram Feature-diagram isnodes Feature, Classifierarcs Feature Classifier: {fname crn}

end-diagram

spec Feature-agg iscolimit of Feature-diagram

end-spec

diagram Parameter-diagram isnodes Parameter, Classifierarcs Parameter Classifier is {fname pn}

morphism ModelElement-to-ParameterModelElement Parameter is {name pn}

spec Class isop isActive: cn Boolean

end-spec

morphism Classifier-to-Class: Classifier Class is {crn, cn}

spec Core is import {all components};; connect all associations with predicates op type: Parameter Classifier op namespace: ModelElement Namespaceend-spec

Next Steps/Issues

• Complete UML O-Slang script• Continue to “UMLize” O-Slang• Formalize UML - Slang version of abstract syntax and static/dynamic semantics at model and meta-model levels of abstraction