1. 1 UML Formalization and Transformation Dissertation Defense Jeffrey E. Smith Committee: Dr. M. Kokar (Advisor), Dr. K. Baclawski, Dr. T. Cullinane, Dr. S. DeLoach (AFIT) December 2, 1999 copy of this presentation and thesis at http://www.isone.com/~jesmith/thesis

2. 2 Agenda Introduction Concise UML Syntax UML to Formal Translation Rules UML Translation UML Verification Comparison with Related Research Demonstration Publications and Presentations Summary

3. 3 Bridge Between CASE and Formal Development Paradigms 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 Computer-aided formally-developed spec/sw DisadvantagesAdvantages Inconsistent specification “Shell”SW only Uniform graphical user interface Modern SE methodologies (OO, state, etc) Reverse engineering Common large-scale development paradigm CASE-based spec/sw DisadvantagesAdvantages Motivation Verification of translation correctness left to tool developers or programmers CASE tools don’t enforce syntax/semantics CASE tools can only do partial translation to a programming language UML is semi-formal and inconsistent Objective Develop provably correct UML to formal language translator with respect to UML intended meaning Derive a process for checking translation of a UML diagram to a formal language form of UML –Formalize subset of UML & show class of translated models is within the class of models of the UML Metamodel ­ Formalize subset of CASE spec language (UML), ­ Automate transformation from UML to formal representation ­ Provide systematic method of expanding UML subset and

4. 4 UML Background De facto standard modeling language for CASE tools Incorporates OOA/OOD, OMT, OOSE and Statecharts UML 1.1 Partners – Microsoft, Hewlett-Packard, Oracle, Sterling, MCI Systemhouse, Unisys, ICON, Intellicorp, i-Logix, IBM, ObjecTime, Platinum Technology, Ptech, Taskon A/S, Reich Technologies and Softeam Version 1.3 is OMG standard UML 1.3 is OMG standard UML improvement areas of international interest – missing and/or redundant items (in UML); extensibility – formal definition of UML features – UML as the missing link from informal to formal specification – semantic enhancement; semantic verification – language mappings – preciseness of OCL constraint language...

5. 5 Related Research Background Cheng, et al. – Instance diagrams, formalized as algebras, provide a graphical definition of semantics of object models – Object models, formalized as algebraic specs, provide algebraic definition of semantics –Showed mapping of object models to instance diagrams and algebraic specs to algebras – Updated work to include functional and dynamic models and in process of updating to UML DeLoach – Formalized restricted form of OMT to algebraic/category theory specs – Models of restricted form of OMT to derived specifications – Spec morphisms map axioms in a spec to theorems in a derived spec – In process of updating to UML (ref. S. DeLoach, T. Hartrum and J. Smith: A Theory-Based Representation for Object-Oriented Domain Models, IEEE Transactions on Software Engineering, 1999)

6. 6 Prepatory Background Math foundation trade-off –Category theory, stream theory,  -calculus or process algebra, algebraic, etc. –Category theory chosen  infrastructure of modularization and structuring systems, OO application, computer- aided support, use in UML-RT Computer-aided support for above – IMPS, PVS, Z-Eves, JAPE, HOL, LARCH, OBJ3, … – Specware chosen  ability to compose new formalizations, category theory and varied theorem proving support Unique approach capturing model elements of UML diagrams in a parseable grammar, independent of any CASE tool –concise, non-redundant, unambiguous and consistent text form of UML –consolidated view of each type of UML relationship –augmented form of BNF syntax for all consolidated UML views similar to O- Slang BNF –progressed enough to build an automatic translation from UML to this modified form of O-Slang

7. 7 UML Syntax Task Rationale to build a concise, non-redundant, unambiguous and consistent text form of UML – so a definitive set of UML constructs can be used as objects of the semantics definitions – as a first step in the process of proving modeling language consistency to ensure research is compatible with, and independent of, any UML compliant CASE tool to extract and collect scattered UML syntax descriptions: – abstract syntax diagrams associated with each UML Package – descriptive text associated with each abstract syntax diagram – dynamic semantics diagrams associated with each UML Package – syntax embedded in the Object Constraint Language (OCL) – semi-formal description of UML well-formedness rules UML ASTs are used to capture the components of the UML diagrams in a parsable grammar, independent of any particular CASE tool

8. 8 UML Syntax Construction Process Collect all components and relationships from abstract syntax diagrams, descriptive text and OCL rules Collect all syntax in fragmented dynamic semantic diagrams Sort collective syntax by relationship Sort collective syntax by relationship Sort by relationship and diagram type Convert UML syntax from diagram to BNF form UML Diagram Types

9. 9 Core Metamodel Generalization Discriminator : Name GeneralizableElement isRoot: Boolean isLeaf: Boolean isAbstract: Boolean Attribute initialValue:Expr Class Classifier Association AssociationEnd isOrdered: Boolean aggregation :AggregationKind mulitplicity: Multiplicity changeable :ChangeableKind Instance Namespace type 1 * classifier 1..* * type 1 specification * associationEnd participant * * {ordered} 2 connection 1 specialization generalization * * subtype 1 supertype 1 ModelElement Name : Name ownedElement namespace * 0.1 Object

10. 10 Benefits Benefit 1. Development of a process to a) reduce errors in the transformation from a graphical to formal spec and b) check that an auto-generated formal UML application spec is consistent with the formalized form of UML semantics 2. Formalization of the UML metamodel, using a semantics guide of international consensus 3. Development of a method to support composition of software specs, logical theories and formalizations so that larger entities may be constructed from smaller components and then checked for consistency, completeness & non-redundancy 4. Development of a method to support interoperability with other CASE tool modeling languages and formal methods systems 5. Construction of a framework to permit formalizations to be extended when new features are added to the CASE tool modeling language 6. Minimization of the human effort needed to create formal methods 7. Improvement of UML understandability through unambiguous syntactic diagrams and explicit, verifiable semantics Explanation Development of a process to formally prove correct translation of CASE specified models to formal methods systems Development of a formal spec of a portion of the static class section of the UML metamodel Use of process that ensures consistency of object oriented spec composition Formalization of the translation from a UML application to an algebraic spec Incorporation of object oriented and type extensions to formalization process Automation of translation from a UML application to an algebraic spec in a language directly compatible with existing formal tools Compilation of formal UML syntax and semantic contributions to future versions of UML

11. 11 Approach UML Semantics (UML Semantics Guide contents) UML Formal Semantics (UML semantics in Slang form) 1.Spec of UML metamodel In Slang UML Graphical Domain (Application in UML form) UML Formal Domain (Application in Slang form) 2.Automatic translation of UML diagrams to Slang 5.CASE check of semantics/constraints 4.Diagram to metamodel mapping 3.Verification of translation correctness Class of models of the theory of any UML diagram is a subclass of models of the theory of the UML Metamodel

