1 / 23

The Models are the Code - Executable UML

The Models are the Code - Executable UML. Lecture 5 - Attributes and Relations Paul Krause. Lecture 5 - Attributes and Relations. Continue with properties of attributes Introduction to xUML relationship types. Properties of Attributes. Purpose Identification role

andrewmjohnson
Download Presentation

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 5 - Attributes and Relations Paul Krause

  2. Lecture 5 - Attributes and Relations • Continue with properties of attributes • Introduction to xUML relationship types

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

  4. Colour temperature Intensity x Location y Location z Location Change SpotLight ID (Implicit) and the values of any of the other attributes may change. But the value of any other attribute may be changed independently of the others. Spot Light Dependence on other attributes Rule 1: • The values of all non-identifying attributes depend only on the identifier

  5. Name Home address Birthdate Company name Work address Change the Company name and the address must (normally) change Contact Dependence on other attributes

  6. Name Home address Birth date Name {I} Address Phone Cafeteria quality R1 0..* employs 0..1 works at Company Contact Dependency on other attributes

  7. Vehicle ID {I} Route ID {I} Accumulated delay Estimated completion time Battery charge These two attributes depend on the whole ID This attribute depends only on Vehicle ID Automated Vehicle on Route Dependence on other attributes Rule 2: • Each non-identifying attribute must depend on the whole ID {

  8. Vehicle ID {I, R1} Route ID {I} Accumulated delay Estimated completion time ID {I} Weight Battery charge Time since last service Automated Vehicle on Route Vehicle Dependence on other attributes R1 1 uses 0..1 is in service as

  9. Vehicle ID {I, R1} Route ID {I} Accumulated delay Estimated completion time Automated Vehicle on Route Value Assignment

  10. Vehicle ID {I, R1} Route ID {I} Accumulated delay Estimated completion time Automated Vehicle on Route Value Assignment The values assigned to these non-identifier attributes can be changed to any other legal value }

  11. Vehicle ID {I, R1} Route ID {I} Accumulated delay Estimated completion time But we can’t, for example, change the value of the Route ID (an identifier attribute) without checking that a duplicate instance is not being created Automated Vehicle on Route Value Assignment

  12. Mark spacing Pulse rate \Rotational speed The “\” indicates this attribute is computationally dependent on other attributes in the model Shaft Encoder Motor Shaft Value Assignment - Computational dependence R1 1 rotational speed is detected by 1 detects rotational speed of self.Rotational_speed = my_Shaft_Encoder.Mark_spacing * my_Shaft_Encoder.Pulse_rate

  13. Universal meaning? • Does an attribute always have meaning in a specific class? • If it does not, then again you may need to modify the class model: • Never applicable for some instances • then use a generalisation hierarchy and specialise these instances • Not applicable at some moment • Then specialise the class into distinct roles

  14. Manufacturer Weight retracted status Uninstalled Landing Gear Installed Landing Gear Landing Gear Universal meaning? R1

  15. Binary reflexive Binary Non-reflexive Association Class Generalisation {disjoint, complete} Executable UML Relationship Types

  16. Lecture 5 - Associations • Naming associations • Binary non-reflexive associations • Binary reflexive associations • Association Classes • Loops and constraints

  17. cardio_7b cardio_7b cardio_7b cardio_7b cardio_7b cardio_1b def_87c Naming Associations preset files currently loaded default Library of presets on local hard drive

  18. Application Note • A medical ultra-sound scanner station operates with hundreds of parameter settings. • A complete collection of parameters with initial value settings can be stored in a preset file. • The capabilities of the ultrasound scanner depend entirely on what preset file has been loaded. • Upon power up, the scanner automatically loads values from whichever preset file has been designated as the station default. Leon Starr - How to Build Class Models

  19. Serial number {I} Station Text Book Solution Preset File * Name uses • Which preset is currently controlling the station? • How do we ensure only one preset is controlling the station at a time? • Which preset file is loaded at power up?

  20. Application rules • At any time, a Station is using the parameter values from one Preset File • Exactly one Preset File is designated as the default for a given station • Any Preset File may be designated as the default for a given Station

  21. Serial number {I} Station Try harder! Preset File 0..1 1 Name is using the values from supplies values to control

  22. Serial number {I} Station Default file Preset File 0..1 1 Name uses values by default from is default source of values for

  23. Serial number {I} Station The complete solution R1 0..1 1 Preset File supplies values to control is using the values from Name R2 0..1 1 is default source of values for uses values by default from

More Related