1 / 26

Extending UML

Extending UML. 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.

swann
Download Presentation

Extending UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 C-S 546

  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 C-S 546

  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 C-S 546

  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 C-S 546

  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 C-S 546

  7. Tagged Values • Used to add specific properties to modeling elements • Represented as { <tag> = <value> } • curly brackets are part of the syntax • Can be added anywhere in the model • Both <tag> and <value> are represented as strings • Both <tag> and <value> are UNINTERPRETED  designer can put any string value for <tag> or <value> C-S 546

  8. Tagged values – example 1 Check inventory Update inventory Database Inventory manager Inventory System { # of managers = 1 } Tagged value C-S 546

  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) C-S 546

  10. Tagged values – Example 3 Season change / changeColor() Fall {duration = 3 months} Winter {duration = 3 months} Tagged values C-S 546

  11. Stereotypes • Extends a meta class • Allows user to create his/her own modeling element • Example • Extend the <class> definition to introduce additional information in it • Same meta class can be extended several times into different stereotypes • Includes, in the representation, <<stereotype name>> • Can associate a graphical icon with a stereotype, but it is optional C-S 546

  12. <<Organization>> <<class>> 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 <<class>> Employee 31 Employee 32 Employee 41 Employee 42 User-defined stereotype, called <<Organization>> Note: a graphical icon is attached to the stereotype <<Organization>> C-S 546

  13. Textual Description of the stereotype <<Organization>> • This stereotype has three components • An organizational name • One or more “Division”s • Each “Division” includes one or more “Department”s • 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 C-S 546

  14. Defining an interface using stereotype <<Interface>> 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 <<interface>> C-S 546

  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 C-S 546

  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 C-S 546

  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 C-S 546

  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 C-S 546

  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 C-S 546

  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 C-S 546

  21. Specifying an invariant Context Company inv : self.numberOfEmployees <= 50 Asserts that the attribute “numberOfEmployees” in class “Company” must be always less than or equal to 50. Keywords are shown in bold letters C-S 546

  22. Possible alternative syntax for the same invariant Context c : Company inv : c.numberOfEmployees <= 50 Context c : Company inv maxEmployees : c.numberOfEmployees <= 50 Name of the invariant C-S 546

  23. Specifying pre and post-conditions Context classname :: operationName (param1 : Type1 , …, paramN : TypeN) : ReturnType pre : param1 > param2 post : result = param1 if param1 > paramK = paramK if paramK > param1 Keywords are shown in bold letters You can also attach names to pre- and post-conditions C-S 546

  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 C-S 546

  25. Primitive types and operators C-S 546

  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. C-S 546

More Related