12. 12 Model Element - Spec Rule - Every Model Element in UML, specified in the UML Semantics Guide, translates to a spec containing a sort, both having the same name as the ModelElement. Specification Constraint to Op/Axiom Rule - For each specification constraint, add an associated op in the spec corresponding to the UML object that contains this specification constraint. Specify the constraint in an axiom associated with the op. UML Diagram to Colimit of Specs Rule - For each UML diagram, specify each metamodel element, as defined in the previous rules, and build the entire diagram, in a bottom-up fashion, using colimits. Constraints are specified at each level of the construction. Generalization - Generalization Instance Spec Rule - Translate each generalizable element of a generalization to a separate instance of a generalizable element spec, filling in each of the generalizable element constraints as ops, axioms and theorems of each generalizable element spec. Translate each generalization to a separate instance of a generalization spec, identifying which of the two generalizable element instances represent the subtype and supertype ``is-a" relationships. Form a colimit of the generalizable element subtype and supertype instances with an instance of the GENERALIZABLE ELEMENT- GENERALIZATION-COLIMIT spec, filling in the constraints associated with the generalizable element and generalization relations as ops and axioms. Association - Association Instance Spec Rule - Translate each association end of an association to a separate instance of an association end spec, filling in each of the association end constraints as ops, axioms and theorems of the association end spec. Translate the association to a separate instance of the association spec, identifying the classifiers associated with each association end as the source and target of the association. Form a diagram, that links the source ASSOCIATIONEND spec with its ASSOCIATION spec, into an instance of the ASSOC-SOURCE diagram, filling in the specs and sorts of the association end and association names with their instantiated values. Similarly, form a diagram, that links the target ASSOCIATIONEND spec with its ASSOCIATION spec, into an instance of the ASSOC-TARGET diagram. Next, form a diagram that combines these two diagrams with diagrams that will link the source and target CLASSIFIER specs with the source and target association ends, respectively. This is done by forming a colimit of these association ends, classifiers and association specs into an instance of the ASSOCIATION-CLASSIFIER-COLIMIT spec, filling in the constraints associated with association end, classifier and association relations, as ops and axioms. Aggregation - Aggregation Instance Rule - Treat aggregation as an association, labeling the association end corresponding to the aggregate end (the side with the hollow or filled in diamond) with the type of aggregation, according to the UML Semantics Guide. Class, Instance and Object Formalization Rules - Translate each class to an instance of a CLASS spec, implementing the specialization of the inherited name constraint from the ModelElement metamodel element and the isRoot, isLeaf and isAbstract constraints from the Classifier metamodel element. Translate each instance to an instance of an INSTANCE spec, implementing the specialization of the inherited name constraint from the ModelElement metamodel element. Translate each object to an instance of an OBJECT spec, implementing the specialization of the inherited name constraint from the Instance metamodel element (which, in turn, was inherited from the ModelElement metamodel element). Attribute Rule - Translate each attribute to an instance of a ATTRIBUTE spec, implementing its specific initialValue constraint and the inherited name constraint from the ModelElement metamodel element. Form a diagram, that links the CLASS spec with its ATTRIBUTE spec, into an instance of the ATTRIBUTE-TYPE diagram (in the UML Formal Semantics), filling in the specs and sorts of the Class and Attribute names with their instantiated values. UML to Formal Spec Translation Rules

13. 13 UML Semantics to Formal Spec Translation Rules UML Formal Domain Association Rule: Use the Association - Association Instance spec rule to capture the relationships between a meta- association and its associated classifiers and meta-association ends. Translate every association in the UML Core Metamodel to a diagram that links the source and target specs of the association. UML Formal Domain Generalization Rule : Use the Generalization - Generalization Instance spec rule to capture the relationships between a generalization and its associated generalizable element. Translate every generalization in the UML Core Metamodel to a morphism that links the source and target specs of the generalization.

14. 14 UML DiagramExport FormatParse Tree Intermediate StructureO-SlangParse Tree O-Slang StructureSlangParse Tree Slang StructureProgramming LanguageParse Tree Intermediate StructureIntermediate CodeExecutable Code parse dump translate code generate optimizegenerate symbol table Transformation Pipeline UML Diagram Intermediate Structure (REI Model) Slang StructureProgramming LanguageParse Tree Intermediate StructureIntermediate CodeExecutable Code parse code generate optimizegenerate translate symbol table Simplified Transformation Pipeline One-Step Transformation

15. 15 Translation Verification Verification of translation correctness –Proof and demonstration of theorem that asserts consistency of UML diagram translator  every sort in the UML Formal Semantics is associated with a sort in the UML Formal Domain  every op in the UML Formal Semantics is associated with an op in the UML Formal Domain  every axiom in the UML Formal Semantics is associated with either an axiom or theorem in the UML Formal Domain Shown by successive refinements of Correctness Theorem –High level informal description –More detailed level with respect to math framework –Example of mechanical steps –Summary formal refinement of Correctness Theorem –Proof of Correctness Theorem

