Skip to main contentCal State San Bernardino
>> [CNS] >> [Comp Sci Dept] >> [R J Botting] >> [papers] >> 20050502Body
[Index] [Contents] [Source] [Notation] [Copyright] [Comment] [Search ]
Fri May 12 15:30:28 PDT 2006

This part of my site contains partly baked ideas (PBI). It has drafts for publications, essays, plus illustrations and visual aids for presentations and seminars.

Disclaimer. CSUSB and the CS Dept have no responsibility for the content of this page.

Copyright. Richard J. Botting ( Fri May 12 15:30:28 PDT 2006 ). Permission is granted to quote and use this document as long as the source is acknowledged.


    A Few Changes in the Unified Modeling Language

      Object and Package Diagrams

      These are now officially part of the standard.

      Package diagrams are used to help control a complex set of UML diagrams by providing grouping and a name space mechanism. They may also indicate the organization of source code in packages (Java and Ada) or name spaces (C++?).

      Here is a classic logical architecture [Larman]

      Packages for user interface views, Application layer controllers, Domain modeling, and technical services like persistence and networking.

      Class and Object Diagrams

      Aggregation <>---. Avoid because it means very little. You might as well just write has on the association instead.

      Use a navigable association to show pointers ---->

      The data structure of LISP with two pointers car and cdr

      Default Multiplicities. Confusing.

        The UML LRM states (page 347) "In a finished model, there is no meaning to an unspecified multiplicity, Not knowing the multiplicity is no different from saying that it is many, because in the absence of knowledge, the cardinality might take any value, which is just the meaning of many".

      1. In the OMG Infrastructure model we have default multiplicities of "1" shown

        Fig 42 from the OMG Infrastructure specification

      2. In the OMG Superstructure model (drawn using the infrastructure!) we have NO defaults:

        Figure 10 from the OMG superstructure specification

      I suggest that we put in all or none.

      Object diagrams give examples of how objects are connected. Simple and obvious:

      A class diagram of an expression and some objects that are an instance of it.

      Notice that the name and type is underlined in the objects. Also note the ":" colon separating the name of the object from it's class.

      Communication Diagrams

      Objects + Messages helps design classes.

      A communication diagram traces how an evaluate message is handled by an expression and so helps refine the class diagram.


      The syntax for components has been improved with the old shape now an icon in the top-right hand corner.

      Components a encapsulate pieces of compiled code with defined interfaces. Each defines the interfaces it provides and the interfaces it requires. Plug Compatible.

      New notation: cup = required, ball = provided.

      UML1 used an arrow pointing at interface to show that a client required and interface. In UML2 we show a cup instead.

      Composite Structure Diagrams

      A detailed description of a set of components and the dependencies between them shown by ball-and-socket links.

      Component Diagrams can now express DFDs

      Many object-oriented fanatics consider Data Flow Diagrams as a cardinal sin or even heresy.

      Physical and data flows remain an important tool for everybody else.

      1. Try explaining how the CSci Dept processes student info without using data flows...
      2. Try modeling a coffee shop or diner.

      UML2.0 has features to handle this

       Figure 13 of Chapter 5 of a recent book.

      For more some of the alternate ways of expressing DFDs see [ rjb04bDFDs/ ] some early drafts for Yang05.

      Sequence Diagrams

      Vertical life lines with messages connecting them horizontally.

      A sequence diagram evaluating an expression

      New syntax: we don't underline the boxes at the top of the life lines any more because they are not objects any more!

      New idea: Interaction frames

      A sequence diagram with interaction frames
      altAlternative sets of interactions only one of which may occur
      loopA set of interactions that can be repeated
      negA negative set of interactions that must not occur
      optA set of interactions that may or may not occur (once)
      parA set of sequences that can occur in parallel
      refA reference to another diagram
      regionA set of sequences that can only be executed by one thread at a time
      sdA named sequence diagram that can be referred to elsewhere

      Activity Diagrams

      Activity diagrams can replace flow charts, pseudocode, etc.

      The Binary Search algorithm as an activity diagram.

      But activity diagrams use Petri Net style token passing semantics.

      Activities start when all incoming tokens are present.

      Activities output tokens as they terminate.

      We can even use an object to pass control tokens to an activity.

      Also allows asynchronous object streams. This means that an activity can start before an object arrives and can continue after it has output its objects:

      Part of the DFD expressed as an Activity diagram.

      Exceptions (><)

      Unexpected use: Critical path analysis, because the fork and join a synchronizing connectors: all the actions leading to them must have completed and none of the following ones can start.

      Thre ways to show a Critical Path Network

      Exercise: modeling a CSci curriculum.

      Artifacts vs Components vs Packages

      TermIdeaCan Appear
      PackageCollection of UML classifiers etcAnywhere
      ComponentAn encapsulated(plug-and-play) network of run-time objectsComponent & composite structure diagrams.
      ArtifactSomething produced during developmentDeployment diagram
      Packages seem to be more of an organizational tool than anything else.

      An artifact manifests some components and components may implement packages (roughly).


      Nodes used to be hardware, now they can be anything that can execute an artifact. They can be nested.

      No more components, only artifacts.

      A correct deployment diagram

      I added one non-standard artifact stereotype: <<applet>>. The standard artifact stereotypes are: file, document, script, executable, library, and source.

      Notation for Diagrams

      The new specification also has a formal way of giving a name to a diagram.

      UML2.0 diagram symbol

      It lists all the different official types of diagram.

      Interaction Overview Diagram

      Allows you to place sequence diagrams as boxes inside activity diagrams!

      See Fowler's 3rd Edition.

      Timing Diagrams


      See Fowler's 3rd Edition.

      Is anything missing?

      I would like to see UML contain And/Or tables for conditions or else Decision Tables for complex logic.


      Goal. To define ways for tools to share information about and in models.

      Too many acronyms.

      New version of the OCL.

    1. OCL::="Object Constraint Language", for expressing constraints, pre-conditions, post-conditions, and invariants. I have to update this [ ocl.html ] (but not too much, I hope).

      New MOF.

    2. MOF::="Meta-Object Facility", defines the data structures and programming interface for storing, communicating, and manipulating models. [ MOF in uml.glossary ]

    3. XMI::XML_DTD="XML implementation of MOF". [ XMI in uml.glossary ]


      MDA - Tomorrow the World

      Model Driven Architecture

      Arlow and Neustadt show there are common patterns that emerge when modeling most enterprises.

      OMG wants to document these and make them available (for a price?) to people.

      OMG also has a scheme to connect general Platform Independent Models to Platform Specific Models to code -- automatically.

      What Next

      I have to update all my UML documentation.

      The department needs to decide when it cuts over to the new notations.

      Back to Outline

      [ 20050502Outline.html ]

    . . . . . . . . . ( end of section A Few Changes in the Unified Modeling Language) <<Contents | End>>