Extending UML

1
Extending UML
2
Why to extend UML?

• UML can be used to model any entity, not
  necessarily software products
• Some organizational concepts may not be directly
  supported by UML
• Example
• The structure of an organization is generally
  modeled using a class.
• A class supports only three compartments name
  of the class, attributes and methods
• But the organization has several components such
  as employees, departments and divisions
• See the diagrams on the next slide

3
Organization
Classname
Division 1
Division 2
Attributes
Department 1
Department 2
Methods
Employee 11 Employee 12
Employee 21 Employee 22
Department 3
Department 4
Supported by UML
Employee 31 Employee 32
Employee 41 Employee 42
Preferred by the designer/modeler
4
Why to extend UML? (continued)

• An organization may impose certain restrictions
  or standards to be followed in modeling
• Similar to design standards and coding standards
• Example
• All classes modeled must have the author name,
  last modified information etc. to be recorded in
  the model itself

5
Standard extensions of UML

• Tagged values
• Indicate additional information for each modeling
  element
• May serve dual purposes
• Administrative information such as date created,
  date modified, author of a model etc. can be
  recorded
• Technical information can provide details for
  programmer

6
Standard extensions of UML (continued)

• Constraints
• Conditions can be added to any modeling element
  or relationship to enrich the semantics of the
  application
• Stereotype extension
• The most commonly used extension
• Lets the designer create a new modeling element
  by extending one of the predefined modeling
  element

7
Tagged Values

• Used to add specific properties to modeling
  elements
• Represented as
• lttaggt ltvaluegt
• curly brackets are part of the syntax
• Can be added anywhere in the model
• Both lttaggt and ltvaluegt are represented as strings
• Both lttaggt and ltvaluegt are UNINTERPRETED ?
  designer can put any string value for lttaggt or
  ltvaluegt

8
Tagged values example 1
Check inventory
Update inventory
Database
Inventory manager
Inventory System
of managers 1
Tagged value
9
Tagged values example 2
Account
author Dr. Jones, created on Dec 11, 2003
tagged values
Account number Integer Owner id
Integer Balance Double initial value 0
Deposit (amt Double) Withdraw (amt Double)
10
Tagged values Example 3
Season change / changeColor()
Fall duration 3 months
Winter duration 3 months
Tagged values
11
Stereotypes

• Extends a meta class
• Allows user to create his/her own modeling
  element
• Example
• Extend the ltclassgt definition to introduce
  additional information in it
• Same meta class can be extended several times
  into different stereotypes
• Includes, in the representation,
• ltltstereotype namegtgt
• Can associate a graphical icon with a stereotype,
  but it is optional

12
ltltOrganizationgtgt
ltltclassgtgt
Organization Name
Class name
Division 1
Division 2
Attributes
Department 1
Department 2
Methods
Employee 11 Employee 12
Employee 21 Employee 22
Department 3
Department 4
Standard or built-in stereotype, called ltltclassgtgt
Employee 31 Employee 32
Employee 41 Employee 42
User-defined stereotype, called ltltOrganizationgtgt
Note a graphical icon is attached to the
stereotype ltltOrganizationgtgt
13
Textual Description of the stereotype
ltltOrganizationgtgt

• This stereotype has three components
• An organizational name
• One or more Divisions
• Each Division includes one or more
  Departments
• A Department may optionally have zero or more
  employees
• The graphical icon attached to this stereotype
  must show all employees of a department inside a
  box within the department

14
Defining an interface using stereotype
ltltInterfacegtgt
MathFunctions
sin (x Double) Double cos (x Double)
Double tan (x Double) Double tanInverse (x
Double) Double
Note there is no special graphical icon
introduced for ltltinterfacegtgt
15
Object Constraint Language (OCL)

• Previously part of UML now, it is a separate
  entity
• Started with simple syntax now, it is enhanced
  into a formal constraint language by itself
• A UML model DOES NOT NEED to include OCL
  expressions (constraints)
• However, use of OCL along with UML enriches the
  semantics of the application being modeled

16
Why OCL?

• Constraints are important in a model to
• Provide rich semantics
• Capture some intrinsic properties of the
  application being modeled
• Example only one manager account in an ATM
  system
• To correctly refine a model towards
  implementation
• Otherwise, programmers may have too many choices
  or the model will become vague

17
Why OCL? (continued)

• Constraints can be expressed in natural
  language(s)
• Inherent ambiguities in natural languages
• Constraints may be misunderstood creating
  additional complexities to the problem
• Longer constraints become confusing or difficult
  to specify
• Not able to justify or derive additional
  properties from such constraints

18
More about OCL

• Developed as a business modeling language within
  IBM Insurance Division
• A pure and formal constraints language with no
  side effects
• i.e., including OCL expressions in a model will
  not change the model (or the values in the model)
  at any time
• It only enriches the model with additional
  constraints

19
More about OCL (continued)

• OCL is not a programming language
• OCL is independent of implementation and hence
  implementation languages
• OCL expressions are conditions that are discrete
  and discontinuous
• Two sets of constraints on the same model may be
  totally different and may be specify two
  different properties of the model
• OCL is STRONGLY TYPED
• Every expression in OCL must be associated with a
  type often, these are Boolean expressions

20
Where to use OCL within a UML model?

• To specify invariants on classes and types
• An invariant is a condition that is true for the
  lifetime of a class or a type
• To specify pre- and post-conditions on operations
• Precondition describes a condition that must be
  true before the operation is invoked
• Post-condition describes a condition that must be
  true after the operation is completed
• To specify guards and conditions on the model

21
Specifying an invariant

• Context Company inv
• self.numberOfEmployees lt 50
• Asserts that the attribute numberOfEmployees in
  class Company must be always less than or equal
  to 50.
• Keywords are shown in bold letters

22
Possible alternative syntax for the same invariant

• Context c Company inv
• c.numberOfEmployees lt 50
• Context c Company inv maxEmployees
• c.numberOfEmployees lt 50

Name of the invariant
23
Specifying pre and post-conditions

• Context classname operationName
• (param1 Type1 , , paramN TypeN)
• ReturnType
• pre param1 gt param2
• post result param1 if param1 gt paramK
• paramK if paramK gt param1

Keywords are shown in bold letters You can also
attach names to pre- and post-conditions
24
Specifying guards and conditions

• Can be specified anywhere in the model using one
  or more modeling elements and on one or more
  modeling elements
• See conditions in Class diagrams, State
  transitions diagrams and interactive diagrams
  (sequence and collaboration diagrams)
• Context is implicit when specifying a guard or
  condition

25
Primitive types and operators
26
Exercises

• In the ATM example, introduce two types of
  accounts one with permission for overdraft and
  another without the privilege for overdraft. Show
  the class diagram. Include tagged values. Define
  invariant for each class and pre and
  post-conditions for each method using OCL.