16. 16 Formalization Process UML Graphical Domain (Application in UML form) UML Semantics (UML Semantics Guide contents) Gen 4. Interpretation of UML diagram UML Formal Domain (Application in Slang form) UML Formal Semantics (UML semantics in Slang form) 3.Findmorphisms GT 1.Formalization of UML metamodel in Slang Translation Example - UML Graphical Domain TR 2.Automatic translation to Slang student_collection 1..1 {frozen} student 1..1 level 1..1 Presentation pres_ID : String Lecture Course Student ID : Integer {ordered} * Theorem 1:  D  M : GT(Gen(D))  TR(D) Theorem 2:  D  ME in D  M: GT(Gen(ME))  TR(ME) Corollary 4:  D  M : colimit(GT(Gen(D))  colimit(TR(D)) D is Diagram; M is Morphism; GT is Ground Truth Theorem 3: Gen and GT correctly map all relationships in D to morphisms in Spec

17. 17 Correctness Theorem Q = {model elements of diagram D}, B = {attributes in D}, S = {association in D} P = {metamodel elements}, A = {meta-attributes}, R = {meta-associations}, C = {consistency constraints on P, A & R}  : Q  P  : B  A  Q  BaseElements,  : S  R  Q 2 P A R spec op diagram colimit({  (q) | q  Q} | D)  colimit({  (  (q)) | q  Q} | D)  (Q) Q B S spec op diagram       UML Graphical DomainUML Semantics UML Formal DomainUML Formal Semantics TR = GT= TR(D)  GT 

18. 18 Formalization Introduction Prove the correctness of the transformation of a UML diagram to a formal spec –Math structures used to formulate syntax of metamodel & a UML diagram must be made rigorous –Math enumeration of all UML diagrams in terms of model elements, attributes and associations that include definitions of Gen, GT and TR mappings

19. 19 Math Framework base types: Bool which denotes the set {true, false) of Boolean values String which denotes the set of strings AggrKind which denotes the set {none, composite, aggregate} of kinds of aggregation Mult = is the set of value range specs for a multiplicity ChgeKind which denotes the set of expressions and is set to {none} if empty BaseType = {BaseType, Bool, String, AggrKind, Mult, ChgeKind, Expr} BaseElement which denotes the union of all base types P denotes metamodel elements, A denotes meta-attributes and R denotes meta-associations C denote consistency constraints,  is A  P  BaseType and  is R  (P  AggrKind  Mult) 2 A metamodel (M) is a 7-tuple (P, A, R, C, , , BaseType), e.g. P is finite partially ordered set whose partial order relation is written  Q denotes model elements, B denotes attributes and S denotes associations in a UML diagram  is Q  P,  is B  A  Q  BaseElement and  is S  R  Q 2 A UML diagram D, with respect to M, is a 7-tuple (Q, B, S, , , , BaseType) satisfying, 1. For every b  B,  (  2 (  (b)))   1 (  (  1 (  (b)))) and  3 (  (b))   2 (  (  1 (  (b)))) 2. For every s  S,  (  2 (  (s)))   1 (  (  1 (  (s)))) and  (  3 (  (s))   4 (  (  1 (  (s)))) D (CM) denotes the set of all UML diagrams with respect to M

20. 20 For every b  B,  (  2 (  (b)))   1 (  (  1 (  (b)))) Q B P P A   2;2; 1;1; 1;1;  (b) = (name, Person, “Person”) Person b.scope = Class name ModelElement

21. 21 Math Framework Example Class Generalization Attribute type: BaseType AssociationEnd aggregation: AggrKind multiplicity: Mult Association 1 1 * * supertype subtype * 1 scope 1 * end 1 source 0..1 1 target P = {Class, Generalization, Attribute, AssociationEnd, Association} A = R = C = Constraints on P, A and R, e.g. multiplicity and aggregation constraints type Attribute BaseType aggregation AssociationEnd AggrKind multiplicity AssociationEnd Mult scope Attr none (0,  ) Class none (1,1) end AssocEnd none (0,  ) Class none (1,1) source AssocEnd none (1,1) Assoc composite (0,1) target AssocEnd none (1,1) Assoc composite (0,1) subtype Gen none (0,  ) Class none (1,1) supertype Gen none (0,  ) Class none (1,1)

22. 22 Correctness Formalization of a metamodel –Individual mappings of metamodel elements to specs, meta- attributes to ops and axioms and meta-associations to diagrams –Map P, A and R to corresponding construct in formal language Translation of a UML diagram to the UML Formal Domain –Individual mappings of UML diagrams model elements to specs, attributes to ops and axioms and associations to diagrams –Map Q, B and S to corresponding construct in formal language Verification from a formalization of the metamodel to a translation of a UML diagram –The construct associated with each diagram element must be compatible with construct associated with corresponding metamodel element

23. 23 Formalization of a Metamodel A formalization of a metamodel M = (P,A,R,C, , , BaseType ) is a triple GT = ( , ,  ) where: –The mapping  maps the poset (P,  ) to a commutative diagram in the category Spec. Each spec  (p) contains a distinguished sort called its primary sort. –For every a  A,  (a) is a pair consisting of an operation  1 (  (a)) and an axiom  2 (  (a)) in  (a.scope). The domain of the operation is the primary sort of  (a.scope) and the range is a.type. –For every r  R,  (r) is a pair consisting of a commutative diagram  1 (  (r)) in Spec and an axiom in the colimit of this diagram.

24. 24 Translation of a UML Diagram A translation of a UML diagram D = (Q,B,S, , , , BaseType ) is a triple TR = ( , ,  ) where: –For every q  Q,  (q) is an object in the category Spec. –For every b  B,  (b) is a pair consisting of an operation  1 (  (b)) and an axiom  2 (  (b)), in  (b.scope). The domain of the operation is the primary sort of  (b.scope) and the range is b.type.type. –For every s  S,  (s) is a pair consisting of the commutative diagram  1 (  (s)) in Spec and an axiom in the colimit of this diagram.

25. 25 Verification Morphism A verification morphism from a formalization GT, of a metamodel M, to a translation TR, of a diagram D, is a mapping  such that: –For every q  Q,  (q) is a morphism in Spec from  (q.type) to  (q). –For every b  B,  (b.scope) takes the operation  1 (  (b.type)) to the operation  1 (  (b)), and the axiom  2 (  (b.type)) maps to an axiom or theorem of the spec  (b.scope). –For every s  S, the diagram in Spec is commutative, where there is a unique morphism (s) from the colimit of  1 (  (s.type)) to the colimit of  1 (  (s)). –For every s  S, the morphism (s) takes the axiom  2 (  (s.type)) to an axiom or theorem of the colimit of  1 (  (s)).

26. 26 P, A, R and C of UML Metamodel A P BaseType name ModelElement String discriminator Generalization String isRoot GeneralizableElement Boolean isLeaf GeneralizableElement Boolean isOrdered GeneralizableElement Boolean aggregation AssociationEnd Boolean multiplicity AssociationEnd Boolean changeable AssociationEnd Boolean initialValue AssociationEnd Boolean R P 1 AggrKind 1 Mult 1 P 2 AggrKind 2 Mult 2 associationEndType AssociationEnd none (0,  ) Classifier none (1,1) specParticipant AssociationEnd none (0,  ) Classifier none (0,  ) genSubType GeneralizableElement none (1,1) Generalization none (0,  ) genSuperType GeneralizableElement none (1,1) Generalization none (0,  ) ownedElNamespace ModelElement none (0,  ) Namespace none (0,1) assocSource Association none (0,1) AssociationEnd none (1,1) assocTarget Association none (0,1) AssociationEnd none (1,1) instanceClassifier Instance none (0,  ) Classifier none (1,  ) attributeType Class none (1,1) Attribute none (0,  ) ModelElement Attribute InstanceGeneralizationNamespaceAssociationEnd ObjectGeneralizableElement ClassifierAssociation Class Partially Ordered Set P of Model Elements

27. 27 Metamodel Constraints (C) 1. The Association Ends must have a unique name within the Association  e: Association  s1, s2 : S  b1, b2 : B such that, (s1.type = assocSource  s1.source = e  s2.type = assocTarget  s2.source = e  b1.type = name  b2.type = name  b1.scope = s1.target  b2.scope = s2.target  b1.value = b2.value)  s1 = s2 2. At most one AssociationEnd may be an aggregation or composition  e: Association  s1, s2 : S  b1, b2 : B such that, (s1.type = assocSource  s1.source = e  s2.type = assocTarget  s2.source = e  b1.type = aggregation  b2.type = aggregation  b1.scope = s1.target  b2.scope = s2.target  ((b1.value = aggregate)  b1.value = composite)  b2.value = none)  ((b2.value = aggregate)  b2.value = composite)  b1.value = none)) 3. The connected Classifiers of the AssociationEnds should be included in the Namespace of the Association... 4. No opposite AssociationEnds may have the same name within a Classifier... 5. A root cannot have any Generalizations... 6. No GeneralizableElement can have a supertype Generalization to an element which is a leaf... 7. The supertype must be included in the Namespace of the GeneralizableElement...

28. 28 Q, B and S of Example UML Diagram S R Q 1 Q 2 LectureGsub genSubType Presentation-Lecture-Generalization Lecture PresentationGsuper genSuperType Presentation-Lecture-Generalization Presentation PresentationSpAs specParticipant Lecture-Course-Association Presentation LectureAsAs assocSource Lecture-Course-Association Lecture CourseAtAs assocTarget Lecture-Course-Association Course PresentationSpAg specParticipant Lecture-Student-Aggregation Presentation LectureAsAg assocSource Lecture-Student-Aggregation Lecture CourseAtAg assocTarget Lecture-Student-Aggregation Course levelAE associationEndType level Lecture student_collectionAE associationEndType student_collection Lecture studentAE associationEndType student Student courseAE associationEndType courseRole Course pres_IDAtAt attributeType pres_ID Presentation pres_IDOENAt ownerElNamespace pres_ID Presentation IDAtAt attributeType ID Student IDOENAt ownerElNamespace ID Presentation Translation Example - UML Graphical Domain student_collection 1..1 {frozen} student 1..1 level 1..1 Presentation pres_ID : String Lecture Course Student ID : Integer {ordered} * Q P Presentation Class Lecture Class Course Class Student Class Presentation-Lecture-Generalization Generalization Lecture-Course-Association Association Lecture-Student-Aggregation Aggregation level AssociationEnd student AssociationEnd student_collection AssociationEnd courseRole AssociationEnd pres_ID Attribute ID Attribute

29. 29 B of Example UML Diagram (partial) B A QBaseElement Presentation.namenamePresentation“Presentation” Presentation.isRootisRootPresentationfalse Presentation.isLeafisLeafPresentationfalse Presentation.isAbstractisAbstractPresentationtrue Lecture.namenameLecture“Lecture” Lecture.isRootisRootLecturefalse Lecture.isLeafisLeafLecturefalse Lecture.isAbstractisAbstractLecturefalse Course.namenameCourse“Course” Course.isRootisRootCoursefalse Course.isLeafisLeafCoursefalse Course.isAbstractisAbstractCoursefalse Student.namenameStudent“Student” Student.isRootisRootStudentfalse Student.isLeafisLeafStudentfalse Student.isAbstractisAbstractStudenttrue LectureisaPresentation.discriminatordiscriminatorPresentation-Lecture-Generalization“” LectureisaPresentation.namenamePresentation-Lecture-Generalization“” LectureCourseAssoc.namenameLecture-Course-Association“Lecture-Course-Association” LectureCourseAssoc.isRootisRootLecture-Course-Associationfalse LectureCourseAssoc.isLeafisLeafLecture-Course-Associationfalse LectureCourseAssoc.isAbstractisAbstractLecture-Course-Associationfalse LectureStudentAgg.namenameLecture-Student-Aggregation“Lecture-Student-Aggregation” LectureStudentAgg.isRootisRootLecture-Student-Aggregationfalse LectureStudentAgg.isLeafisLeafLecture-Student-Aggregationfalse LectureStudentAgg.isAbstractisAbstractLecture-Student-Aggregationfalse levelAE.namenamelevel“level” levelAEisOrderedisOrderedlevelfalse...

