[Skip Navigation] [Remove Frame] [CS320] [Text Version] uml.glossary.html Sat Dec 23 08:01:04 PST 2006
Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).


    UML Glossary



        stands for the Unified Modelling Language created by the Three_Amigos [ http://www.rational.com/uml/ ] of Rational. It is a graphic language developed to help in the development of software. 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 methods into our CS degree.

        This page defines and illustrates some of the key concepts of UML using the MATHS notations. To learn how to use UML please see

          [ uml1.html ] How to draw simple diagrams of classes

          [ uml1b.html ] How to draw complex diagrams of classes

          [ uml13.html ] How to draw use cases, scenarios and collaboration diagrams

          [ cs320wuml.html ] How to use UML to describe programming languages

          [ uml2.html ] How to use Rational Rose on our UNIX Workstations.

          TBA How the software is distributed over the available hardware(Deployment Diagrams).

          TBA How a complex business procedure is represented (Activity Diagram)

          [ See Also ] below.

        Note. In this glossary a definition is written like this

        When there are several alternative meanings they are separated by a vertical bar symbol: "|" read as "or". This is an informal extension of the notation John Backus and Pete Naur developed in 1960. [ BNF in glossary ] [ BNF in comp.text.Meta ] and
      1. Algol60::= See http://csci.csusb.edu/dick/samples/algol60.syntax.html

        A B

      2. AKO::="A Kind Of" -- object-oriented jargon for relation between general and particular.
      3. APO::="A Part Of" -- object-oriented jargon for relations between pats and wholes, compare with AKO.

      4. abstract::stereotype=indicates that a class defines an abstraction so that no objects of this type exist except as objects of the specialized subtypes of this type. You can have pointers or references to abstract classes but you can not have any objects or variables of an abstract type. The pointers always refer to objects in a more specific concrete classes. [ uml.shape.gif ] [ uml.find.gif ]
      5. abstract_data_type::=a collection of data with invisible attributes (the data) that is manipulated only by operations and so hides its attributes behind an interface.
      6. abstraction::=indicates that something is left out of a description or definition.

      7. 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. [ uml.usecases.gif ]
      8. actors::=plural of actor.

      9. actual_parameter::=a value supplied when generating a particular version of a parameterized class or package. Actual parameters are listed inside diamond brackets like this <for,example>.

      10. aggregation::=a way that one class can refer to another class without having possession of it + a weak form of 'has-a' / APO link + if the whole object is an aggregation then deleting it does not effect the existence of the aggregated part. This relationship is shown by an open diamond at one end of a link. The other end may have an arrow head indicating the link can be navigated in one direction only.

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

      12. association::=A kind of relationship or link between classes. Associations are further documented by stereotypes + roles + multiplicities + constraints + descriptive names + aggregation indicators + navigability indicators. [ uml.coll0.gif ] [ uml.coll1.jpg ] [ uml.game.gif ] [ uml.association.gif ] [ uml.link.gif ]

      13. attributes::=plural of attribute.
      14. attribute::=a named value that an object or class is responsible for maintaining. [ uml1.gif ]


      15. class::=a part of a UML class_diagram indicating a collection of objects with similar responsibilities 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. [ uml1.gif ] [ uml3.gif ] [ uml.game.gif ] [ clock1.gif ] [ clock2.gif ]

      16. classes::=plural of class.

      17. class_diagram::=a diagram showing classes and the associations between them. [ uml3.gif ] [ uml.coll0.gif ] [ uml.coll1.jpg ] [ uml4.jpg ]

      18. class_utility::=A class with only static attributes and static functions, -- for example a math library. [ umlutility.gif ] [ umlutility.mdl ]

        collaboration_diagram=a description of the collaborations between objects as they fulfil a usecase. [ uml.collab.gif ]

      19. collaboration::=an interaction between one object or class with another object or class. Typically the first object or class invokes an operation of the other or accesses an attribute.
      20. collaborations::=plural of collaboration.

      21. communicating::=the process of sending and receiving data through a communication_association linking an actor and an usecase.
      22. communication_association::an association or link in a usecase_diagram connecting an actor to a usecase. [ uml.usecases.gif ]

      23. composition::= a strong form of the 'has_a' or APO relation so that deleting the whole automatically removes the parts as well. Composition fits when objects of one class are made up of parts that are objects of of other classes, for example when they are implemented using fields in structures, items in records, columns in a data base, or pieces of a document. However, in some cases, the responsibility for keeping an object alive changes during that objects life, and so that objects class would be shown as being parts of several different compositions. [ clock2.gif ] [ uml.period.gif ] [ uml.link.gif ]

      24. concrete::=the opposite of abstract - a concrete class is defined in enough detail so that objects can be constructed for it.

      25. 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" or frozen. [ uml.gen.gif ] [ uml.dynamic.gif ]
      26. constraints::=plural of constraint.

      27. constructor::stereotype=indicates that an operation creates a new object of its class. Notes. In UML the initial values of attributes can be indicated in the specification of a class and so constructors are optional. In many OO language like C++ and Java default attribute values are not permitted and so constructors are effectively mandatory. Also notice that a constructor should not be shown as returning any type of object.

        D E

      28. destructor::stereotype=indicates that an operator deletes an object of its class. Note a destructor is a C++ idea where its name is always the name of the class prefixed with a tilde symbol.

      29. dependencies::=plural of dependency.
      30. dependency::=a relationship between parts of an UML model drawn as a dashed line with an arrow head that indicates that if one thing changes then the change may effect the other thing. Often one thing uses the other thing(usage). [ uml.gen.gif ] [ usage.gif ]

      31. domain::= problem_domain | application_domain.

      32. 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. Also see frozen. [ uml.dynamic.gif ]

      33. end::=each association has 2 ends and associated with each end is ( a class, a role the association plays in the class, a multiplicity).

        F G H

      34. formal_parameter::=a parameter that is used in a parameterized definition in place of an actual_parameter that can be supplied later.

      35. frozen::=a property of an end of an association that no links are (added|deleted|moved) from an object at the frozen end.

      36. generalization::=relationship (is_a ) between a specialized class and a more general class where objects of the more specialized class ( the subtype) are automatically also instances of the more general type. It is typically easier to implement static generalizations in C++ by using inheritance than to implement dynamic forms. Dynamic generalizations need patterns developed by the GoF [ uml.gif ] [ uml.gen2.gif ] [ uml.gender.gif ] [ uml.shape.gif ] [ uml.dynamic.gif ]

        I J K

      37. icon::= a symbol that appears on a computer screen that may manipulated using a mous or other pointing device.
      38. icons::=plural of icon.

      39. interface::stereotype=indicates a set of operations that may be defined by one or more classes and used by one or more classes. An interface is an abstraction with no implementation and no attributes. [ uml.interface.gif ] [ uml.client.gif ]
      40. interfaces::=plural of interface.

      41. key::=an attribute or set of attributes of a class that uniquely identify a particular instance of the class.

        L M

      42. link::=a line connecting two boxes or other icons.

      43. MOF::="Meta Object Facility", CORBA interface describing a UML model, also see XMI.

      44. multiplicities::=plural of multiplicity.
      45. multiplicity::=numbers or sets of numbers (using a comma or range) placed at an end of an association indicating how many object of the closest type correspond thru the link to a single item at the other end. [ uml.period.gif ] [ uml.game.gif ] [ uml.coll1.jpg ] Note. Links that have many-to-one multiplicities are nearly always simpler to implement and easier to understand than those with muliplicities other than one at both ends.

        N O

      46. navigable::=an association that can be navigated in both directions. Note. if an association is not navigable it is simpler to implement it because storing an identifier of an object allows it to be found.
      47. navigate::verb=to gain access to a object by following an association linking one object to the other.
      48. navigated::=past participle of navigate..

      49. 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. [ uml.gen.gif ]

      50. objects::=plural of object.
      51. object::=following
        1. In analysis, an object is an instance of a class in the problem_domain.
        2. In design, an object is something with an unique identity that encapsulates some know-how (operations) and some values(attibutes).
        3. In code, an object is a piece of storage plus some sub-programs that have privileged access to that storage. [ object in glossary ]

      52. operations::=things that an object in a class knows how to do, in UML these are placed in the lowest compartment in a three compartment box. [ uml1.gif ]

        P Q

      53. package::=an icon in UML that looks like a folder and refers to another UML diagram that either exists or may be in the process of creation. [ uml.gen.gif ]
      54. packages::=plural of package.

      55. parameter::=actual_parameter | formal_parameter, In mathematics this is a "constant variable".
      56. parameterized::=a class or package in UML can be given a parameter and then for each possible value of the parameters a special version of the class or package is generated. Compare with an Ada generic and a C++ template. [ uml.template.gif ] [ uml.find.gif ]

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

      59. pointer::=a technique for implementing aggregation and linked data structures where an attribute of one object stores the physical address of the other object. Compare key and see navigable. [ uml.link.gif ]

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

        R S

      61. result::=the end point of a scenario.
      62. results::=the end points of a set of scenarios.

      63. roles::=plural of role.
      64. 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.
      65. 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.

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

      68. sequence::diagram=a diagram showing the sequence of messages passed between objects to achieve a given usecase. [ uml.seq.gif ]

      69. state::=a particular set of values for the attributes of an object.
      70. statechart::diagram=a way of documenting the states of an object and the changes that can occur to it during its life.
      71. state_diagram::=statechart. [ uml.states.gif ]

      72. 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. See frozen.

      73. stereotype::UML=a special note looking like this: <<example>> that adds to the meaning of a part of a UML diagram. [ uml.gen.gif ]

      74. 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 generalization arrow that has an open arrow head.

        T U V

      75. template::= C++ jargon for the UML parameterized class. [ uml.template.gif ] [ uml.find.gif ]

      76. usage::=a special kind of dependency where one piece of a program makes use of another part of the program. [ usage.gif ]

      77. usecase::=a set of scenarios sharing a class of similar actors achieving similar tangible results that is documented by a natural language text and pictured as an oval icon. [ uml.usecases.gif ]

      78. usecase_diagram::=a UML diagram that shows one or actors communicating with one or more usecases.

      79. usecases::=plural of usecase. [ uml.usecases.gif ]

      80. utility::=See class_utility.

      81. visibility::=an indicator(plus, minus, hash) indicating whether a rolename | attribute | operation can be accessed from outside a class. Rational Rose uses some neat little icons involving keys and locks to indicate the degree of visibility of attributes, operations, and roles. [ Privacy in uml1 ] [ uml.link.gif ]

        W X Y Z

      82. XMI::=" A standard way to present MOF meta-data modeling objects using XML". //ftp.pmg.org/pub/docs/ad/98-1005.pdf

      83. XML::= See http://cse.csusb.edu/dick/samples/xml.html


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

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

      87. OO::abbreviation=Object-Oriented.

      88. OMT::method=The Object Modelling Method developed by Rumbaugh et al that forms one of UML's parents.

      89. TBA::="To Be Announced", indicating work that needs completing.

        Parts of Speech

        In this glossary I sometimes indicate the syntactic class of a word used in English as well as UML.
      90. adjective::=qualifies a noun by adding properties to it.
      91. adverb::=qualifies a verb by adding properties to it.
      92. noun::=names something.
      93. verb::=indicates an action or relationship.


      94. tilde::= "~", indicates a destructor in C++.
      95. plus::="+", indicates public visibility for an operation or attribute.
      96. minus::="-", indicates private visibility for an operation or attribute.
      97. hash::="#", indicates protected visibility for an operation or attribute.
      98. range::="..", indicates a set of numbers lying between to values.
      99. colon::=":", used to separate a name of a parameter or attribute or operation from a class.
      100. comma::=","used to separate items in a set.

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

      See Also

    1. ROOT::= See http://cse.csusb.edu/rootproj/, This project incorporated object-oriented technology into the core of the BS degee in computer Science at CSUSB.

      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's IBM Web site.

    2. Rational::= See http://www.rational.com/

      Online Tutorials: [ http://csci.csusb.edu/dick/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 ] )