Skip to main contentCal State San Bernardino / [CNS] / [Comp Sci Dept] / [R J Botting] >> [CSci202] >> uml
[Index] [Schedule] [Syllabi] [Text] [Labs] [Projects] [Resources] [Search] [Contact] [Grading]
Notes: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
Mon Jun 4 07:51:26 PDT 2007

Contents

    UML -- The Unified Modelling Language

      Definition

       UML is the Unified Modelling Language [ http://www.rational.com/uml/ ] created by the Three_Amigos. Many companies support UML and several CASE tools use it. Rational has a particular CASE tool called Rational Rose that we have installed here at CSUSB as part of the ROOT project to incorporate state-of-the-art object-oriented Technology and mathods into our CS degree.

      Beginners Start Here

        Why Use UML

         If you become familiar with a way to draw pictures of your ideas you will find that you will be able to think of more ideas and also to work out the consequences of your decisions. UML is such a graphic language. It will probably become a popular and standardized way of analysing problems and designing solutions using objects. As a widely used standard UML will become valuable in the job market. It will also be used in the CS degree here.

        How to Draw Pictures of a Static Structure

        The heart of an object oriented program are the classes and the links between them. Here are some notes [ uml1.html ] on how to draw diagrams of simple C++ structures and classes. For the more advanced C++ ideas (pointers, friends, inheritance for example) see [ uml1b.html ]

        Using Ratonal Rose 4.0

         It helps if you have a tool to draw the diagrams and maintain the documentation that describes the problem and its solution: [ uml3.html ]

        How to Draw Pictures of Dynamics

        The development of object-oriented software starts and ends with the study of how the system and its parts work together to help the user: [ uml2.html ]

        Disclaimer

        These notes are a very short and incomplete summary of UML. The Rational UML Resource Pages should be consulted for definitive examples and definitions. There is a list of WWW resources below [ See Also ]

        This set of notes leaves several parts of UML out. They do not cover notations needed for industrial size problems:

        • How the parts of a piece of software are grouped into logical packages and connected together by dependencies. But see [ uml.gen.gif ]
        • How the software is distributed over the available hardware(Deployment Diagrams).
        • How a complex business procedure is represented (Activity Diagram)

      . . . . . . . . . ( end of section Beginners Start Here) <<Contents | End>>

      Quick Reference

      Here is a quick list of UML diagram types with links to graphic images that are examples of that diagram.
      1. General Purpose Concepts
      2. Use-Case Diagram
      3. Class Diagram [ uml.coll0.gif ] [ uml.coll1.jpg ] [ uml4.jpg ]
      4. State-Transition Diagram
      5. Interaction Diagrams
        Net
        1. Sequence Diagram [ uml.seq.gif ]
        2. Collaboration Diagram [ uml.collab.gif ]

        (End of Net)

      6. Component Diagram
        • Dependencies between pieces of software
      7. Deployment Diagram
        • configuration of runtime elements

      See Also

      Complete and up to date information can be found on the Internet by following the World Wide Web links below. UML is defined and maintained by the Three_Amigos at Rational Corporation's Web site.
    1. Rational::= See http://www.rational.com/

      Online Tutorials: [ http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/rose/ ] (Actually uses Booch not UML) Books:

      • UML Distilled: Applying the Standard Object Modeling Language by: Martin Fowler, Kendall Scott part of the Object Technology Series ISBN: 0-201-32563-2 (Search under [ catalogtitle.qry ] )

      UML Glossary

        There is a more complete glossary in [ uml.glossary.html ] my samples of mathematical techniques.

        Note. In this glossary a definition is written like this 

         		defined_term::=what_the_term_means.
        or 
         		defined_term::context=what_the_term_means.
        When there are several alternative meanings they are separated by a vertical bar symbol: "|". This is an informal extension of the notation Jim Backus and Pete Naur developed in 1960. [ BNF in glossary ] [ BNF in comp.text.Meta ] [ algol60.syntax.html ]

        A B C
      1. abstract::stereotype=indicates that a class defines an abstraction so that no objects of this type exist except as objects of the specific subtypes of this type.

      2. actor::=an entity that starts scenarios and gets results from them. An actor has an iconic stick-figure form but is actually a class or type with the <<actor>> sterotype.
      3. actors::=plural of actor.

      4. aggregation::=a way that one class can refer to another class without having possession of it + a weak form of 'has-a' link. This relationship is shown by an open diamon at one end of a link. The other end may have an arrow head indicating the the link can be navigated in one direction only. This allows a simple iterator or pointer to implement the association.

      5. application_domain::=a collection of more or less similar solutions.

      6. association::=A kind of relationship or link between classes. Associations are further documented by stereotypes + roles + multiplicities + constraints + descriptive names + aggregation indicators.

      7. attributes::=plural of attribute.
      8. attribute::=a named value that an object or class is responsible for maintaining.

      9. class::=a part of a UML class_diagram indicating a collection of objects with similar responsibillities and/or behaviors. It can be shown as a box with a name in it or as a box with a name, attributes and operations.
      10. classes::=plural of class.

      11. class_diagram::=a diagram showing classes and relationships between them. Very close to the early Object Model of Rumbaugh.

      12. communicating::=the process of sending and receiving data through a communication_association between an actor and a usecase.
      13. communication_association::association=a link in a usecase_diagram connecting an actor to a usecase.

      14. composition::= a strong for of 'has_a' where objects of one class possess and are made up of parts that belong in other classes. These are implemented using fields in structures.

      15. constraint::=A logical formula or informal text stating something that must be true and written inside curly braces | one of a small number of words indicating a logical constraint - for example "complete".
      16. constraints::=plural of constraint.

      17. constructor::stereotype=indicates that an operation creates a new object of its class.

        D E F G

      18. destructor::stereotype=indicates that an operator deletes an object of its class.

      19. dependencies::=plural of dependency.
      20. dependency::=a relationship between parts of an UML model drawn as a dotted line with an arrow head that indicates that if one thing chages then the change may effect the other thing. Often one things uses the other thing(usage).

      21. domain::= problem_domain | application_domain.

      22. dynamic::stereotype=a generalization can be described as dynamic if it possible for an object to change its classification during its life. This is the opposite of the normal static form of generalization.

      23. frozen::=a property of a link that no links are added|deleted|moved from an object at the frozen end.

      24. generalization::=relationship between two classes where objects of the specific class(subtype)automagically also belong to the more general type. A static or dynamic is_a relationship. It is typically easier to implement static generalisations in C++ by using inheritnace than to implement dynamic forms. Dynamic generalisations need patterns developed by the GoF

        H I J K
      25. interface::stereotype=indicates that a type is an abstract data type that is implemented by one or more other types and can be used by one or more types.
      26. interfaces::=plural of interface.

        L M N O

      27. multiplicities::=plural of multiplicity.
      28. multiplicity::=numbers or sets of numbers written at one end of an association indicating how many objct of the closest type correspond thru the link to a single item at the other end.

      29. note::=an informal remark linked to a part of a UML diagram. The link is a dotted line and the remark is in a rectangular box with the corner folded over. Looks a little like a stereotype and a constraint.

      30. objects::=plural of object.
      31. object::analysis=an instance of a class.
      32. object::design=something with an unique identity that encapsulates some know-how (operations) and some values(attibutes).
      33. object::code=a piece of storage plus some subprograms that have privileged access to that storage. [ object in glossary ]

      34. operations::=things that an object in a class knows how to do.

        P Q R S
      35. package::=an icon in UML that looks like a folder and refers in a single symbol to a whole UML diagram that either exists or may be in the process of creation.
      36. packages::=plural of package.

      37. patterns::= See http://www.csci.csusb.edu/dick/se.html#Patterns.
      38. pattern::patterns=a recurring problem which involves compromising between several forces and which has a preffered and documented solution. See GoF.

      39. problem_domain::=a collection of more or less similar problems selected for practical or theoretical reasons.

      40. result::=the end point of a scenario.
      41. results::=the end points of a set of scenarios.

      42. roles::=plural of role.
      43. role::=a word or phrase written where a link meets an box indicating the part played by the class in the relationship indicated by the link. See rolename.
      44. rolename::=A name string near the end of the link indicating the role played by the class in the association attached to end of the path near the rolename.

      45. scenario::=A description of how a particular actor achieves a tangible result.
      46. scenarios::=plural of scenario.

      47. static::=something that is permanent and can't change. In UML generalizations are normally static but there is a stereotype that allows a classification to change.

      48. stereotype::UML=a special note looking like this: <<example>> that adds to the meaning of a UML diagram.
      49. stereotype::UML=a special note looking like this: <<example>> that adds to the meaning of a UML diagram.

      50. subtype::=One class is a subtype of another class if all the operations of the second class of object also apply to objects of the first type - perhaps in a different way. Subtypes shown by the generalisation arrow that has an open arrow head.

        T U V
      51. usage::=a special kind of dependency where one piece of a program makes use of another part of the program.
      52. usecase::=a set of scenarios sharing a a class of similar actors achieving similar tangible results documented by a natural language text and pictured as an oval.
      53. usecase_diagram::=a UML diagram that shows one or actors communicating with one or more usecases.
      54. usecases::=plural of usecase. [ uml.usecases.gif ]

      55. visibility::=an indicator(+#-...) indicating whether a rolename | attribute | operation can be accessed from outside a class.

        W X Y Z

        Abbreviations

      56. Three_amigos::abbreviation={ Grady Booch, Ivar Jacobsen, James Rumbaugh }. (See [ JokeUML in methods ] and [ Unified in methods ] )

      57. GoF::abbreviation=The_Gang_of_Four.
      58. The_Gang_of_Four::abbreviation={Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides}, Four OO thinkers who wrote an influential book of design patterns.

      59. OO::abbreviation=Object-Oriented.
      60. OMT::method=The Object Modelling Method developed by Rumbaugh et al that forms one of UML's parents.

      . . . . . . . . . ( end of section UML Glossary) <<Contents | End>>

    . . . . . . . . . ( end of section UML) <<Contents | End>>

    Abbreviations

  1. TBA::="To Be Announced", something I have to do.
  2. TBD::="To Be Done", something you have to do.
  3. Dia::="A free Open Source Diagramming tool for Linux, Windoze, etc. ".
  4. YAGNI::="You Ain't Gonna Need It".
  5. DRY::="Don't Repeat Yourself".

End