1 / 29

The Models are the Code - Executable UML

The Models are the Code - Executable UML. Lecture 4 - How to Build Class Models Paul Krause. Lecture 4 - How to Build Class Models. Specifications vs Things Interactions Roles working within our modelling goals Attributes. Aircraft Specification. Aircraft. Abstract. Concrete.

alank
Télécharger la présentation

The Models are the Code - Executable 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. The Models are the Code -Executable UML Lecture 4 - How to Build Class Models Paul Krause

  2. Lecture 4 - How to Build Class Models • Specifications vs Things • Interactions • Roles • working within our modelling goals • Attributes

  3. Aircraft Specification Aircraft Abstract Concrete Model number {I} Stall profile Weight Wingspan Fuel consumption Registration number {I} Maintenance status Assigned pilot Assigned mechanic Hours flown Properties common to a specific aircraft type Properties common to a specific aircraft instance Specification Classes Distinct lifecycles and properties R1 1 design is specified by 0..* specifies design of

  4. Specification Pattern Will rarely need a state model to define its behaviour Will normally need a state model to define its behaviour Abstract Concrete Widget Specification Widget R1 1 design is specified by 0..* specifies design of Model number {I} Serial number {I} design characteristics, references to sub-specifications or other related specifications characteristics that vary from widget to widget, even when the widgets are defined by the same widget specification

  5. ?? ?? Interaction Classes Flight Passenger Number {I} Airline {I} Departure date Departure time Departure airport Arrival date Arrival time Arrival airport R1 0..* is reserved for 0..* reserves Name Phone number Seat Assignment

  6. Reservation Ticket number {I} Airline {I, R1} Cost Class Seat assignment Interaction Classes Flight Passenger Number {I} Airline {I} Departure date Departure time Departure airport Arrival date Arrival time Arrival airport R1 0..* is reserved for 0..* reserves Name Phone number

  7. Delete once Wafer has been unloaded from the Inspection Station Role Classes R1 Wafer 0..* contains 0..1 is loaded into Inspection Station Wafer in Process Inspection Script R2 0..1 directs scanning of 0..1 is scanned according to Allignment Temperature Percent scan complete Area to cover Scan method

  8. Relative Roles Back Side Front Side APPLICATION NOTE: The flat shape can rotate in 3D space and must have exactly one bitmap image on each of its two sides

  9. Multiplicity • Remember, an important characteristic of an association is the number of instances (objects) that participate in each instance of the domain relationship • UML allows specific numbers in a multiplicity relation • In xUML the recommendation is to only use four kinds: • unconditional; 1, or 1..* • conditional; 0..1, or 0..*

  10. Relative Roles The arguments for making this multiplicity “2” seem compelling, but can we work within our modelling guidelines? R1 Flat Shape 1 can be shown by 1..* can show Side Colour Texture

  11. Two 1:1 associations? Flat Shape R1 Side 1 is front of 1 has front Colour Texture R2 1 is back of 1 has back But a Side is either the Front or the Back of a Flat Shape, not both!

  12. Two 1:1 associations? Flat Shape R1 Side 1 is front of 1 has front Colour Texture R2 1 is back of 1 has back But a Side is either the Front or the Back of a Flat Shape, not both!

  13. Two conditional associations? Flat Shape R1 Side 0..1 is front of 1 has front Colour Texture R2 0..1 is back of 1 has back But this says that a Side might exist that does not belong to any Flat Shape!

  14. Two conditional associations? Flat Shape R1 Side 0..1 is front of 1 has front Colour Texture R2 0..1 is back of 1 has back But this says that a Side might exist that does not belong to any Flat Shape!

  15. How about making the Sides attributes? Flat Shape ? Bitmap Image Front colour Front texture Back colour Back texture But we need to model the association between a Bitmap Image and a specific Side!

  16. Side Bitmap Image R1 0..* is drawn on 1 has drawn Colour Texture R4 Front Side Back Side has on front 1 has on back 1 R2 R3 is front of 1 is back of 1 Flat Shape Solution: Abstract Positional roles as Classes N.B. We have worked within our modelling goals and produced a better model!

  17. Two instances of Star Star SAO Number {I} Name Diameter Mass Distance 252838 Alpha Centauri 1.26 M km 1.1 x Sun 4.3 ly 131881 Sirius 4.9 M km 3 x Sun 8.7 ly What is an Attribute? “A quality or characteristic inherent in or ascribed to someone or something” The American Heritage Dictionary of the English Language Attributes: Prototypical characteristics Attribute Values: Characteristics of a specific instance

  18. Properties of Attributes • Purpose • Identification role • Dependency on other attributes • Value assignment • Universal meaning

  19. Purpose • Here the attribute either names or describes a class instance • Descriptive attributes • Size, Capacity, Colour, Stall speed • Naming attributes • Discovered names - Company name, Floor number, Driver’s licence number • Invented names - Pump ID, Transaction ID, Event ID • Using “ID” as a suffix makes it clear these names are the invention of an analyst

  20. Identification role • Every instance of a class is unique • Consequently, each object must have an attribute whose value can unambiguously identify that object • If an attribute is marked as an identifier, then it is constrained to have distinct values for each instance • In xUML there are three kinds of identifier • implicit identifiers • single-attribute identifiers • compound identifiers

  21. Camera ID {I} Location Zoom Implicit identifier location = right zoom = 2 location = centre zoom = 1 location = left zoom = 1.5

  22. Camera ID {I} Location Zoom Implicit identifier location = right zoom = 2 location = centre zoom = 1 But this identifier is not adding anything to the model other than guaranteeing uniqueness location = left zoom = 1.5

  23. Camera Location Zoom Implicit identifier location = right zoom = 2 location = centre zoom = 1 We can rely on an implicit identifier in this case to guarantee uniqueness location = left zoom = 1.5

  24. Implicit vs. Explicit Identifiers • In the preceding example we were only interested in the service each camera performed in a studio • We don’t actually care which precise physical camera maps onto the class instances so long as the attribute values are correct • But sometimes we may need to model a real-world identification scheme • SAO Number, Aircraft registration, Flight number • In these cases we use an explicit identifier • may consist of single or multiple attributes

  25. Two instances of Star Star SAO Number {I} Name Diameter Mass Distance 252838 Alpha Centauri 1.26 M km 1.1 x Sun 4.3 ly 131881 Sirius 4.9 M km 3 x Sun 8.7 ly Single explicit identifier In contrast to implicit identifiers, typically the values of explicit identifiers will not be assigned by the model compiler

  26. Licensed Vehicle State {I} License number {I} Colour Make Model Compound identifiers These two attributes together mark a single identifier (State + License number)

  27. Runway Direction {I} Side {I} Length Grade Referential attributes But we could have two runways with the same value for (Direction + Side) at different airports

  28. Runway Airport Direction {I} Side {I} Airport {I, R1} Length Grade Code {I} Current visibility Referential attributes R1 1 is located at 1..* is location of Refers to identifier of the associated Airport class (the renaming is legal)

  29. Summary • We have illustrated some good practice in developing class models and their associated attributes • Next time we will look at the remaining properties of attributes: • Dependency on other attributes • Value assignment • Universal meaning • Origin • Read Chapter 5 of Mellor and Balcer • also Chapters 1 & 2 of Starr

More Related