UML01
Upcoming SlideShare
Loading in...5
×
 

UML01

on

  • 605 views

 

Statistics

Views

Total Views
605
Views on SlideShare
482
Embed Views
123

Actions

Likes
0
Downloads
15
Comments
0

1 Embed 123

http://www.eis.mdx.ac.uk 123

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Do demo of MMT here: just run check of MMF against itself
  • No method can really be coherent with some underlying principles that it (or its creators) hold dear. In Catalysis, these principles are: Abstraction: It is overwhelming to deal with the complexity of a software system at the level of code. Abstract models of that code let us separately describe its functional behavior, its relationship to the problem domain, its performance characteristics, the architecture it uses, etc. Any piece of source code will have been written to satisfy a combination of requirements imposed from each of these different points of view, each describing a different aspect of the problem. Examples of common abstractions are interfaces (which hide information about implementation ), and architectural patterns (which hide details of usages of those patterns in different domains). Precision: Abstract descriptions, unfortunately, have a history of being extremely fuzzy and poorly defined. As a consequence, a very elegantly laid out drawing of boxes which claims to describe the system architecture may not have sufficiently precise meaning to show that a particular implementation either does or does not conform to that architecture. Abstraction does not require loss of precision -- provided the appropriate tools and constructs are used. Abstraction with precision lets us work at different levels of detail with some confidence that the abstractions are accurate representations of the eventual implementation. Note, however, that precision must have its rightful place. There is always need for creativity, and formalism is not always appropriate. Different projects and development staff also justify different degrees of precision. Pluggable parts: All development work should be done by (a) adapting and assembling existing parts, be they implementation code, requirements specs, or design patterns, or (b) disassembling existing design to re-factor out more abstract parts from it. These three principles support each other in very powerful ways, yielding: robust, reliable abstractions; reuse at all levels from code to business models; and reliable composition and plugging together at all levels.
  • No method can really be coherent with some underlying principles that it (or its creators) hold dear. In Catalysis, these principles are: Abstraction: It is overwhelming to deal with the complexity of a software system at the level of code. Abstract models of that code let us separately describe its functional behavior, its relationship to the problem domain, its performance characteristics, the architecture it uses, etc. Any piece of source code will have been written to satisfy a combination of requirements imposed from each of these different points of view, each describing a different aspect of the problem. Examples of common abstractions are interfaces (which hide information about implementation ), and architectural patterns (which hide details of usages of those patterns in different domains). Precision: Abstract descriptions, unfortunately, have a history of being extremely fuzzy and poorly defined. As a consequence, a very elegantly laid out drawing of boxes which claims to describe the system architecture may not have sufficiently precise meaning to show that a particular implementation either does or does not conform to that architecture. Abstraction does not require loss of precision -- provided the appropriate tools and constructs are used. Abstraction with precision lets us work at different levels of detail with some confidence that the abstractions are accurate representations of the eventual implementation. Note, however, that precision must have its rightful place. There is always need for creativity, and formalism is not always appropriate. Different projects and development staff also justify different degrees of precision. Pluggable parts: All development work should be done by (a) adapting and assembling existing parts, be they implementation code, requirements specs, or design patterns, or (b) disassembling existing design to re-factor out more abstract parts from it. These three principles support each other in very powerful ways, yielding: robust, reliable abstractions; reuse at all levels from code to business models; and reliable composition and plugging together at all levels.

