View
212
Download
0
Category
Preview:
Citation preview
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
Recommended