1. UML Formalization: A Position Paper Kenneth BaclawskiNortheastern University Scott DeLoachAFIT Mieczyslaw KokarNortheastern University Jeffrey SmithNortheastern University/Sanders

2. Why Formalize UML? inconsistent specification shell sw only Computer-aided formally-developed spec/sw CASE- based spec/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 advantages

3. Math Foundation Alternatives AlgebraicLogic Hidden sorted algebrasAlgebraic/transformational (objects are terms) Dynamic and entity algebrasCategorical/reactive (objects are theories) Processes Projection spaces Competing mathematical theoriesReference Category theoryS. DeLoach, “Formal Transformations from Graphically-Based OO Representations to Theory Based Specifications” Stream theoryR. Breu, U. Hinkel, “Towards a Formalism of UML”  -calculus or process algebraG. Overgaard,”The Semantics of UML - Tutorial” Algebraic approachesR. 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

4. Theory-based Object Model Components 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

5. Theory-based example class PERSON is import Sex, Natural class sort Person sorts Person-State operations person-attr-equal: Person, Person  Boolean attributes age: Person  Integer gender: Person  Sex state-attributes person-state: Person  Person-State methods create-person: Sex  Person increment-age: Person  Person states old, young:  Person-State events new-person: Sex  Person birthday: Person  Person axioms 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

6. Inheritance  Extension - add attributes/operations Restriction - constrain attributes/operations Liskov substitution property - If for each object o 1 of type S there is an object o 2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o 1 is substituted for o 2, then S is a subtype of T. In theory-based object model - When specification morphism from superclass to subclass and subclass class 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

7. 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 Acct-ClassCust-AcctCust-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}

8. 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

9. 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 sortsReceiving class event signature Colimit between generating and receiving classes unify events and sort so invoking generating class corresponds to invoking receiving event(s)

10. UML Core Package

11. UML to Slang Translation Rules UMLSlang Aggregationdiagram with colimit & ops (parts belong to whole) Associationops at next higher level (parts belong to diagram) Generalizationmorphism OCLaxioms defining constraints at next higher level Componentspec UML Diagram spec of specs Collective of UML diagramsdiagram of spec of specs

12. Core Translation Example spec Namespace is sort name op unique: name, name  Boolean axiom unique is (not (equal (n1 n2))) end-spec spec ModelElement is ; add provision, requirement and namespace op/axioms end-spec morphism ModelElement-to-Namespace: ModelElement  Namespace is {n  name} spec Constraint is sort body op: wellformed  Boolean end-spec spec GeneralizableElement is sort gn op isAbstract: gn  Boolean op isLeaf: gn: Boolean op isRoot: gn  Boolean end-spec morphism GeneralizableElement-to-Namespace: GeneralizableElement  Namespace is {n  gn} spec Parameter is sorts defaultValue, kind, in, out, inout, return sort-axiom kind = in | out | inout | return op type: pn  Classifier end-spec spec Classifier is sort crn end spec morphism Classifier-to-GeneralizableElement: Classifier  GeneralizableElement is {crn -> gn} spec Feature is sorts ownerScope, instance, classifier, fname sort-axiom ownerScope = instance | classifier sorts visibility, public, protected, private sort-axiom visibility = public | protected | private op owner: fname  classifier end-spec morphism Feature-to-ModelElement: Feature  ModelElement is {fname  name}

13. Core Translation Example (cont.) diagram Feature-diagram is nodes Feature, Classifier arcs Feature  Classifier: {fname  crn} end-diagram spec Feature-agg is colimit of Feature-diagram end-spec diagram Parameter-diagram is nodes Parameter, Classifier arcs Parameter  Classifier is {fname  pn} morphism ModelElement-to-Parameter ModelElement  Parameter is {name  pn} spec Class is op 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  Namespace end-spec

14. 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