1 / 14

Optional Case Study - Chapter 3

Optional Case Study - Chapter 3. Outline 3.1 Introduction 3.2 Class Attributes 3.3 Statechart Diagrams 3.4 Elevator Statechart Diagram 3.5 Activity Diagrams 3.6 Conclusion. 3.1 Introduction. Previous chapter First phase - identify classes

johndstewart
Télécharger la présentation

Optional Case Study - Chapter 3

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. Optional Case Study - Chapter 3 Outline 3.1 Introduction 3.2 Class Attributes 3.3 Statechart Diagrams 3.4 Elevator Statechart Diagram 3.5 Activity Diagrams 3.6 Conclusion

  2. 3.1 Introduction • Previous chapter • First phase - identify classes • List nouns, created separate class for each category • Represented classes and relationships in UML class diagram • Classes have • Attributes - data • Focus of this chapter • Example: A radio's attributes include volume setting, AM/FM • Operations - functions • Focus of Chapter 4

  3. 3.2 Class Attributes • Class Attributes • Describe classes • Identify attributes by looking for descriptive words in problem statement • Create an attribute for each descriptive word/phrase • Create attributes to represent data a class may need

  4. 3.2 Class Attributes (II)

  5. 3.2 Class Attributes (III) • Notice • Bell and Building have no attributes • As we continue the case study, we will add, modify, and delete information about the classes • Attributes • Name • Type • Initial value • If no initial value, only name and type shown • Random numbers • Example: capacity : int = 1 • For now, not overly concerned with types or initial values • Include information we can get from problem statement

  6. 3.2 Class Attributes (III) - Class Diagram with Attributes Elevator Clock Door currentFloor : int = 1 time : int = 0 open : bool = false direction : enum = up capacity : int = 1 arrivalTime : int Floor moving : bool = false Bell capacity : int = 1 <none yet> occupied : bool = false Scheduler Light floor1ArrivalTime : int FloorButton floor2ArrivalTime : int on : bool = false pressed : bool = false Person Person ElevatorButton Building ID : int ID : int pressed : bool = false <none yet>

  7. button press Pressed Not pressed button reset 3.3 Statechart Diagrams • States • Describe condition of an object at a given point in time • Statechart diagrams (state diagrams) • Express how, and under what conditions, objects change state • Format • Rounded rectangle - represents a state • Solid circle with arrowhead - points to initial state • Solid lines with arrows - transitions • Object can transition in response to an event • Name of event written near line

  8. button press [need to move] button press [other floor]/ arrivalTime = currentTime + 5 Servicing Floor when [currentTime == arrivalTime] button press [current floor] Waiting [no further requests] Moving exit/ close door 3.4 Elevator Statechart Diagram • Guard condition - transition only occurs if condition met • Elevator transitions from "Waiting" state to "Servicing Floor" state when a button is pressed on the elevator's floor • Forward slash / - indicates action with state change

  9. 3.4 Elevator Statechart Diagram (II) • true condition • State transition if a certain condition is true when [currentTime == arrivalTime] • Elevator transitions from "Moving" state to "Servicing Floor" state • Actions • Model actions by splitting state into Top: state name Bottom: state actions • Exit - action label, indicates an action to be performed when an object exits a state • Elevator must "close door" when exits "Servicing Floor" state • If elevator needs to move, it must first close the door

  10. 3.5 Activity Diagrams • Activity diagram • Variation of statechart diagram • Statechart diagram does not how the elevator decides if it needs to move • Models what object does during its lifetime (its activities)

  11. 3.5 Activity Diagrams (II) • Format • Activities modeled as ovals (name inside oval) • Solid line with arrowhead - connects two activities • Indicates order activities are performed • Solid circle - starting point of sequence of activities • In our example, each time button pressed, sequence of activities are executed • Double circle (bull's eye) - ending point of diagram • Diamond - decision • Each line extending from diamond is a different set of activities • Guard condition indicates which path to choose in square brackets [ ]

  12. button pressed] [ in motion] [ currentTime == current floor button [ [ arrivalTime] not pressed] current floor [ Close door button pressed] Move to other floor Stop moving currentTime < [ arrivalTime] Reset elevator button Ring bell Guard conditions Open door 3.5 Activity Diagram (III)

  13. 3.5 Activity Diagrams (IV) • When button pressed • Elevator in "Moving" state • Path terminates (elevator cannot immediately perform any activities) • If button pressed on elevator's current floor • Reset button • Ring bell • Open door • If button not on elevator's floor • Close door • Move to other floor • Stop at other floor

  14. 3.6 Conclusion • We have • Expanded knowledge of classes • Represented new knowledge in class diagram • Used statecharts • Gained information on how our system works • Chapters 4 and 5 • Determine operations associated with classes • Determine how classes interact (collaborate) • Randomness arrivalTime = currentTime + ( 5 + rand() % 16 ); • Can be used to schedule next arrival of person on floor

More Related