30. 30 Fundamental Rule Translation Every model element in UML, specified in the UML Semantics Guide, translates to a spec containing a sort, both having the same name as the model element. To make a lexical distinction between a spec and a sort name, the sort name will begin with a capital letter followed by lower case for the remaining characters of the name, while the spec name uses upper case letters. spec SOMEOBJECT is sort SOMEOBJECT... end-spec For each specification constraint, add an associated op in the spec corresponding to the UML object that contains this spec constraint. Specify the constraint in an axiom associated with the op. spec PAIR is sorts Pair, Left, Right op make-pair: Left, Right -> Pair op left: Pair -> Left op right: Pair -> Right axiom (equal (left (make-pair d e)) d) axiom (equal (right(make-pair d e)) e) constructors {make-pair} construct Pair theorem (equal p (make-pair (left p) (right p))) end-spec

31. 31 Model Element (ME) Translation -  ME: Each class translates to an instance of a CLASS spec, implementing the specialization of the inherited name constraint from the ModelElement metamodel element and the isRoot, isLeaf and isAbstract constraints from the Classifier metamodel element spec LECTURE is sort Lecture op name: Lecture -> String axiom fa(a: Lecture) name(a) = "Lecture" theorem Lecture-name is fa(a: Lecture, b: Lecture) (name(a) = "Lecture" & name(b) = "Lecture") op isLeaf: Lecture -> Boolean axiom fa(a: Lecture) isLeaf(a) = true theorem Lecture-isLeaf is fa(a: Lecture, b: Lecture) (isLeaf(a) = true & isLeaf(b) = true) op isRoot: Lecture -> Boolean axiom fa(a: Lecture) isRoot(a) = false theorem Lecture-isRoot is fa(a: Lecture, b: Lecture) (isRoot(a) = false & isRoot(b) = false) op isAbstract: Lecture -> Boolean axiom fa(a: Lecture) isAbstract(a) = false theorem Lecture-isAbstract is fa(a: Lecture, b: Lecture) (isAbstract(a) = false & isAbstract(b) = false) end-spec morphism CLASS-LECTURE-MORPHISM: CLASS -> LECTURE is {Class -> Lecture} spec CLASS is sort Class op name : Class -> String axiom name is (fa (a: Class b: Class) (equal (name a) (name b))) op isRoot : Class -> Boolean axiom isRoot is (fa (a: Class b: Class) (equal (isRoot a) (isRoot b))) op isLeaf : Class -> Boolean axiom isLeaf is (fa (a: Class b: Class) (equal (isLeaf a) (isLeaf b))) op isAbstract : Class -> Boolean axiom isAbstract is (fa (a: Class b: Class) (equal (isAbstract a) (isAbstract b))) end-spec

32. 32 Example of Class Translation Software For ClsID = 1 To AllClasses.Count Set theClass = AllClasses.GetAt(ClsID) Set theAssociations = theClass.GetAssociations() pr ("spec " & UCase(theClass.Name) & " is") pr (" sort " & theClass.Name & base) pr (" op name: " & theClass.Name & " -> String") pr (" axiom fa(a: " & theClass.Name & ") name(a) = " & Q & theClass.Name & Q) pr (" theorem " & theClass.Name & "-name is") pr (" fa(a: " & theClass.Name & ", b: " & theClass.Name & ")") pr (" (name(a)=" & Q & theClass.Name & Q & " & name(b)=" & Q & theClass.Name & Q & ")") pr (" op isLeaf: " & theClass.Name & " -> Boolean") If (theClass.GetSubclasses.Count = 0) Then pr (" axiom fa(a: " & theClass.Name & ") isLeaf(a) = true") pr (" theorem " & theClass.Name & "-isLeaf is") pr (" fa(a: " & theClass.Name & ", b: " & theClass.Name & ")") pr (" (isLeaf(a) = true & isLeaf(b) = true)") Else pr (" axiom fa(a: " & theClass.Name & ") isLeaf(a) = false") pr (" theorem " & theClass.Name & "-isLeaf is") pr (" fa(a: " & theClass.Name & ", b: " & theClass.Name & ")") pr (" (isLeaf(a) = false & isLeaf(b) = false)") End If pr (" op isRoot: " & theClass.Name & " -> Boolean") If (theClass.GetSuperclasses.Count = 0) Then pr (" axiom fa(a: " & theClass.Name & ") isRoot(a) = true") pr (" theorem " & theClass.Name & "-isRoot is") pr (" fa(a: " & theClass.Name & ", b: " & theClass.Name & ")") pr (" (isRoot(a) = true & isRoot(b) = true)") Else... End If pr ("end-spec") Next ClsID