UML01 UML01 Presentation Transcript

  • Tony Clark Kings College London, UK – anclark@dcs.kcl.ac.uk Andy Evans University of York, UK – andye@cs.york.ac.uk Stuart Kent University of Kent at Canterbury, UK – sjhk@ukc.ac.uk September 2001 precise UML (pUML) group www. puml .org Realising MDA – a Precise Metamodeling Approach Acknowledgements Steve Cook, Desmond D’Souza, Steve Mellor
  • Outline
    • MDA
      • Modeling space
      • Metamodeling space
    • Language engineering – precise meta-modeling approach
      • Three principles and techniques
      • Excerpts from the 2U submission
    • Tools
      • Tool demonstration
      • Future developments
    • Transformations
      • Importance of transformations
      • The relation template
      • Example mappings
    • Conclusions & Discussion
  • MDA – modeling space 1
  • MDA – platform independence business model supporting systems
    • Technology independent
    • Domain expert oriented
    • Involves a range of technologies
    • Intermixed with manual processes
    • Business processes and rules scattered and implicit
    Architecture, patterns, templates current practice paperware
  • MDA – platform independence business model supporting systems
    • Technology independent
    • Domain expert oriented
    • Involves a range of technologies
    • Intermixed with manual processes
    • Business processes and rules scattered and implicit
    Architecture, patterns, templates future practice precise models, templates & patterns code/test generation traceability management tools chain
  • MDA scenario – b2c TESTS ? UML Spec Model UML Impl Model db set up .html cgi script Platform 1 .php Platform 2 UML Spec Model UML Impl Model = extension = refinement Platform 3 .jsp .java (with embedded sql) java compilation script java interface to legacy wrapper = translation
  • MDA – modeling space 2
  • MDA – Model Separation and Composition
    • Compose generated and non-generated models
    • Build consistently architected systems from components
      • Specialize and Configure
      • Generate plug-ins, bridges, adaptors
      • Connect together
    Example inspired by Kevin Tyson
    • Precise templates of domains and business processes
      • Futures Trading – orange juice, pork bellies, … electricity, drinking water?
      • Consumption – auto parts, … orange juice, pork bellies, … electricity, drinking water?
    • Generate models from templates specialized with domain specifics
      • Futures Trading [ electricity / commodity, drinking water futures / payment ]
      • Consumption [ futures electricity purchase / consumable ]
    Futures Trading (commodity, payment) Consumption (consumable, …) generate: electricity, water futures electricity, water futures compose with …
  • MDA – modeling space 3
  • MDA – Need for tools
    • Problems with modeling on an industrial scale:
      • tests/inspections/proofs of large models?
      • validation… do the models support the business well?
      • code & test generation to different platforms?
    • A lesson from eXtreme programming (XP)
      • forget paperware… focus only on stuff that executes
      • (automated) testing
      • refactoring
      • responsive to change
    • XP works on homogeneous systems
      • written in one language & environment
    • MDA abstracts from heterogeneous environment to homogeneous environment
      • abstractions are closer to business model
      • tools required to move X practices to MDA
  • MDA – meta modeling space 1
  • MDA – meta modeling space 2
  • MDA – Defining a Family of Languages
    • Precise templates for the domains of language definition
      • Concrete notation
      • Abstract syntax
      • Instances
      • Mappings between these
    compose with …
    • Generate models of languages (or fragments) from these templates
      • Classes, attributes
      • Objects, slots
    • Compose fragments
    • Build consistently architected language family
      • Even including relationships across languages
    Classes Specification Instances Namespaces Instance class attrib object slot generate: , class, attribute object, slot
  • MDA – meta modeling space 3
  • Rate of change
    • Tools that support exploration of specifications through instances
      • Permits automated testing of specs (programs or models)
    • A tool implementing a language 4 defining languages can be used to generate tools to support particular languages
    all the time hardly ever instances filmstrips traces language 4 defining languages specifications PIMs UML models PSMs programs language definitions
  • Metatools
    • Don’t live in a world of fixed languages
      • different domains use different modeling patterns (architectures)
      • some can be captured by templates, others need domain specific languages (DSLs)
    • But, if modeling is to be used in anger we need tools
      • tools need to be modeling language specific (both PS and PI)
      • main ‘brake’ is time-to-market of tools
    • Metatools generate tools from language definitions
      • through interpretation or compilation
      • still a long way to go
    • Metatools would admit opportunistic invention of DSLs
      • opportunistic identification and definition of patterns
      • more powerful than templates
  • Example metatools
    • MOF – www.omg.org
    • MetaEdit+ – www.metacase.com
    • Dome – www.htc.honeywell.com/dome/
    • XML – www.w3c.org
    • PROGRESS – graph grammars
    • MMT
  • Outline
    • MDA
      • Modeling space
      • Metamodeling space
    • Language engineering – precise meta-modeling approach
      • Three principles and techniques
      • Excerpts from the 2U submission
    • Tools
      • Tool demonstration
      • Future developments
    • Transformations
      • Importance of transformations
      • The relation template
      • Example mappings
    • Conclusions & Discussion
  • Three Principles
    • Generative Architecture
    • ensures consistency
    • avoids duplication
    • easily re-factored
    • Unambiguous Language
    • verifiable models
    • translatable models
    • richer tool support
    • Layered Definitions
    • pluggable definitions
    • extensible definitions
    • composition avoids errors
    Consistent Core
  • Three Techniques
    • Package Templates
    • ensures consistency
    • avoids duplication
    • easily re-factored
    • Instance Constraints
    • verifiable models
    • translatable models
    • richer tool support
    • Package Generalization
    • pluggable definitions
    • extensible definitions
    • composition avoids errors
    Consistent Core
  • Apply Template
  • Merge Templates
  • Package Generalization
  • Structured Language Definition: Java
    • class A extends B
    • { int I;
    • m () { …. }
    • }
      • every instance of A will …
      • when class A is loaded, a new class object …
    T x = new A(p);
      • matching constructor available, return value type T match
      • new instance of A created and variable x is bound to it
      • class needs valid identifier name, can extend 0..1 class, has instance variables …
    Specification: rules about well-formed expressions Instance/Example: rules about valid instances Language Element
  • Structured Language Definition: UML
      • every object of class Dog has slots name, breed, weight
      • every slot has a value of the type of the corresponding attribute
      • Each binary association links two classes. Each association has a multiplicity string…
      • Association is drawn as a line joining classes
      • An instance of the association (a link) links a specific instance of Dog, Sarzak, to a specific instance of owner, Sally
      • The “dog owner” John owns no dogs
      • Every valid example …
    Specification: rules about well formed models Instance/(Counter)Example Language Element Dog Name Breed Weight Owner Dog Owner Name Address {Dogs} 1 1 .. * A counter-example discovered during instance modeling
      • Class contains attributes; Attributes have distinct names
      • Attributes are in middle compartment
    Dog Name Breed Weight
  • To Define a Language …
    • Specification: abstract syntax for expressions
      • Java: class, variable, statements, constructors, …
      • UML: Class, Attribute, Association
    • Notation: concrete syntax for expressions
      • Java: strings, parentheses, …
      • UML: boxes, lines, text strings
    • Instances that are described by expressions
      • Java:objects, method invocations, threads, …
      • UML: Objects, Slots, Links
    • How abstract syntax constrains instances
      • Java: instantiation, binding, execution
      • UML: instantiation, deletion, query, computation
    • Concrete syntax to / from abstract syntax
      • Java: strings to tokens to abstract syntax trees
      • UML: boxes to classes, lines to associations, …
  • Cover All 4 Aspects Of Language Definition
    • From the RFP…
      • “ Proposals shall enforce a clear separation of concerns between the specification of the metamodel semantics and notation, including precise bi-directional mappings between them.”
      • “ Proposals should stipulate the mechanisms by which compliance to the specification will be determined…”
    • MDA requires that PSM implementations be testable against PIM specs
      • Need to know what a PIM specifies about instance behavior
      • (Plus the relation between PIM instances (data types, exceptions, slots) and PSM ones)
    • We want tools that do much more than in the recent past
      • Instance level exploration is key to understanding, debugging, testing, …
  • Federated tools: integration, interoperability
    • Architecture of language = architecture of tools
    specification concepts instance visualiser text tools instance checker instance generator diagram editor xml tools text parser text generator xml tools repository management version control concepts layout engine Body of examples & counter examples – tests specification Translator, Traceability manager
  • 2U Submission Architecture Note: Picture in initial submission document is incomplete
  • Compare with… …current architecture of UML / MOF UML 1.x (concepts) UML core UML 1.x “ physical meta-model” MOF CWM maps extends OCL instantiates uses uses XMI, IDL defines Profile adapted from a slide by Steve Cook subsets/ extend s
  • Separation of concerns
  • Package UML2.StaticCore: focus on Classes
  • Portion of UML2 Template Library
  • Generate StaticCore.Classes from Templates: 1
  • Easy step to rule on naming: <X> , <X>Instance Instances of a generalisable element can be viewed as different types Instances of any container will contain instances of the container’s contents A container whose contents are calculated from locally introduced contents and from its parents’ contents and which applies the namespace pattern
  • Generating StaticCore.Classes from Templates: 2
    • If
    • elements E1 and E2 are related by name1
    • and each element is generalizable
    • Then
    • each E1’s parents must be related (name1) to the parents of its corresponding E2s
    • E1’s instances must be related (name2) to the parents of the corresponding (name2) E2’s instances
    • E1’s instances can be viewed as of type E1 or of type any of E1’s transitive parents
    • Similarly for E2
    • See Template 4.16 for full model
  • Generated StaticCore.Classes: 1 of 3
    • Class has namespace for its attributes (alternative: parametric inheritance)
    • Classes are generalizable (have parents)
    • Attributes are generalizable (have parents)
    • All OCL constraints and query expressions generated as well
  • Generated StaticCore.Classes: 2 of 3
    • Objects have slots, whose values are objects
    • Since Classes are generalizable, objects can be viewed as being of different classes (parents link)
      • Note: In document, “Object” might be better named “ObjectView”; and ID might be better named “Object”
    • Since Attributes are generalizable, slots can be viewed as being of different attributes
  • Generated StaticCore.Classes: 3 of 3
    • Instance constraints between objects/slots and classes/attributes
      • Associations generated
      • OCL constraints generated
  • Result of Our Approach
    • Consistent structure, constraints, names introduced at will
    • Architectural integrity maintained through all lower templates
    • Consistency assured in every end-model template application
    • Consistency assured across languages and profiles, across concrete syntax, abstract syntax, and instance domains
    • Changes made in just on place
    • Final submission will develop ContainerMap branch: basis for 1 st class MDA support
    • More on templates from submission
  • Outline
    • MDA
      • Modeling space
      • Metamodeling space
    • Language engineering – precise meta-modeling approach
      • Three principles and techniques
      • Excerpts from the 2U submission
    • Tools
      • Tool demonstration
      • Future developments
    • Transformations
      • Importance of transformations
      • The relation template
      • Example mappings
    • Conclusions & Discussion
    • Slides for tool demo
  • Outline
    • MDA
      • Modeling space
      • Metamodeling space
    • Language engineering – precise meta-modeling approach
      • Three principles and techniques
      • Excerpts from the 2U submission
    • Tools
      • Tool demonstration
      • Future developments
    • Transformations
      • Importance of transformations
      • The relation template
      • Example mappings
    • Conclusions & Discussion
  • Transformations Everywhere!
    • Language definition
    • Between languages
      • Business models to PIMs
      • PIMs to PSMs
    • Between models in the same language
      • Refinement
  • Relation template context <X>Rel<Y> inv : image()=pairs.<y>_r->asSet inverseImage()=pairs.<x>_d->asSet isFunctional()=pairs->forAll(p,q| p.<x>_d=q.<x>_d implies p=q) isInverseFunctional()= pairs ->forAll(p,q | p.<y>_r =q.<y>_r implies p=q) isInjection()=isFunctional and isInverseFunctional isOnto()=(image=ran) isTotal()=(inverseImage=dom) isBijection()=isInjection() and isOnto() and isTotal() lookup(x)=pairs->select(p|p.<x>_d=x) lookup(y)=pairs->select(p|p.<y>_r=y)
  • Semantics
  • Example PIM to PSM
  • Refinement
    • Car hire example (rental action)
    • Consider mapping of dynamic behaviour
  • Outline
    • MDA
      • Modeling space
      • Metamodeling space
    • Language engineering – precise meta-modeling approach
      • Three principles and techniques
      • Excerpts from the 2U submission
    • Tools
      • Tool demonstration
      • Future developments
    • Transformations
      • Importance of transformations
      • The relation template
      • Example mappings
    • Conclusions & Discussion
  • Conclusions
    • MDA needs languages
      • in families
        • education and training
        • tooling
    • MDA needs advanced tools
      • to explore models by example
      • to check well-formedness
      • to automate and track model transformations
    • MDA applied at the metamodeling level could deliver technology to generate tools from definitions
    • MDA needs an approach to metamodeling which delivers
      • complete
      • consistently architected
      • unambiguous and machine processable
      • definitions of language families
    • Transformations are critical
      • candidate for first class language support
  • Discussion
    • If MDA is realised, what impact will it have?
      • On people
        • analysts, designers, engineers, programmers, …
      • On solutions for customers
        • quality, costs, time-to-deployment, ongoing evolution, …
      • On margins for solution providers
        • productivity, tools, …
    • Are there other (non-technical?) things we should be doing that would have greater impact?