Presentation on theme: "Karolina Muszyńska Based on:"— Presentation transcript:
1 Object-oriented modeling Modeling the functions and dynamics of the system Use case diagram Karolina MuszyńskaBased on:G. Schneider , J.P. Winters „Stosowanie przypadków użycia”S. Wrycza, B. Marcinkowski, K. Wyrzykowski „Język UML 2.0 w modelowaniu SI”
2 Object Modeling Why Object Modeling? Genesis of UML UML diagrams Use Case DiagramsFrom business tasks to Use CasesNo additional notes
3 Object ModelingObject modeling is a technique for identifying objects within the systems environment and the relationships between those objects.Object-oriented analysis (OOA) techniques are used to (1) study existing objects to see if they can be reused or adapted for new uses, and (2) define new or modified objects that will be combined with existing objects into a useful business computing application.The Unified Modeling Language (UML) is a set of modeling conventions (notations) to specify or describe a software system in terms of objects.No additional notes
4 Object Modeling Benefits: Break a complex system into manageable componentsCreate reusable components can be plugged into other systems or use them as starting points for other projects“Object-think” is more realistic !!!No additional notes
5 Genesis of UMLMethodological storm in object-oriented solutions ( )over 50 various object-oriented methods/solutionsUnified Modeling Language (UML)Third generation OO methodAn attempt to combine advantages of previous methodsBasis for the UML standardObject Modeling Technique (J. Rumbaugh) – UML diagrams notation, analysis and designObject Oriented Analysis and Design (G. Booch) – analysis and designObject Oriented Software Engineering (I. Jacobson) – business modeling, use casesNo additional notes
7 UML DiagramsStructure diagrams. A type of diagram that depicts the elements of a specification that are irrespective of time. This includes class, object, package, composite structure diagrams and implementation diagrams: component and deployment diagrams.Behavior diagrams. A type of diagram that depicts behavioral features of a system or business process. This includes activity, state machine, and use case diagrams as well as the four interaction diagrams.Interaction diagrams. A subset of behavior diagrams which emphasize object interactions. This includes sequence, communication, interaction overview, and timing diagrams.No additional notes
8 Most common UML Diagrams Modeling the functions of the system (with a use case diagram).Modeling the objects within the scope of the system and their relationships (with class and object diagrams for each use case, and then for the integrated system).Modeling the interactions between objects to complete a function/use case (with a sequence diagram and activity diagram for each use case).Modeling the behavior / logic of the objects (with a statechart diagram for each complex class).
9 UML Diagrams STATECHART DIAGRAM FOR OBJECT “Order” USE CASE DIAGRAM Enter New CustomerCreate New Order:customer:orderCreate OrderSHIP ORDERCREATE ORDERORDERCUSTOMERSHIPMENTUSE CASE DIAGRAMCLASS DIAGRAM FOR USE CASE “Create New Order”SEQUENCE DIAGRAM FOR USE CASE “Create New Order”Order Clerk:shipmentCreate Shipment
10 Use Case ModelingUse case modeling is the process of modeling a system’s functions in terms of business events, who initiated the events, and how the system responds to the events.A use case is a complete sequence of related actions (a scenario), both automated and manual, for the purpose of completing a business function: What the system must do.An actor represents an external entity that needs to interact with the system to exchange information. An actor is a user, a role, which could be an external system as well as a person.A temporal event is a system event that is triggered by time. (The actor of a temporal event use case is time.)
11 USE CASE DIAGRAMUse Case Diagram is a functional description (use cases, actors) of the entire system: functions being supported by the systemUse Case Diagram does NOT indicate data flows or flows of information in and out the system (they are identified later in interaction diagrams)
12 Extension and Abstract Use Cases An extension use case extends the functionality of an original use case to add new behaviors or actions to the basic course. An extension use case can only be invoked by the use case it is extending.An abstract use case contains typical course steps that were common to two or more original use cases. An abstract use case reduces redundancy and promotes reuse.
13 Extension Use Cases (“extend” relationship) Class registrationRegistration for special classesInsufficient prerequisites“Class registration” is the basic course of actions. On special occasions, “Registration for special classes” and/or “Insufficient prerequisites” will be invoked. Special cases add new data/behaviors to the normal case.
14 Abstract Use Cases (“include” relationship) Track sales & inventoryReorder suppliesGenerate reports“Track sales & inventory” includes “Reorder Supplies” and “Generate reports”
15 Inheritance among Actors or Use Cases Place orderPlace order by telephonePlace order via webpageClientSales RepresentativePrepare sales report“Place order by telephone” or “Place order via webpage” are possible types of “Place order” “Sales Representative” plays all roles of “Client”
16 CRUD Use Cases vs. Individual Use Cases Place orderClientSalesmanCheck order statusCancel orderDataBase AdministratorAdminister warehouse stateCRUD (Create, Read, Update, Delete) type use cases are used when application is meant to store data and one actor interacts with it (e.g. database maintenance, order management, etc.).
17 Use Case Documentation Each use case should include documentation in the form of scenariosScenario is a sequence of actions documenting a behaviorEach use case should have at least the main scenario but it is preferable to include the alternative scenarios as wellBoth main and alternative scenarios precisely describe the full functionality represented by a use caseAdditional important elements of the use case documentation include: pre-conditions and post- conditions
18 Building a Use Case Diagram Identify actors (look at the sources and destinations of major inputs and outputs)Identify use cases (major system functions)Identify the system boundaryIdentify associations between actors and use casesIdentify additional associations between use cases (“extend”, “include”)Identify inheritance relationships among use cases and actors
22 „Make repair reservation” use case specification Service personnel selects 'Make repair reservation‘System displays 'repair reservation' formService personnel selects client searchSystem displays list of clientsService personnel chooses a clientSystem inserts the client's data into the 'repair reservation' formService personnel selects repairs searchInclude: Display repair typesService personnel selects the repair typeSystem inserts the repair's data together with the cost to the 'repair reservation' formService personnel selects 'make repair reservation‘System displays confirmationNo additional notes
23 „Make repair reservation” use case extension point before point 5. extend: Add client„Add client” use case specificationSystem displays 'add client' formService personnel inserts client's data (name, address, phone number, address)Service personnel selects 'add client‘System displays confirmationNo additional notes
24 Rent-a-Car case study Possible business tasks: Rent a car Take back the rented carPrepare cars for rentalMake a reservation for a carBuy a carSell a car…No additional notes
25 „Rent a car” business task Business steps:Identifying the type of car and rental time frame the client is interested inIdentifying the clientPreparing the rental contractSigning the contract and informing garage about new rentalNo additional notes