33. 33 Correctness Theorem Let D be a UML diagram with respect to the Core Metamodel CM, then: –the triple GT = ( , ,  ) is a formalization of CM in Slang –  D in D(CM)  ME in D  M: GT(Gen(ME))  TR(ME) –  D in D(CM)  M: colimit(GT(Gen(D))  colimit(TR(D)) Note GT mappings ( , ,  ) are given in Appendix C and TR templates in Appendix D

34. 34 Proof of Correctness Show GT satisfies the requirements of a formalization –Show all , ,  mappings Prove correctness of TR = ( , ,  ) by showing the existence of a verification morphism between GT(Gen(D)) and TR(D) for all possible D in D(CM)

35. 35 Related Research ResearchDescriptionAdvantage Disadvantage Miriyala Interactive formal spec derivation fromUnique intelligent assistant Non-object-oriented, lack of tool & Harandiinformal NL based on schema, analogy &providing uniform & integratedsupport for formal language difference based problem solvingapproach of deriving formal specs JacksonNotation & toolset combining static classWell defined math semantics, toolAlternative to UML, semantics notation with rigor of Zsupport of graphical representationdid not address math & tool & semantic analysissupport for spec composition Kim &Specified UML structures in Z and usedDeveloped formalization rulesNo translation support,Class diagram Carringtonthem to develop translation rules from (& associated OCL) for UMLunstructured union of classes, UML to Object-Zstatic class portionsemantics for objects, aggregation & association incompatible with USG Fraser, Kumar Rule-based transforms from Structured Translation of decision tables workNon-object-oriented & Vaishnavi Analysis to VDM specificationswell Babin, Lustman Rule-based transforms from ADISSA FSM semantics well definedNon-object-oriented, only FSMs & Shoval semi-formal FSM spec to formal addressed Cheng, et alConstruct algebraic specifications fromObject model semantics and a meth.Differed from std. OMT, OMT object (& eventually functionalto insure correctness of algebrasdependency on instance diagrams, & dynamic) diagramsresulting from object model diagramLARCH not composable Paredes, et alArchitectural OO, logic-based modelAbility to capture and support incom-Non-UML compatibility, lack of for systems specification described plete info, handle rigorous arch.support for multiple views of through CV-Netsmodels, refine and reason aboutsimilar systems and dynamic com- specs, compositionponent interconnection modeling Robbins, et alIntegrated UML with semantics of otherADL interface of choice, ability toSimple, partial and inconsistent ADLs, applying OO concepts todetect deadlocksview of UML metamodel, no architectural elementsunderlying formalism DeLoachConstruct algebraic specifications fromMore automated, no reliance on OMT-based, verification/ OMT object model diagramsnew set of diagrams, supportedcompleteness of formal language composability

36. 36 Proposed research is transitional-sequential – UML Graphical Domain and UML Semantics Guide are each fully defined and transformed Computer assisted – Specware - spec construction/composition & theorem proving – Rose - UML construction and spec check – Visual Basic - translator implementation, debug & support UML Formal Domain and Semantics construction are independent Comparison with Ongoing Research Formalization Process Direct Transitional Sequential Parallel Successive Refinement Formalization Support Unassisted Computer assisted Kemmerer Wing Miriyala & Harandi Jackson Kim and Carrington Andrews & Gibbins Kung Conger et al Proposed Research Fraser, Kumar & Vaishnavi Babin, Lustman & Shoval Cheng et al Paredes et al Robbins et al Lano et al DeLoach

37. 37 Example of Browsing Rose/UML Objects

38. 38 Sample Debug Screen of Lecture UML Diagram

39. 39 Portion of Specware’s Parse and Type/Theorem Checking

40. 40 Transformation Software GUI

41. 41 Specware Graphical View of the ASSOC-SOURCE Diagram

42. 42 UML Sample Execution

43. 43 spec LECTURE is sort Lecture op name: Lecture -> String axiom fa(a: Lecture) name(a) = "Lecture" theorem Lecture-name is fa(a: Lecture, b: Lecture) (name(a) = "Lecture" & name(b) = "Lecture") op isLeaf: Lecture -> Boolean axiom fa(a: Lecture) isLeaf(a) = true theorem Lecture-isLeaf is fa(a: Lecture, b: Lecture) (isLeaf(a) = true & isLeaf(b) = true) op isRoot: Lecture -> Boolean axiom fa(a: Lecture) isRoot(a) = false theorem Lecture-isRoot is fa(a: Lecture, b: Lecture) (isRoot(a) = false & isRoot(b) = false) op isAbstract: Lecture -> Boolean axiom fa(a: Lecture) isAbstract(a) = false theorem Lecture-isAbstract is fa(a: Lecture, b: Lecture) (isAbstract(a) = false & isAbstract(b) = false) end-spec spec COURSE is sort Course op name: Course -> String axiom fa(a: Course) name(a) = "Course" theorem Course-name is fa(a: Course, b: Course) (name(a) = "Course" & name(b) = "Course") op isLeaf: Course -> Boolean axiom fa(a: Course) isLeaf(a) = true theorem Course-isLeaf is fa(a: Course, b: Course) (isLeaf(a) = true & isLeaf(b) = true) op isRoot: Course -> Boolean axiom fa(a: Course) isRoot(a) = true theorem Course-isRoot is fa(a: Course, b: Course) (isRoot(a) = true & isRoot(b) = true) op isAbstract: Course -> Boolean axiom fa(a: Course) isAbstract(a) = false theorem Course-isAbstract is fa(a: Course, b: Course) (isAbstract(a) = false & isAbstract(b) = false) end-spec spec PRESENTATION is sort Presentation op name: Presentation -> String axiom fa(a: Presentation) name(a) = "Presentation" theorem Presentation-name is fa(a: Presentation, b: Presentation) (name(a) = "Presentation" & name(b) = "Presentation") op isLeaf: Presentation -> Boolean axiom fa(a: Presentation) isLeaf(a) = false theorem Presentation-isLeaf is fa(a: Presentation, b: Presentation) (isLeaf(a) = false & isLeaf(b) = false) op isRoot: Presentation -> Boolean axiom fa(a: Presentation) isRoot(a) = true theorem Presentation-isRoot is fa(a: Presentation, b: Presentation) (isRoot(a) = true & isRoot(b) = true) op isAbstract: Presentation -> Boolean axiom fa(a: Presentation) isAbstract(a) = true theorem Presentation-isAbstract is fa(a: Presentation, b: Presentation) (isAbstract(a) = true & isAbstract(b) = true) end-spec spec PRES_ID-ATTRIBUTE is sort pres_ID-attribute op name: pres_ID-attribute -> String axiom fa(a: pres_ID-attribute) name(a) = "pres_ID" theorem pres_ID-name is fa(a: pres_ID-attribute, b: pres_ID-attribute) (name(a) = "pres_ID" & name(b) = "pres_ID") op pres_ID: pres_ID-attribute -> String axiom fa(a: pres_ID-attribute) pres_ID(a) = "" theorem pres_ID-initialValue is fa(a: pres_ID-attribute, b: pres_ID-attribute) (pres_ID(a) = "" & pres_ID(b) = "") end-spec diagram PRES_ID-ATTRIBUTE is nodes T1: TRIV, T2: TRIV, PAIR, PRESENTATION, PRES_ID-ATTRIBUTE arcs T1 -> PRESENTATION: {e -> Presentation}, T1 -> PAIR: {e -> Left}, T1 -> PAIR: {e -> Right}, T1 -> PRES_ID-ATTRIBUTE: {e -> pres_ID-attribute} end-diagram Translation Example - UML Formal Domain - 1 of 5

44. 44 Translation Example - UML Formal Domain - 2 of 5 spec LECTURE-AE-COURSE is sort Lecture-AE-Course op name: Lecture-AE-Course -> String axiom fa(a: Lecture-AE-Course) name(a) = "level" theorem Lecture-AE-Course-name is fa(a: Lecture-AE-Course, b: Lecture-AE-Course) (name(a) = "level" & name(b) = "level") op multiplicity: Lecture-AE-Course -> Nat, Nat axiom fa(a: Lecture-AE-Course) multiplicity(a) = (1,1) theorem Lecture-AE-Course-multiplicity is fa(a: Lecture-AE-Course, b: Lecture-AE-Course) (multiplicity(a) = (1,1) & multiplicity(b) = (1,1)) op isNavigable: Lecture-AE-Course -> Boolean axiom fa(a: Lecture-AE-Course) isNavigable(a) = true theorem Lecture-AE-Course-isNavigable is fa(a: Lecture-AE-Course, b: Lecture-AE-Course) (isNavigable(a) = true & isNavigable(b) = true) op aggregate: Lecture-AE-Course -> String axiom fa(a: Lecture-AE-Course) aggregate(a) = "none" theorem Lecture-AE-Course-aggregate is fa(a: Lecture-AE-Course, b: Lecture-AE-Course) (aggregate(a) = "none" & aggregate(b) = "none") op changeable: Lecture-AE-Course -> String axiom fa(a: Lecture-AE-Course) changeable(a) = "none" theorem Lecture-AE-Course-changeable is fa(a: Lecture-AE-Course, b: Lecture-AE-Course) (changeable(a) = "none" & changeable(b) = "none") op isOrdered: Lecture-AE-Course -> Boolean axiom fa(a: Lecture-AE-Course) isOrdered(a) = false theorem Lecture-AE-Course-isOrdered is fa(a: Lecture-AE-Course, b: Lecture-AE-Course) (isOrdered(a) = false & isOrdered(b) = false) end-spec spec COURSE-AE-LECTURE is sort Course-AE-Lecture op name: Course-AE-Lecture -> String axiom fa(a: Course-AE-Lecture) name(a) = "" theorem Course-AE-Lecture-name is fa(a: Course-AE-Lecture, b: Course-AE-Lecture) (name(a) = "" & name(b) = "") op multiplicity: Course-AE-Lecture -> Nat, Nat axiom fa(a: Course-AE-Lecture) multiplicity(a) = (1,1) theorem Course-AE-Lecture-multiplicity is fa(a: Course-AE-Lecture, b: Course-AE-Lecture) (multiplicity(a) = (1,1) & multiplicity(b) = (1,1)) op isNavigable: Course-AE-Lecture -> Boolean axiom fa(a: Course-AE-Lecture) isNavigable(a) = true theorem Course-AE-Lecture-isNavigable is fa(a: Course-AE-Lecture, b: Course-AE-Lecture) (isNavigable(a) = true & isNavigable(b) = true) op aggregate: Course-AE-Lecture -> String axiom fa(a: Course-AE-Lecture) aggregate(a) = "none" theorem Course-AE-Lecture-aggregate is fa(a: Course-AE-Lecture, b: Course-AE-Lecture) (aggregate(a) = "none" & aggregate(b) = "none") op changeable: Course-AE-Lecture -> String axiom fa(a: Course-AE-Lecture)changeable(a) = "frozen" theorem Course-AE-Lecture-changeable is fa(a: Course-AE-Lecture, b: Course-AE-Lecture) (changeable(a) = "frozen" & changeable(b) = "frozen") op isOrdered: Course-AE-Lecture -> Boolean axiom fa(a: Course-AE-Lecture) isOrdered(a) = false theorem Course-AE-Lecture-isOrdered is fa(a: Course-AE-Lecture, b: Course-AE-Lecture) (isOrdered(a) = false & isOrdered(b) = false) end-spec

45. 45 Translation Example - UML Formal Domain - 3 of 5 spec LECTURE-COURSE-ASSOCIATION is sort Lecture-Course-Association, Lecture, Course op name: Lecture-Course-Association -> String axiom fa(a: Lecture-Course-Association) name(a) = "Lecture-Course-Association" theorem Lecture-Course-Association-name is fa(a: Lecture-Course-Association, b: Lecture-Course-Association) (name(a) = "Lecture-Course-Association" & name(b) = "Lecture-Course-Association") op isLeaf: Lecture-Course-Association -> Boolean axiom fa(a: Lecture-Course-Association) isLeaf(a) = true theorem Lecture-Course-Association-isLeaf is fa(a: Lecture-Course-Association, b: Lecture-Course-Association) (isLeaf(a) = true & isLeaf(b) = true) op isRoot: Lecture-Course-Association -> Boolean axiom fa(a: Lecture-Course-Association) isRoot(a) = true theorem Lecture-Course-Association-isRoot is fa(a: Lecture-Course-Association, b: Lecture-Course-Association) (isRoot(a) = true & isRoot(b) = true) op isAbstract: Lecture-Course-Association -> Boolean axiom fa(a: Lecture-Course-Association) isAbstract(a) = true theorem Lecture-Course-Association-isAbstract is fa(a: Lecture-Course-Association, b: Lecture-Course-Association) (isAbstract(a) = true & isAbstract(b) = true) op make-association: Lecture, Course -> Lecture-Course-Association op first: Lecture-Course-Association -> Lecture op second: Lecture-Course-Association -> Course axiom first(make-association(d, e)) = d axiom second(make-association(d, e)) = e constructors {make-association} construct Lecture-Course-Association theorem p = make-association(first(p), second(p)) end-spec diagram LECTURE-COURSE-ASSOC-SOURCE is nodes T1: TRIV, T2: TRIV, PAIR, LECTURE-COURSE-ASSOCIATION, LECTURE-AE-COURSE arcs T1 -> LECTURE-COURSE-ASSOCIATION: {e -> Lecture-Course-Association}, T1 -> P1: {e -> Right}, T2 -> P1: {e -> Left}, T2 -> LECTURE-AE-COURSE: {e -> Lecture-AE-Course} end-diagram diagram LECTURE-COURSE-ASSOC-TARGET is nodes T1: TRIV, T2: TRIV, PAIR, LECTURE-COURSE-ASSOCIATION, COURSE-AE-LECTURE arcs T1 -> LECTURE-COURSE-ASSOCIATION: {e -> Lecture-Course-Association}, T1 -> P1: {e -> Right}, T2 -> P1: {e -> Left}, T2 -> COURSE-AE-LECTURE: {e -> Course-AE-Lecture} end-diagram spec LECTURE-COURSE-ASSOCIATION-COLIMIT is import colimit of diagram nodes T1: TRIV, T2: TRIV, T3: TRIV, T4: TRIV, T5: TRIV, T6: TRIV, T7: TRIV, T8: TRIV, P1: PAIR, P2: PAIR, P3: PAIR, P4: PAIR, LECTURE, COURSE, LECTURE-AE-COURSE, COURSE-AE-LECTURE, LECTURE-COURSE-ASSOCIATION

46. 46 Translation Example - UML Formal Domain - 4 of 5 arcs T1 -> P1: {e -> Right}, T2 -> P1: {e -> Left}, T1 -> LECTURE: {e -> Lecture}, T2 -> LECTURE-AE-COURSE: {e -> Lecture-AE-Course}, T3 -> P2: {e -> Right}, T4 -> P2: {e -> Left}, T3 -> LECTURE-AE-COURSE: {e -> Lecture-AE-Course}, T4 -> LECTURE-COURSE-ASSOCIATION: {e -> Lecture-Course-Association}, T5 -> P3: {e -> Right}, T6 -> P3: {e -> Left}, T5 -> LECTURE-COURSE-ASSOCIATION: {e -> Lecture-Course-Association}, T6 -> COURSE-AE-LECTURE: {e -> Course-AE-Lecture}, T7 -> P4: {e -> Right}, T8 -> P4: {e -> Left}, T7 -> COURSE-AE-LECTURE: {e -> Course-AE-Lecture}, T8 -> COURSE: {e -> Course} end-diagram axiom OCL1 is fa(a: Lecture-AE-Course, b:Course-AE-Lecture) name(a) = name(b) => a = b axiom OCL2 is fa(a: Lecture-AE-Course, b:Course-AE-Lecture) ((aggregate(a) = "aggregate") or (aggregate(a) = "composite") => (aggregate(b) = "none") or ((aggregate(b) = "aggregate") or (aggregate(b) = "composite") => (aggregate(a) = "none")) axiom OCL3 is fa(a: Lecture-Course-Association) Lecture = first(a) & Course = second(a) axiom OCL4 is fa(a: Lecture, b:Course) name(a) = name(b) => a = b end-spec spec PRESENTATION-LECTURE-GENERALIZATION is sorts Presentation-Lecture-Generalization, Lecture op name: Presentation-Lecture-Generalization -> String axiom fa(a: Presentation-Lecture-Generalization) name(a) = "Presentation-Lecture-Generalization" theorem Presentation-Lecture-Generalization-name is fa(a: Presentation-Lecture-Generalization, b: Presentation-Lecture-Generalization) (name(a) = "Presentation-Lecture-Generalization" & name(b) = "Presentation-Lecture-Generalization") op discriminator: Presentation-Lecture-Generalization -> String axiom fa(a: Presentation-Lecture-Generalization) discriminator(a) = "") theorem Presentation-Lecture-Generalization-discriminator is fa(a: Presentation-Lecture-Generalization, b: Presentation-Lecture-Generalization) (discriminator(a) = "" & discriminator(b) = "") op isa: Lecture -> Presentation-Lecture-Generalization axiom fa(a: Lecture) isa(a) = Presentation-Lecture-Generalization) theorem Presentation-Lecture-Generalization-isa is fa(a: Lecture, b: Lecture) (isa(a) = Presentation-Lecture-Generalization & isa(b) = Presentation-Lecture-Generalization) op no-isa: Presentation-Lecture-Generalization -> String axiom fa(a: Presentation-Lecture-Generalization) no-isa(a) = "Presentation" theorem Presentation-Lecture-Generalization-no-isa is fa(a: Presentation-Lecture-Generalization, b: Presentation-Lecture-Generalization) (no-isa(a) = "Presentation" & no-isa(b) = "Presentation") end-spec spec PRESENTATION-LECTURE-GENERALIZATION-COLIMIT is import colimit of diagram

