Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Unified Modeling Language

3.235 Aufrufe

Veröffentlicht am

Veröffentlicht in: Bildung, Technologie
  • Login to see the comments

Unified Modeling Language

  1. 1. LOGO Introduction to UML Prof. Erwin M. Globio, MSIT Senior IT Lecturer Far Eastern University
  2. 2. What is UML?Unified Modeling Language  OMG Standard, Object Management Group  Based on work from Booch, Rumbaugh, JacobsonUML is a modeling language to express and design documents, software  Particularly useful for OO design  Not a process, but some have been proposed using UML  Independent of implementation language 2
  3. 3. Why use UML Open Standard, Graphical notation for  Specifying, visualizing, constructing, and documenting software systems Language can be used from general initial design to very specific detailed design across the entire software development lifecycle Increase understanding/communication of product to customers and developers Support for diverse application areas Support for UML in many software packages today (e.g. Rational, plugins for popular IDE‟s like JBuilder, NetBeans, Eclipse) Based upon experience and needs of the user community 3
  4. 4. Brief History Inundated with methodologies in early 90‟s  Booch, Jacobson, Yourden, Rumbaugh 1989-1994: 50+ OO methods Clearly prominent methods • Jacobson‟s OOSE: support for use cases to capture requirements • Booch: expressive during design/construction • Rumbaugh‟s OMT: analysis+ data intensive systems 1994: Rumbaugh joined Booch at Rational 1995: Jacobson joined Rational 1996: UML version 0.9 1997 UML 1.1 from OMG includes input from others, e.g. Yourden 1997: Standardized by OMG  UML 1.1…1.4 (2.0)  UML v2.0 current version 4
  5. 5. History of UML 5
  6. 6. Contributions to UML 6
  7. 7. Conceptual model of UML UML Building Rules Common blocks name, scope, visibility mechanisms Things Relations Diagrams Class Dependency Object Structural Behavioral Grouping Annotate Association Use caseClass Interaction Generalization SequenceInterface Package Note State machine Realization CollaborationActive class StatechartComponent ActivityNode Use case Component Collaboration Deployment 7
  8. 8. Systems, Models and ViewsA model is an abstraction describing a subset of a systemA view depicts selected aspects of a modelA notation is a set of graphical or textual rules for depicting viewsViews and models of a single system may overlap each otherExamples:System: AircraftModels: Flight simulator, scale modelViews: All blueprints, electrical wiring, fuel system 8
  9. 9. Systems, Models and Views Flightsimulator Blueprints Aircraft Model 2 View 2 View 1System View 3 Model 1 Electrical Wiring Scale Model 9
  10. 10. UML Models, Views, DiagramsUML is a multi-diagrammatic language  Each diagram is a view into a model • Diagram presented from the aspect of a particular stakeholder • Provides a partial representation of the system • Is semantically consistent with other views  Example views 10
  11. 11. Models, Views, Diagrams 11
  12. 12. Summary of diagram kinds in UML (nine concrete kinds)  Structural diagrams  Static structural diagrams • Class diagrams • Object diagrams  Implementation diagrams • Component diagrams • Deployment diagrams  Behavior diagrams  Use case diagrams  Interaction diagrams • Sequence diagrams • Collaboration diagrams  Statechart diagrams  Activity diagrams 12
  13. 13. UML BaselineUse Case DiagramsClass DiagramsPackage DiagramsInteraction Diagrams  Sequence  CollaborationActivity DiagramsState Transition DiagramsDeployment Diagrams 13
  14. 14. ViewsStatic Dynamic  Use case  Sequence  Class  Collaboration  Object  Statechart  Component  Activity  Deployment 14
  15. 15. How Many Views?Views should to fit the context  Not all systems require all views  Single processor: drop deployment view  Single process: drop process view  Very small program: drop implementation viewA system might need additional views  Data view, security view, … 15
  16. 16. Basic Modeling StepsUse Cases  Capture requirementsDomain Model  Capture process, key classesDesign Model  Capture details and behaviors of use cases and domain objects  Add classes that do the work and define the architecture 16
  17. 17. Use Case Modeling: Core ElementsConstruct Description Syntaxuse case Describes what a system /subsystem/class/interface does. A set of sequences of actions UseCaseName performed by a system to yield an observable result to an actor.actor A coherent set of roles that users of use cases play when interacting with these use cases. They live outside the ActorName system.system Represents the boundary between theboundary physical system and the actors who interact with the physical system. 17
  18. 18. Use Case Modeling: Core RelationshipsConstruct Description Syntaxassociation The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other.generalization A taxonomic relationship between a more general use case and a more specific use case.extend A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be <<extend>> inserted into the behavior defined for the base use case. 18
  19. 19. Use Case Modeling: Core Relationships (cont’d)Construct Description Syntaxinclude An relationship from a base use case to an inclusion use case, specifying how the <<include>> behavior for the inclusion use case is inserted into the behavior defined for the base use case. 19
  20. 20. Use Case Diagram The same person Telephone Catalog (or system) may play the roles of Check status a number of actors at the same time Place Salesperson order Fill ordersCustomer Shipping Clerk Billing Establish System credit Supervisor 20
  21. 21. Use Case Diagrams  Used during requirements elicitation to represent external behavior  Actors represent roles, that is, a type of user of the systemPassenger  Use cases represent a sequence of interaction for a type of functionality; summary of scenarios  The use case model is the set of all use cases. It is a complete description of the PurchaseTicket functionality of the system and its environment 21
  22. 22. Actors An actor models an external entity which communicates with the system:  User  External systemPassenger  Physical environment An actor has a unique name and an optional description. Examples:  Passenger: A person in the train  GPS satellite: Provides the system with GPS coordinates 22
  23. 23. Use Case A use case represents a class of functionality provided by the system as an event flow. A use case consists of:PurchaseTicket Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements 23
  24. 24. Use Case Diagram: ExampleName: Purchase ticket Event flow: 1. Passenger selects theParticipating actor: Passenger number of zones to be traveled.Entry condition: 2. Distributor displays the Passenger standing in front of ticket distributor. amount due. Passenger has sufficient 3. Passenger inserts money to purchase ticket. money, of at least the amount due.Exit condition: 4. Distributor returns Passenger has ticket. change. 5. Distributor issues ticket. 24
  25. 25. The <<extends>> Relationship  <<extends>> relationships represent exceptional or seldom invoked cases. Passenger  The exceptional event flows are factored out of the main event flow for clarity.  Use cases representing exceptional flows can extend more than one use case. PurchaseTicket  The direction of a <<extends>> relationship is to the extended use case <<extends>> <<extends>> <<extends>>OutOfOrder <<extends>> TimeOut Cancel NoChange 25
  26. 26. The <<includes>> Relationship  <<includes>> relationship represents behavior that is factored out of the use case. Passenger  <<includes>> behavior is factored out for reuse, not PurchaseMultiCard because it is an exception.PurchaseSingleTicket  The direction of a <<includes>> <<includes>> relationship is to the using use <<includes>> case (unlike <<extends>> relationships). CollectMoney <<extends>> <<extends>> NoChange Cancel 26
  27. 27. Use Cases are useful to…Determining requirements  New use cases often generate new requirements as the system is analyzed and the design takes shape.Communicating with clients  Their notational simplicity makes use case diagrams a good way for developers to communicate with clients.Generating test cases  The collection of scenarios for a use case may suggest a suite of test cases for those scenarios. 27
  28. 28. Use Case Diagrams: SummaryUse case diagrams represent external behaviorUse case diagrams are useful as an index into the use casesUse case descriptions provide meat of model, not the use case diagrams.All use cases need to be described for the model to be useful. 28
  29. 29. What is structural modeling?Structural model: a view of a system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations. 29
  30. 30. Class DiagramsGives an overview of a system by showing its classes and the relationships among them.  Class diagrams are static  they display what interacts but not what happens when they do interactAlso shows attributes and operations of each classGood way to describe the overall architecture of system components 30
  31. 31. Structural Modeling: Core ElementsConstruct Description Syntaxclass a description of a set of objects that share the same attributes, operations, methods, relationships and semantics.interface a named set of operations that characterize the behavior of an element. «interface»component a modular, replaceable and significant part of a system that packages implementation and exposes a set of interfaces.node a run-time physical object that represents a computational resource. 31
  32. 32. Structural Modeling: Core Elements (cont’d)Construct Description Syntaxconstraint¹ a semantic condition or restriction. {constraint}¹ An extension mechanism useful for specifying structural elements. 32
  33. 33. Structural Modeling: Core RelationshipsConstruct Description Syntaxassociation a relationship between two or more classifiers that involves connections among their instances.aggregation A special form of association that specifies a whole-part relationship between the aggregate (whole) and the component part.generalization a taxonomic relationship between a more general and a more specific element.dependency a relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element). 33
  34. 34. Structural Modeling: Core Relationships (cont’d)Construct Description Syntaxrealization a relationship between a specification and its implementation. 34
  35. 35. Class Diagram PerspectivesWe draw Class Diagrams under three perspectives  Conceptual • Software independent • Language independent  Specification • Focus on the interfaces of the software  Implementation • Focus on the implementation of the software 35
  36. 36. Classes – Not Just for Code TariffSchedule Name Table zone2price Enumeration getZones() TariffSchedule Price getPrice(Zone) zone2price Attributes getZones() getPrice() Signature OperationsA class represent a concept TariffScheduleA class encapsulates state (attributes) and behavior (operations).Each attribute has a type.Each operation has a signature.The class name is the only mandatory information. 36
  37. 37. Instances tarif_1974:TarifSchedule zone2price = { {‘1’, .20}, {‘2’, .40}, {‘3’, .60}}An instance represents a phenomenon.The name of an instance is underlined and can contain the class of the instance.The attributes are represented with their values. 37
  38. 38. Actor vs InstancesWhat is the difference between an actor , a class and an instance?Actor:  An entity outside the system to be modeled, interacting with the system (“Passenger”)Class:  An abstraction modeling an entity in the problem domain, must be modeled inside the system (“User”)Object:  A specific instance of a class (“Joe, the passenger who is purchasing a ticket from the ticket distributor”). 38
  39. 39. UML Class Notation A class is a rectangle divided into three parts  Class name  Class attributes (i.e. data members, variables)  Class operations (i.e. methods) Modifiers  Private: -  Public: +  Protected: #  Static: Underlined (i.e. shared among all members of the class) Abstract class: Name in italics Employee -Name : string +ID : long #Salary : double +getName() : string +setName() -calcInternalStuff(in x : byte, in y : decimal) 39
  40. 40. UML Class Notation Lines or arrows between classes indicate relationships  Association • A relationship between instances of two classes, where one class must know about the other to do its work, e.g. client communicates to server • indicated by a straight line or arrow  Aggregation • An association where one class belongs to a collection, e.g. instructor part of Faculty • Indicated by an empty diamond on the side of the collection  Composition • Strong form of Aggregation • Lifetime control; components cannot exist without the aggregate • Indicated by a solid diamond on the side of the collection  Inheritance • An inheritance link indicating one class a superclass relationship, e.g. bird is part of mammal • Indicated by triangle pointing to superclass 40
  41. 41. Binary AssociationBinary Association: Both entities “Know About” each other myB.service(); myA.doSomething(); Optionally, may create an Associate Class 41
  42. 42. Unary AssociationA knows about B, but B knows nothing about A myB.service(); Arrow points in direction of the dependency 42
  43. 43. AggregationAggregation is an association with a “collection-member” relationship void doSomething() Hollow diamond on aModule.service(); the Collection side No sole ownership implied 43
  44. 44. CompositionComposition is Aggregation with:Lifetime control; components cannot exist without the aggregate Lifetime Control (owner controls construction, destruction) Part object may belong to only one whole object Employee Team -Name : string -members : Employee +ID : long 1 #Salary : double -adfaf : bool * +getName() : string +setName() -calcInternalStuff(in x : byte, in y : decimal) members[0] = new Employee(); … Filled diamond on delete members[0]; side of the Collection 44
  45. 45. InheritanceStandard concept of inheritance Base Class Derived Class class B() extends A … 45
  46. 46. UML MultiplicitiesLinks on associations to specify more details about the relationship Multiplicities Meaning zero or one instance. The notation n . . 0..1 m indicates n to m instances. no limit on the number of instances 0..* or * (including none). 1 exactly one instance 1..* at least one instance 46
  47. 47. UML Class Example 47
  48. 48. Association DetailsCan assign names to the ends of the association to give further information Employee Team -group -Name : string -members: Employee -individual +ID : long 1 #Salary : double -adfaf : bool * +getName : string () +setName () -calcInternalStuffin x : byte, in y : decimal ( ) 48
  49. 49. From Problem Statement To Object ModelProblem Statement: A stock exchange lists many companies. Each company is uniquely identified by a ticker symbolClass Diagram: StockExchange * * Company Lists tickerSymbol 49
  50. 50. From Problem Statement to CodeProblem Statement : A stock exchange lists many companies.Each company is identified by a ticker SymbolClass Diagram: StockExchange * * Company Lists tickerSymbolJava Code public class StockExchange { private Vector m_Company = new Vector(); }; public class Company { public int m_tickerSymbol; private Vector m_StockExchange = new Vector(); }; 50
  51. 51. Object Modeling in Practice: Class Identification Foo Dinero CustomerId Deposit() Withdraw() GetBalance() Class Identification: Name of Class, Attributes and Methods 51
  52. 52. Object Modeling in Practice: Encourage Brainstorming “Dada” Foo Dinero Dinero CustomerId CustomerId Account Deposit() Deposit() Withdraw() Withdraw() Dinero GetBalance() GetBalance() CustomerId Deposit() Naming is important! Withdraw() Is Foo the right name? GetBalance() 52
  53. 53. Object Modeling in Practice Account Betrag Customer AccountId Bank NameName Deposit() CustomerId Withdraw() GetBalance() 1) Find New Objects 2) Iterate on Names, Attributes and Methods 53
  54. 54. Object Modeling in Practice: A Banking System Account Dinero * Has Customer Bank AccountId CustomerId Name Name Deposit() CustomerId Withdraw() GetBalance() 1) Find New Objects 2) Iterate on Names, Attributes and Methods 3) Find Associations between Objects 4) Label the assocations 5) Determine the multiplicity of the assocations 54
  55. 55. Practice Object Modeling: Iterate, Categorize! Account Bank CustomerName * Amount * Has Name AccountId CustomerId Deposit() Withdraw() GetBalance() CustomerId() Savings Checking Mortgage Account Account Account Withdraw() Withdraw() Withdraw() 55
  56. 56. Static vs. Dynamic DesignStatic design describes code structure and object relations  Class relations  Objects at design time  Doesn‟t changeDynamic design shows communication between objects  Similarity to class relations  Can follow sequences of events  May change depending upon execution scenario  Called Object Diagrams 56
  57. 57. Object DiagramsShows instances of Class Diagrams and links among them  An object diagram is a snapshot of the objects in a system • At a point in time • With a selected focus – Interactions – Sequence diagram – Message passing – Collaboration diagram – Operation – Deployment diagram 57
  58. 58. Object DiagramsFormat is  Instance name : Class name  Attributes and Values  Example: 58
  59. 59. Objects and LinksCan add association type and also message type 59
  60. 60. Package DiagramsTo organize complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elementsNotation  Packages appear as rectangles with small tabs at the top.  The package name is on the tab or inside the rectangle.  The dotted arrows are dependencies. One package depends on another if changes in the other could possibly force changes in the first.  Packages are the basic grouping construct with which you may organize UML models to increase their readability 60
  61. 61. ExamplePackage 1 Package 2 Package 3 61
  62. 62. ExampleSubsystem Name Package 1 Package 2 Package 3 62
  63. 63. Package Example DispatcherInterfaceNotification IncidentManagement 63
  64. 64. More Package Examples 64
  65. 65. Interaction DiagramsInteraction diagrams are dynamic -- they describe how objects collaborate.A Sequence Diagram:  Indicates what messages are sent and when  Time progresses from top to bottom  Objects involved are listed left to right  Messages are sent left to right between objects in sequence 65
  66. 66. What are interactions?Interaction: describes a collection of communications between instances, including all ways to affect instances, like operation invocation, as well as creation and destruction of instancesThe communications are partially ordered (in time) 66
  67. 67. Interactions: Core ElementsConstruct Description SyntaxInstance An entity with a unique identity and(object, to which a set of operations can be namedata value, applied (signals be sent) and which attr valuescomponent has a state that stores the effects ofinstance the operations (the signals).etc.)Action A specification of an executable textual statement. A few different kinds of actions are predefined, e.g. CreateAction, CallAction, DestroyAction, and UninterpretedAction. 67
  68. 68. Interactions: Core Elements (cont’d)Construct Description SyntaxStimulus A communication between two instances.Operation A declaration of a service that can textual be requested from an instance to effect behavior.Signal A specification of an asynchronous «Signal» Name stimulus communicated between parameters instances. 68
  69. 69. Interaction: Core RelationshipsConstruct Description SyntaxLink A connection between instances.Attribute Link A named slot in an instance, which textual holds the value of an attribute. 69
  70. 70. Different kinds of arrows Procedure call or other kind of nested (synchronous) flow of control (caller waits for the callee to return) Return Asynchronous flow of control (no waiting, no nesting, caller returns immediately) 70
  71. 71. Example: Different Arrows Nested Flow Nested Flow Asynchronous flowteller : Order : Article teller : Order : Article caller exchange callee lift receiver getValue getValue dial tone price price dial digit dial digit getName getName ringing tone ringing signal lift receiver 71
  72. 72. Interaction diagram tourShow interactions between instances in the model  graph of instances (possibly including links) and stimuli  existing instances  creation and deletion of instancesKinds  sequence diagram (temporal focus)  collaboration diagram (structural focus) 72
  73. 73. Interaction diagramsSequence Diagram Collaboration Diagramx y z 1.1: a 1.2: c a x y b 1.1.1: b c z 73
  74. 74. Sequence Diagram Format Actor from Use Case Objects 1 2Activation 3 4 Lifeline Calls = Solid Lines Returns = Dashed Lines 74
  75. 75. Sequence Diagram : Destruction Shows Destruction of b (and Construction) 75
  76. 76. Sequence Diagram : Timing Slanted Lines show propagation delay of messages Good for modeling real-time systemsIf messages cross this is usually problematic – race conditions 76
  77. 77. Sequence Example: Alarm SystemWhen the alarm goes off, it rings the alarm, puts a message on the display, notifies the monitoring service 77
  78. 78. Sequence Diagram ExampleHotel Reservation 78
  79. 79. Collaboration DiagramCollaboration Diagrams show similar information to sequence diagrams, except that the vertical sequence is missing. In its place are:  Object Links - solid lines between the objects that interact  On the links are Messages - arrows with one or more message name that show the direction and names of the messages sent between objectsEmphasis on static links as opposed to sequence in the sequence diagram 79
  80. 80. Collaboration Diagram 80
  81. 81. Example: A Booking System 81
  82. 82. Use Case Description: Change Flt Itinerary Actors: traveler, client account db, airline reservation system Preconditions: Traveler has logged in Basic course:  Traveler selects „change flight itinerary‟ option  System retrieves traveler‟s account and flight itinerary from client account database  System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment.  System asks traveler for new departure and destination information; traveler provides information.  If flights are available then …  …  System displays transaction summary. Alternative course:  If no flights are available then… 82
  83. 83. Sequence Diagram: Change Flight ItineraryTraveler : Booking System Client Account DBMS Airline Reservation System change flight itinerary get customer account get itinerary present itinerary select segment present detailed info update information available flight : : 83
  84. 84. Collaboration Diagram: Change Flt Itinerary 1: change flight itinerary 5: select segment 2: get customer account 3: get itinerary 7: update information : Booking System 4: present itineraryTraveler 6: present detailed info Client Account DBMS 8: available flight Airline Reservation System 84
  85. 85. Activity Diagrams Fancy flowchart  Displays the flow of activities involved in a single process  States • Describe what is being processed • Indicated by boxes with rounded corners  Swim lanes • Indicates which object is responsible for what activity  Branch • Transition that branch • Indicated by a diamond  Fork • Transition forking into parallel activities • Indicated by solid bars  Start and End 85
  86. 86. Sample Activity DiagramOrdering SystemMay need multiple diagrams from other points of view 86
  87. 87. Activity Diagram Example 87
  88. 88. State Transition DiagramsShows the possible states of the object and the transitions that cause a change in state  i.e. how incoming calls change the stateNotation  States are rounded rectangles  Transitions are arrows from one state to another. Events or conditions that trigger transitions are written beside the arrows.  Initial and Final States indicated by circles as in the Activity Diagram • Final state terminates the action; may have multiple final states 88
  89. 89. State RepresentationThe set of properties and values describing the object in a well defined instant are characterized by  Name  Activities (executed inside the state) • Do/ activity  Actions (executed at state entry or exit) • Entry/ action • Exit/ action  Actions executed due to an event • Event [Condition] / Action ^Send Event 89
  90. 90. Notation for States 90
  91. 91. Simple Transition Example 91
  92. 92. More Simple State Examples 92
  93. 93. State Transition ExampleValidating PIN/SSN 93
  94. 94. State Charts – Local VariablesState Diagrams can also store their own local variables, do processing on themLibrary example counting books checked out and returned Borrow / N = N+1 Is-Member Clean-Up Start / N=0 Stop / N=0 Return / N=N-1 94
  95. 95. Component DiagramsShows various components in a system and their dependencies, interfacesExplains the structure of a systemUsually a physical collection of classes  Similar to a Package Diagram in that both are used to group elements into logical structures  With Component Diagrams all of the model elements are private with a public interface whereas Package diagrams only display public items. 95
  96. 96. Component Diagram NotationComponents are shown as rectangles with two tabs at the upper leftDashed arrows indicate dependenciesCircle and solid line indicates an interface to the component 96
  97. 97. Component Example - InterfacesRestaurant ordering systemDefine interfaces first – comes from Class Diagrams 97
  98. 98. Component Example - ComponentsGraphical depiction of components 98
  99. 99. Component Example - LinkingLinking components with dependencies 99
  100. 100. Deployment DiagramsShows the physical architecture of the hardware and software of the deployed systemNodes  Typically contain components or packages  Usually some kind of computational unit; e.g. machine or device (physical or logical)Physical relationships among software and hardware in a delivered systems  Explains how a system interacts with the external environment 100
  101. 101. Some Deployment Examples 101
  102. 102. Deployment ExampleOften the Component Diagram is combined with the Deployment 102
  103. 103. Summary and Tools UML is a modeling language that can be used independent of development Adopted by OMG and notation of choice for visual modeling  http://www.omg.org/uml/ Creating and modifying UML diagrams can be labor and time intensive. Lots of tools exist to help  Tools help keep diagrams, code in sync  Repository for a complete software development project  Examples here created with TogetherSoft ControlCenter, Microsoft Visio, Tablet UML  Other tools: • Rational, Cetus, Embarcadero • See http://plg.uwaterloo.ca/~migod/uml.html for a list of tools, some free 103
  104. 104. SampleImplementation of UML 104
  105. 105. Hotel Reservation [USE CASE](1) Identify the actors.(2) Identify the responsibilities of each role.(3) Identify the use cases by considering what the system can offer. 105
  106. 106. Hotel Reservation [USE CASE](1) Identify the actors. – staff – customer – guest – management – front desk – laundry service – room service 106
  107. 107. Hotel Reservation [USE CASE](2) Identify the responsibilities of each role.Staff includes management, front desk, laundry service, room serviceEach actor is considered individually.Dividing the responsibilities based on the description gives the following breakdown: 107
  108. 108. Hotel Reservation [USE CASE]i) front desk accept reservation cancel reservation assign rooms check in guests check out guests receive payment 108
  109. 109. Hotel Reservation [USE CASE]ii) room service provide room service laundry service provide laundry serviceiii) customer make reservation cancel reservation 109
  110. 110. Hotel Reservation [USE CASE]iv) guest check in check outv) management need for increasing rooms based on non availability occupancy rate revenue from services reservation pattern based on holidays and conventions corporate customer reservations 110
  111. 111. Hotel Reservation [USE CASE](3) Identify the use cases by considering what the system can offer.A set of use cases can be derived by grouping the related actions together accept reservation  AcceptReservation cancel reservation  CancelReservation assign rooms  AssignRooms check in guests  CheckInGuests check out guests  CheckOutGuests receive payment  ReceivePayment provide room service  ProvideRoomService provide laundry service  ProvideLaundryService 111
  112. 112. Hotel Reservation [USE CASE]Consider any other possible situations. You can also consider different situations representing the use case.Example When a person walks into the hotel without any reservation and wants to stay Notice that the current use cases cannot handle this situation. We discover the need to separate two possible situations where a guest may use our hotel.i) Walk inii) Previous reservation madei) Walk in The walk in use case represents the situation when no previous reservations were made. The customer walks into the hotel and wants to stay A new class may be created to represent this use case. This use case comprises a combination of the following existing use cases: a) accept reservation b) assign rooms c) check in guests 112
  113. 113. Hotel Reservation [USE CASE] 113
  114. 114. Hotel Reservation [Analysis Class Diagram ](1) Identify the nouns and model the concepts as classes and adjectives as attributes.(2) Identify the possible attributes by looking at how to describe each concept.(3) Test the 3 relationships between the classes, has a or part of, uses or depends on, kind of or is a.(4) Consider the range, default and limitations of each attribute. 114
  115. 115. Hotel Reservation [Analysis Class Diagram ](1) Identify the nouns and model the concepts as classes and adjectives as attributes.(2) Identify the possible attributes by looking at how to describe each concept.Guidelines in abstracting the possible classes and attributesYou may also include the adjectives as adjectives represent descriptions.Adjectives become the attributes.When absolute values are mentioned, it represents an attribute. 115
  116. 116. Hotel Reservation [Analysis Class Diagram ]Example$250 for a twin roomDescriptions attached to the nouns indicate possible specializations.ExampleSingle room, Twin room, SuiteRoom can be thought of as the general class and the single and twin as specialized classes.If there are no additional attributes or operations in the specialized classes, it is possible to replace the specialized classes by an attribute.In this example the suite is described by a name. A set of specialized classes is used.To represent the type of roomThis indicates that an attribute has to be defined in a room class to hold the value. 116
  117. 117. Hotel Reservation [Analysis Class Diagram ]i) Abstracting the nouns from the description gives the following:hotel, branch, reservation, room, room no, customer, Customer’s nameContact address, Country, Sex, Type of accommodations, and number of rooms requiredNames of the people and the type of room they needPeriod of stay, Expected check in date, reservation identity, Block bookings, agencies, payment, Credit card, Credit card type, number and issuing companyTraveler’s checks, Check No., issuing company, Direct corporate billing corporate account number, Cash, room rate, $10 for breakfast, $10 for lunch, $10 for dinner, Reservation, Name of the guest’s expected, Type of payment, Shirt $5, Suits $12, Dress $8, Trousers $9, Others $6, suite, single, twin, Single $150, Twin $250, Suite $550 117
  118. 118. Hotel Reservation [Analysis Class Diagram ]ii) Organizing the nouns and adjectives gives the following: System Hotel represents the system.Possible classes The following gives the potential classes and the possible attributes from the list of nouns and adjectives. 118
  119. 119. Hotel Reservation [Analysis Class Diagram ]Reservation Reservation identity No. of single rooms required No. of twin rooms required No. of suite rooms required breakfast lunch dinnerMeal charge type of meal cost 119
  120. 120. Hotel Reservation [Analysis Class Diagram ]Guest nameSingle room room no. rateTwin room room no. rateSuite room no. rate suite nameCustomer name, contact address, country, sex,Cash payment amountCredit card payment amount, Credit card type, number and issuing companyTraveler’s check payment amount, Check No., issuing company 120
  121. 121. Hotel Reservation [Analysis Class Diagram ]Direct corporate billing payment amount, corporate account numberLaundry charge type of clothing cost per pieceLaundry use date of use No. of pieces type of clothingRoom service charge type of service cost 121
  122. 122. Hotel Reservation [Analysis Class Diagram ](3) Test the 3 relationships between the classes, has a or part of, uses or depends on, kind of or is a.Generalization specialization Traveler’s check, Direct corporate billing, cash and credit card are types of payment. The general class is abstracted.payment amount 122
  123. 123. Hotel Reservation [Analysis Class Diagram ]Aggregation laundry use is a set of objects. laundry usage has many laundry items. An aggregation can be used to represent laundry.Association The following shows the type: Customer makes reservation. rooms are assigned to the reservation. guests belonging to the reservation reservation requires meals Reservation has a payment attached. Payment comprises meals, room service, laundry service and room charge When rooms are assigned to the reservation, an assignment class representing the association is created. The reservation object is associated with room objects through the room assignment object. Each room object is related through one room assignment object to the reservation. This means one reservation may have one or more rooms. One customer can make one or more reservations. One reservation may have one or more guests. Each reservation can have the meal options. 123
  124. 124. Hotel Reservation [Analysis Class Diagram ](4) Consider the range, default and limitations of each attribute. laundry charge type of clothing: Shirt, Suits, Dress, Trousers, Others cost per piece: 5, 12, 8, 9, 6 single room room No.: 100 to 149, 200 to 249 rate 150 twin room room No., 150 to 199, 250 to 299 rate 250 suite room No., 300, 301, 302 rate 550 suite name Royal suite, Presidential suite, Honeymoon suite meal charge type of meal breakfast, lunch, dinner cost: $10 124
  125. 125. 125
  126. 126. [Statecharts](1) Consider the state changes induced by the use case. Now that we have a set of classes, we can consider how the objects representing each class is affected by the use cases. The following shows the possible state changes and the classes affected:accept reservation use case The reservation object is created and the state is unpaid and room Unassigned. It can also be a Block reservation if the reservation is made by the agency. Or a Not Block reservationassign rooms The reservation object goes from room Unassigned to rooms Not checked in state but is still in the unpaid state. The association object (Room Assignment) is created with the state assigned Not check in. To represent the relationship between the reservation and the roomcheck in guests The reservation object goes from rooms Not checked in state to Partial check Out when the first guest checks in. The Room Assignment object goes from the assigned Not check in to Assigned Check in. A change back to the same state is also allowed in this use case. The reservation object goes from Partial check Out state to Partial check Out when the other guests checks in. 126 If the last guest comes in then it becomes All Guest Check in.
  127. 127. [Statecharts]cancel reservation The reservation object goes from Rooms Not checked in if rooms are assigned or Room Unassigned to Cancelled if the whole reservation is cancelled. A change back to the same state is also allowed in this use case. This represents the situation where only some guests are cancelled. The reservation object goes from Rooms Not checked in to Rooms Not checked in.check out guests The reservation object goes from Unpaid to paid if the type of payment is cash, check or credit card. The payment takes place in the check out. If the type of payment is corporate, a different payment use case takes place after the checkout representing the payment received from the corporate. The reservation also goes from the Partial check in or all guest checked in to the partial checked out if the there are still guests remaining in the hotel for the reservation. A change back to the same state is also allowed in this use case. The reservation also goes from partial checked out to partial checked out when the guests checked out. When the last guest checked out, the reservation goes to the All guest checked out. The Room Assignment object goes from the assigned Not check in to Assigned Checkout.receive payment This is done either the checkout or a different use case depending upon the Type of payment. If the type of payment is corporate the payment is a separate use case as the Hotel have to wait for notification of payment from the company. For the other payment types, direct payment is made when the guests checked outprovide room service The room service usage object is created.provide laundry service 127 The laundry service usage object is created.
  128. 128. 128
  129. 129. 129
  130. 130. Activity DiagramThe activity diagram shows the actual steps performed in the use case. It looks like a flowchart with the decisions represented by a diamond and the tasks represented by a box.(1) Make ReservationThe following shows the related tasks and decisions made when a reservation is made.- A customer specifies the type of accommodation, number required, period of stay, and expected check in date.- The person at the front desk checks the availability, and if available, the following additional information is requested:Name and Contact telephone of the person making the reservationName of the guest’s expectedType of room for them- The person at the front desk also asks if any combination of the meals is required, i.e. breakfast, lunch or dinner.- The person at the front desk then informs the customer of the reservation identity. 130
  131. 131. 131
  132. 132. 132
  133. 133. 133
  134. 134. 134
  135. 135. 135
  136. 136. 136
  137. 137. 137
  138. 138. 138
  139. 139. 139
  140. 140. 140
  141. 141. 141
  142. 142. Continuation…. 142
  143. 143. 143
  144. 144. 144
  145. 145. 145
  146. 146. 146
  147. 147. 147
  148. 148. 148
  149. 149. 149
  150. 150. 150
  151. 151. Useful Websiteshttp://erwinglobio.wix.com/ittraininghttp://ittrainingsolutions.webs.com/http://erwinglobio.sulit.com.ph/http://erwinglobio.multiply.com/ 151