47. 47 Translation Example - UML Formal Domain - 5 of 5 nodes T1: TRIV, T2: TRIV, T3: TRIV, T4: TRIV, P1: PAIR, P2: PAIR, PRESENTATION, LECTURE, PRESENTATION-LECTURE-GENERALIZATION arcs T1 -> P1: {e -> Left}, T1 -> LECTURE: {e -> Lecture}, T2 -> P1: {e -> Right}, T2 -> PRESENTATION-LECTURE-GENERALIZATION: {e -> Lecture}, T3 -> P2: {e -> Left}, T3 -> PRESENTATION-LECTURE-GENERALIZATION: {e -> Presentation-Lecture-Generalization}, T4 -> P2: {e -> Right}, T4 -> PRESENTATION: {e -> Presentation} end-diagram axiom OCL5 is fa(a: Presentation, b:Presentation-Lecture-Generalization) isRoot(a) = no-isa(b) => "" axiom OCL6 is fa(a: Presentation) isLeaf(a) = false axiom OCL7 is fa(a: Presentation, b:Presentation-Lecture-Generalization) name(a) = no-isa(b) end-spec

48. 48 Translation Example - UML Formal Semantics - 1 of 5 % Part 1 specs - each of the meta-classes in the Core Metamodel ---- spec PAIR is sorts Pair, Left, Right op make-pair: Left, Right -> Pair op left: Pair -> Left op right: Pair -> Right axiom (equal (left (make-pair d e)) d) axiom (equal (right(make-pair d e)) e) constructors {make-pair} construct Pair theorem (equal p (make-pair (left p) (right p))) axiom unique is (and (and (fa (a: Left) (ex (b: Right p: Pair) (and (equal (Left p) a) (equal (Right p) b)))) (implies (fa (a: Left b1: Right b2: Right p1: Pair p2: Pair) (and (and (and (equal (Left p1) a) (equal (Left p2) a)) (equal (Right p1) b1)) (equal (Right p2) b2))) (and (equal p1 p2) (equal b1 b2)))) (and (fa (a: Right) (ex (a: Left p: Pair) (and (equal (Left p) a) (equal (Right p) b)))) (implies (fa (a1: Left a2: Left p1: Pair p2: Pair b: Right) (and (and (and (equal (Left p1) a1) (equal (Left p2) a2)) (equal (Right p1) b1)) (equal (Right p2) b2))) (and (equal p1 p2) (equal a1 a2))))) end-spec spec MODELELEMENT is sort ModelElement op name : ModelElement -> String axiom name is (fa (a: ModelElement b: ModelElement) (equal (name a) (name b))) end-spec spec ATTRIBUTE is sorts Attribute, Expr op name : Attribute -> String axiom name is (fa (a: Attribute b: Attribute) (equal (name a) (name b))) op initialValue : Attribute -> Expr axiom initialValue is (fa (a: Attribute b: Attribute) (equal (initialValue a) (initialValue b))) end-spec spec INSTANCE is sort Instance op name : Instance -> String axiom name is (fa (a: Instance b: Instance) (equal (name a) (name b))) end-spec spec OBJECT is sort Object op name : Object -> String axiom name is (fa (a: Object b: Object) (equal (name a) (name b))) end-spec spec GENERALIZATION is sorts Generalization, Specialization op name : Generalization -> String axiom name is (fa (a: Generalization b: Generalization) (equal (name a) (name b))) op discriminator : Generalization -> String axiom discriminator is (fa (a: Generalization b: Generalization) (equal (discriminator a) (discriminator b))) op isa : Specialization -> Generalization

49. 49 Translation Example - UML Formal Semantics - 2 of 5 op name : Classifier -> String axiom name is (fa (a: Classifier b: Classifier) (equal (name a) (name b))) op isRoot : Classifier -> Boolean axiom isRoot is (fa (a: Classifier b: Classifier) (equal (isRoot a) (isRoot b))) op isLeaf : Classifier -> Boolean axiom isLeaf is (fa (a: Classifier b: Classifier) (equal (isLeaf a) (isLeaf b))) op isAbstract : Classifier -> Boolean axiom isAbstract is (fa (a: Classifier b: Classifier) (equal (isAbstract a) (isAbstract b))) end-spec spec CLASS is sort Class op name : Class -> String axiom name is (fa (a: Class b: Class) (equal (name a) (name b))) op isRoot : Class -> Boolean axiom isRoot is (fa (a: Class b: Class) (equal (isRoot a) (isRoot b))) op isLeaf : Class -> Boolean axiom isLeaf is (fa (a: Class b: Class) (equal (isLeaf a) (isLeaf b))) op isAbstract : Class -> Boolean axiom isAbstract is (fa (a: Class b: Class) (equal (isAbstract a) (isAbstract b))) end-spec axiom isa is (fa (a: Specialization b: Specialization) (equal (isa a) (isa b))) op no-isa : Generalization -> String axiom no-isa is (fa (a: Generalization b: Generalization) (equal (no-isa a) (no-isa b))) end-spec spec NAMESPACE is sort Namespace op name : Namespace -> String axiom name is (fa (a: Namespace b: Namespace) (equal (name a) (name b))) end-spec spec GENERALIZABLEELEMENT is sort GeneralizableElement op name : GeneralizableElement -> String axiom name is (fa (a: GeneralizableElement b: GeneralizableElement) (equal (name a) (name b))) op isRoot : GeneralizableElement -> Boolean axiom isRoot is (fa (a: GeneralizableElement b: GeneralizableElement) (equal (isRoot a) (isRoot b))) op isLeaf : GeneralizableElement -> Boolean axiom isLeaf is (fa (a: GeneralizableElement b: GeneralizableElement) (equal (isLeaf a) (isLeaf b))) op isAbstract : GeneralizableElement -> Boolean axiom isAbstract is (fa (a: GeneralizableElement b: GeneralizableElement) (equal (isAbstract a) (isAbstract b))) end-spec spec CLASSIFIER is sort Classifier op name : Classifier -> String

50. 50 Translation Example - UML Formal Semantics - 3 of 5 spec ASSOCIATION is sort Association, Source, Target op name : Association -> String axiom name is (fa (a: Association b: Association) (equal (name a) (name b))) op isRoot : Association -> Boolean axiom isRoot is (fa (a: Association b: Association) (equal (isRoot a) (isRoot b))) op isLeaf : Association -> Boolean axiom isLeaf is (fa (a: Association b: Association) (equal (isLeaf a) (isLeaf b))) op isAbstract : Association -> Boolean axiom isAbstract is (fa (a: Association b: Association) (equal (isAbstract a) (isAbstract b))) op make-association: Source, Target -> Association op first: Association -> Source op second: Association -> Target axiom (equal (first (make-association d e)) d) axiom (equal (second(make-association d e)) e) constructors {make-association} construct Association theorem (equal p (make-association (first p) (second p))) end-spec spec ASSOCIATIONEND is sorts AssociationEnd op isNavigable: AssociationEnd -> Boolean axiom isNavigable is (fa (a: AssociationEnd b: AssociationEnd) (equal (isNavigable a) (isNavigable b))) op isOrdered: AssociationEnd -> Boolean axiom isOrdered is (fa (a: AssociationEnd b: AssociationEnd) (equal (isOrdered a) (isOrdered b))) op name: AssociationEnd -> String axiom name is (fa (a: AssociationEnd b: AssociationEnd) (equal (name a) (name b))) op aggregate: AssociationEnd -> String axiom aggregate is (fa (a: AssociationEnd b: AssociationEnd) (equal (aggregate a) (aggregate b))) op multiplicity: AssociationEnd -> Nat, Nat axiom multiplicity is (fa (a: AssociationEnd b: AssociationEnd) (equal (multiplicity a) (multiplicity b))) op changeable: AssociationEnd -> String axiom changeable is (fa (a: AssociationEnd b: AssociationEnd) (equal (changeable a) (changeable b))) end-spec % Part 2 diagrams - diagrams that implement each link between pairs of meta-classes - diagram ASSOCIATION-END-TYPE is nodes T1:TRIV, T2:TRIV, PAIR, ASSOCIATIONEND, CLASSIFIER arcs T1 -> ASSOCIATIONEND: {e -> AssociationEnd}, T1 -> PAIR: {e -> Left}, T2 -> PAIR: {e -> Right}, T2 -> CLASSIFIER{e -> Classifier} end-diagram diagram SPEC-PARTICIPANT is nodes T1:TRIV, T2:TRIV, PAIR, ASSOCIATIONEND, CLASSIFIER arcs T1 -> ASSOCIATIONEND: {e -> AssociationEnd}, T1 -> PAIR: {e -> Left}, T2 -> PAIR: {e -> Right}, T2 -> CLASSIFIER: {e -> Classifier} end-diagram

51. 51 Translation Example - UML Formal Semantics - 4 of 5 diagram GEN-SUBTYPE is nodes T1:TRIV, T2:TRIV, PAIR, GENERALIZABLEELEMENT, GENERALIZATION arcs T1 -> GENERALIZABLEELEMENT: {e -> GeneralizableElement}, T1 -> PAIR: {e -> Left}, T2 -> PAIR: {e -> Right}, T2 -> GENERALIZATION: {e -> Specialization} end-diagram diagram GEN-SUPERTYPE is nodes T1:TRIV, T2:TRIV, PAIR, GENERALIZABLEELEMENT, GENERALIZATION arcs T1 -> GENERALIZABLEELEMENT: {e -> GeneralizableElement}, T1 -> PAIR: {e -> Left}, T2 -> PAIR: {e -> Right}, T2 -> GENERALIZATION: {e -> Generalization} end-diagram diagram OWNED-EL-NAMESPACE is nodes T1:TRIV, T2:TRIV, PAIR, MODELELEMENT, NAMESPACE arcs T1 -> MODELELEMENT: {e -> ModelElement}, T1 -> PAIR: {e -> Left}, T2 -> PAIR: {e -> Right}, T2 -> NAMESPACE: {e -> Namespace} end-diagram diagram ASSOC-SOURCE is nodes T1:TRIV, T2:TRIV, PAIR, ASSOCIATION, ASSOCIATIONEND arcs T1 -> ASSOCIATION: {e -> Source}, T1 -> PAIR: {e -> Left}, T2 -> PAIR: {e -> Right}, T2 -> ASSOCIATIONEND: {e -> AssociationEnd} end-diagram diagram ASSOC-TARGET is nodes T1:TRIV, T2:TRIV, PAIR, ASSOCIATION, ASSOCIATIONEND arcs T1 -> ASSOCIATION: {e -> Target}, T1 -> PAIR: {e -> Left}, T2 -> PAIR: {e -> Right}, T2 -> ASSOCIATIONEND: {e -> AssociationEnd} end-diagram diagram ATTRIBUTE-TYPE is nodes T1:TRIV, T2:TRIV, PAIR, CLASS, ATTRIBUTE arcs T1 -> CLASS: {e -> Class}, T1 -> PAIR: {e -> Left}, T2 -> PAIR: {e -> Right}, T2 -> ATTRIBUTE: {e -> Attribute} end-diagram % Part 3 constraints - colimit specs necessary to describe the OCL constraints - spec ASSOCIATION-CLASSIFIER-COLIMIT is import colimit of diagram nodes T1: TRIV, T2: TRIV, T3: TRIV, T4: TRIV, T5: TRIV, T6: TRIV, T7: TRIV, T8: TRIV, P1: PAIR, P2: PAIR, P3: PAIR, P4: PAIR, C1: CLASSIFIER, C2: CLASSIFIER, AE1: ASSOCIATIONEND, AE2: ASSOCIATIONEND, ASSOCIATION

52. 52 Translation Example - UML Formal Semantics - 5 of 5 arcs T1 -> P1: {e -> Right}, T2 -> P1: {e -> Left}, T1 -> C1: {e -> Classifier}, T2 -> AE1: {e -> AssociationEnd}, T3 -> P2: {e -> Right}, T4 -> P2: {e -> Left}, T3 -> AE1: {e -> AssociationEnd}, T4 -> ASSOCIATION: {e -> Association}, T5 -> P3: {e -> Right}, T6 -> P3: {e -> Left}, T5 -> ASSOCIATION: {e -> Association}, T6 -> AE2: {e -> AssociationEnd}, T7 -> P4: {e -> Right}, T8 -> P4: {e -> Left}, T7 -> AE2: {e -> AssociationEnd}, T8 -> C2: {e -> Classifier} end-diagram % The AssociationEnds must have a unique name within the association axiom OCL1 is (fa(a: AE1.AssociationEnd b: AE2.AssociationEnd) (implies (equal (AE1.name a) (AE2.name b)) (equal AE1.a AE2.b))) % At most one AssociationEnd may be an aggregate or a composite axiom OCL2 is (fa(a: AE1.AssociationEnd b: AE2.AssociationEnd) (or (implies (or (equal (AE1.aggregate AE1.a) "aggregate") (equal (AE1.aggregate AE1.a) "composite")) (equal (AE2.aggregate AE2.b) "none")) (implies (or (equal (AE2.aggregate AE2.b) "aggregate") (equal (AE2.aggregate AE2.b) "composite")) (equal (AE1.aggregate AE1.a) "none")))) % The connected Classifiers of the AssociationEnds should be included % in the Namespace of the association axiom OCL3 is (fa(a: Association) (and (equal C1.Classifier (first a)) (equal C2.Classifier (second a)))) % No opposite AssociationEnds may have the same name within the Classifier axiom OCL4 is (fa(a: C1.Classifier b: C2.Classifier) (implies (equal (C1.name a) (C2.name b)) (equal C1.a C2.b))) end-spec spec GENERALIZABLEELEMENT-GENERALIZATION-COLIMIT is import colimit of diagram nodes T1: TRIV, T2: TRIV, T3: TRIV, T4: TRIV, P1: PAIR, P2: PAIR, GESUB:GENERALIZABLEELEMENT, GESUPER:GENERALIZABLEELEMENT, GENERALIZATION arcs T1 -> P1: {e -> Right}, T1 -> GESUB: {e -> GeneralizableElement}, T2 -> P1: {e -> Left}, T2 -> GENERALIZATION: {e -> Specialization}, T3 -> P2: {e -> Right}, T3 -> GENERALIZATION: {e -> Generalization}, T4 -> P2: {e -> Left}, T4 -> GESUPER: {e -> GeneralizableElement} end-diagram % A root cannot have any Generalizations axiom OCL5 is (fa(a: GESUPER.GeneralizableElement b: Generalization) (implies (GESUPER.isRoot a) (equal (no-isa b.Generalization) ""))) % No GeneralizableElement can have a supertype Generalization to an % element which is a leaf axiom OCL6 is (fa(a: GeneralizableElement) (equal (GESUPER.isLeaf GESUPER.a) false)) % The supertype must be included in the Namespace of the Generalization axiom OCL7 is (fa(a: GESUPER.GeneralizableElement b: Generalization) (equal (GESUPER.name GESUPER.a) b.Generalization)) end-spec

53. 53 Future Work Expand on the set of meta-tools - future expansions include: –Metamodel analyzer that identifies metamodel elements, meta-attributes, meta-generalizations and meta- associations and helps with the identification of morphisms between these meta-elements and specific UML Formal Domain output –More of UML than existing core metamodel –Translation from a wider set of CASE tools –Extension of the UML Formal Domain to the level of Specware programming language primitives, supporting the potential of direct UML translation to any source code provided by Specware –Use of a wider set of theorem provers than currently built into Specware –Expansion of a CASE tool’s forward and reverse engineering functionality by including the UML Formal Domain as an intermediate representation to support richer and more complete code generation Include reflective OCL constraints by either basing formalization on naïve set theory or building reflectivity into Specware Contribute to future revisions of UML by streamlining redundant functionality and helping to improve the form and content of new revisions Creation of semantics for commonly used rule based systems and translation of the UML form of these rules (and associated actions) to verifiably compose large business and military AI Systems Develop the relationship between other theory- based object models, e.g. the one developed by Hartrum and DeLoach, and the UML Formal Semantics constructed in this research Parameterized specs (Schorch) permits the formal expression of higher level design information. Parameterized specs will be examined as a method to include a larger set of Core Metamodel constraints in a more comprehensive spec colimit.

54. 54 Publications and Presentations K. Baclawski, S. DeLoach, M. Kokar and J. Smith: UML Formalization: A Position Paper, Seventh OOPSLA Workshop on Behavioral Semantics of Object Oriented Business and Systems Specifications, Aug. 1998. K. Baclawski, S. DeLoach, M. Kokar and J. Smith: Object-Oriented Parsing and Transformation, OOPSLA '98, Oct. 1998. K. Baclawski, S. DeLoach, M. Kokar and J. Smith: Object-Oriented Transformation, published as a Chapter in Behavioral Specifications in Businesses and Systems Book, ISBN 0-7923-8629-9, Kluwer Publishing, 10/99. S. DeLoach, T. Hartrum and J. Smith: A Theory-Based Representation for Object- Oriented Domain Models, IEEE Transactions on Software Engineering (to appear). J. Smith, M. Kokar and K. Baclawski: Formal Verification of UML Diagrams: A First Step Towards Code Generation, OOPSLA'99, November 1999. J. Smith: UML Formalization and Transformation Dissertation Proposal Abstract, ASE '98 Doctoral Symposium, June 1998. J. Smith, M. Kokar and K. Baclawski: Formal Verification of UML Diagrams Poster, Presented at UML ‘99, October 1999.

55. 55 Summary Formal Methods SystemsCASE Tools Formalize subset of UML Systematic method of expanding subset Viable UML to Formal Methods translation Automation of human intensive processes