1 / 119

Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005

Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005. UML Overview. UML. This is how the UML developers see their brain child :

zarola
Télécharger la présentation

Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005

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. Object georiënteerd Ontwerpen met UMLSaxion Hogeschool Enschede, januari 2005

  2. UML Overview UML Overview

  3. UML • This is how the UML developers see their brain child: • "The Unified Modeling Language (UML) provides system architects working on object analysis and design with one consistent language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling."

  4. UML : What It Is …. • A language for modeling systems : • Mechanical systems, electronic systems • Software systems • A combination • But also business processes • A language that helps to cope with complexity of systems : • Abstracts from uninteresting details • Provides different, but related views • Reveals large scale structure (architecture) • A language that helps to develop software systems : • Modeling the problem domain • Specifying desired system behavior • Describe implementation

  5. UML … What It Isn’t • A description of a software development process ((R)UP is the “corresponding” process) • A programming language • (models are not always executable)

  6. UML History • The number of OO methods increased from 10 in 1989 …… … to more than 50 in 1994 • The most notable (say popular) methods were : • Booch's OOD • Jacobson's OOSE • Rumbaugh's OMT • Fusion • Shlaer-Mellor • Coad and Yourdon • No modeling language filled all needs completely

  7. UML History • Babylonian confusion: • Everybody invents and speaks his own modeling language • Everybody has a different understanding of modeling concepts • Tools all use a different language or dialect • Interchange of models is not possible • One popular language (and process) emerged: OMT (2) • Grady Booch observed the need for an object esperanto! • A comedy acted out in real life: the three amigos • Around 1994Booch convinced the other two famous methodologists to join him at rational : Jacobson, Rumbaugh

  8. UML 2.0 UML 1.0 public feedback UML 0.9 Web - June ´96 Unified Method 0.8 OOPSLA ´95 OOSE Other Methods History UML 2005? UML 1.5 2003 UML approved by the OMG Nov ‘97 Booch method OMT

  9. OMG • OMG stands for object management group, inc. (1989) • International industrial consortium with over 800 members • The OMG promotes object-oriented technology • E.G. CORBA and UML • The OMG wants to provide a framework for software development • Stimulate growth of object technology • Increase interoperability of software of different vendors • Reducing confusion by setting standards

  10. HP Fusion Meyer Booch Operation descriptions en message numbering Before and after conditions Booch methode Rumbaugh Embley Harel OMT Singleton classes en high-level view Statecharts Gamma, et al Wirfs-Brock Frameworks en patterns, Responsibilities Odell Shlaer - Mellor Jacobson Classification Object lifecycles OOSE Contributions to UML

  11. UML and other OMG technologies

  12. UML Diagrams • The UML is constructed specifically to enable modeling of objects, their structure, behavior and interaction. • With the UML it is possible to : • Display the boundary of a system & its major modes of use as observed by external actors using Use Case Diagrams. • Illustrate how particular use cases are realized through the interactions between objects in Interaction Diagrams: • Sequence Diagrams; • Communication Diagrams. • Model the structure of objects with Class Diagrams. • Model individual object behavior with State machine Diagrams. • Describe the physical implementation architecture with Component & Deployment Diagrams.

  13. UML Diagrams

  14. Views • Use Case View : • Use Cases capture a mode of use of the system as observed by an external actor. The Use Case view is a visual representation of such modes of use. • Static View : • captures static relationships between conceptual entities in a domain, abstracting from their physical representation or implementation. • Design View : • models the structure of the application itself (structured classifiers, collaborations, components and interfaces). • State Machine View : • Models the possible life histories of an object of a class.

  15. Views • Activity View : • Shows the flow of control among the computational activities involved in performing a calculation or a workflow. • Interaction View : • Describes sequences of message exchanges among the parts of a system. • Model Management View : • Models the organization of the model itself. A model comprises a set of packages that hold model elements (classes, state machines, use cases) or other packages. • Deployment View : • A description of the allocation of components to execution resources.

  16. Views

  17. Views

  18. Use-Case View • Use-Case Diagrams model modes of use of a system : • Use Cases • Actors

  19. Lift system Static View • Class Diagrams model structure of objects and their relationships • Classes • Objects • Packages

  20. Interaction View • Interaction diagrams • Model interactions between objects • Objects • Messages

  21. State machineView Door • State machine Diagrams model behavior of individual objects • States • Transitions • Events (messages)

  22. Building.java background.gif Component View • Component Diagrams • Typical components: • Executables • DLL’s • Packages • Database tables • Show the component dependencies appletviewer.exe Building.html Lift Building.class JavaDevices Devices java.awt

  23. Deployment View • Deployment Diagrams show the physical distribution of components over processors Location of components on nodes

  24. Use Cases The Essentials Use Case s Essentials

  25. Requirements • Requirements specification : • High-level description of what should be implemented • Importance of requirements : • 25% of the projects fail due to problems with requirements • Find out about requirements : • Interview stakeholders to find out what they need system to do • A requirement may be a description of : • What behaviour the system should offer • A specific property of the system • A constraint on the system

  26. Functional and Non-functional Requirements • Functional Requirements : • What the system should do • “The ATM system shall provide a facility for authenticating the identity of a system user” • Non-functional Requirements : • A constraint on how the functional requirements are implemented • “The ATM system shall authenticate a customer in four seconds or less”

  27. The glossary • There is always a certain jargon in a business domain • Project glossary captures the language of the domain • The aim of the glossary is : • Define key terms • Resolve synonyms and homonyms • Project Glossary • Term1 Definition • Term2 Definition • Term3 Definition • …

  28. The system boundary • Before we can build anything, we need to know : • Where the boundary of the system lies • Who or what uses the system • What functions the system should offer • System boundary is identified in UML by a Use Case model • The Use Case model contains : • Actors – who or what uses the system • Use Cases – things actors do with the system • Relationships - between actors and use cases

  29. Use Case Diagram

  30. Characteristics Use Case Modeling • Use Case Modeling is OO-independent • There is no UML standard way of writing requirements!

  31. Actors • An actor is anything that interacts directly with the system • Actors identify who or what uses the system • Actors indicate where the system boundary lies • Actors are external to the system • An Actor specifies a role that some external entity adopts when interfacing with the system

  32. Identifying Actors • When identifying actors ask : • Who or what uses the system? • What roles do they play in the interaction? • What other systems use this system? • Who gets and provides information to the system? • Is there a dedicated time at which the system has to do something? • Actor symbol : Visitor

  33. Use Cases • A use case is something an actor wants to do with the system. • It is a “case of use” of the system by a specific actor • Use cases are always started by an actor • Use cases are always written from the point of view of an actor • Use Case symbol : Place order

  34. Steps in Use Case Modeling • Find actors and use cases • Detail a use case : • Specify the flow of events or scenario’s • Specify pre- and postconditions • Structure the use case model : • Find relationships between use cases • include • extend • generalization

  35. Use case specification Uses case name System state before the use case can begin • Deposit VAT • Preconditions : • 1. It is the end of a business quarter • Flow of events : • 1. The use case starts when it is the end of the business quarter. • 2. The system determines the amount of VAT owed to the government. • 3. The system sends an electronic payment to the government. • Postconditions : • 1. The government receives the correct amount of VAT Actual steps of the use case System state when the use case is over

  36. Pre and postconditions • Preconditions and postconditions are constraints • Preconditions : • Constrain the state of the system before the use case can start • Postconditions : • Constrain the state of the system after the use case has executed • Place Order • Preconditions: • 1. A valid user has logged on to the system • Postconditions: • 1. The order has been marked • confirmed and is saved by the system

  37. When to use use cases ? • Use cases describe system behaviour from the point of view of one or more actors. • Use cases are the best choice when : • System is dominated by functional requirements • System has many types of users to which it delivers different functionality • Use cases are designed to capture functional requirements • Uses cases are a poor choice when : • The system is dominated by non-functional requirements • The system has few users • The system has few interfaces • Develop test plan using use cases

  38. Questions

  39. Use Cases Advanced concepts Use Cases Advanced Concepts

  40. Use case specification Uses case name System state before the use case can begin • Deposit VAT • Preconditions : • 1. It is the end of a business quarter • Flow of events : • 1. The use case starts when it is the end of the business quarter. • 2. The system determines the amount of VAT owed to the government. • 3. The system sends an electronic payment to the government. • Postconditions : • 1. The government receives the correct amount of VAT Actual steps of the use case System state when the use case is over

  41. Pre and postconditions • Preconditions and postconditions are constraints • Preconditions : • Constrain the state of the system before the use case can start • Postconditions : • Constrain the state of the system after the use case has executed Place Order Preconditions: 1. A valid user has logged on to the system Postconditions: 1. The order has been marked confirmed and is saved by the system

  42. Flow of events • The flow of events lists the steps in a use case • It always begins by an actor doing something • A good way to start a flow of events is : • “1) The use case starts when an <actor> <function>” • Flow of events should be a sequence of short steps which are: • Declarative, numbered, time ordered • Alternatives can be shown by branching or by listing under “Alternative paths” • A good format for steps is : • <number> The <something> <some action>

  43. Branching within a flow: If • Use the keyword if to indicate alternatives within the flow of events • Use indentation and numbering to indicate the conditional part of the flow • View Basket • Flow of Events: • 1. The use case starts when the customer selects “view basket”. • 2. The customer selects an item. • 3. The customer may delete an item from the basket, change the quantity of an item, exit “view basket” or proceed to checkout. • 4. If the user selects “delete item” • 4.1. The item is removed from the basket • 5. If the customer types in a new quantity • 5.1. The quantity of the item is updated • 6. If the customer selects…

  44. Branching: Alternative paths • Alternative Paths are for things that can happen at any time • Section in use case specification for each alternative path with : • The flow of events for the alternative path • postconditions for the alternative path (optional) Flow of Events: Basic Path 1. The use case starts when the customer selects “go to checkout”. 2. The system displays the customer order. 3. … Alternative Path 1 1. At any time the customer can select “cancel order” and the order is deleted from the system. Alternative Path 2 1. At any time, the customer can go back to shopping. Checkout

  45. Repetition within a flow: For • Use the keyword “For” to indicate the start of a repetition within the flow of events • Expression immediately after “For” indicates the number of repetitions of the indented text beneath the “For” statement Find a Product Flow of Events: 1. The use case starts when the customer selects “find product”. 2. The customer enters a keyword and selects “find”. 3. For each product found 3.1. The system displays a thumbnail sketch of the product and the customer selects one of the products. 4. The system displays full product details and a larger picture. 5. … Find a Product Flow of Events: 1. The use case starts when the customer selects “find product”. 2. The customer enters a keyword and selects “find”. 3. For each product found 3.1. The system displays a thumbnail sketch of the product and the customer selects one of the products. 4. The system displays full product details and a larger picture. 5. …

  46. Repetition within flow: While • Use the keyword “While” to indicate that something repeats • while some Boolean condition is true Show Company Details Flow of Events: 1. The use case starts when the customer selects “show company details”. 2. While the customer is browsing the company details 2.1. The system plays some background music. 2.2. The system displays special offers in a banner at the top of the page. 3. …

  47. Complex use cases • Techniques up to now are fine for modeling average use cases • However, when use cases are complex, and there are many branches within the flow of events, there is a better approach • Scenarios

  48. Scenarios • One specific path through a use case with no branching • Each use case has one primary scenario : • This is the “happy day” or “perfect world” path through the flow • Everything goes as expected and desired • No errors, interrupts or branches • Each use case has many secondary scenarios : • Alternate paths through the flow • Errors (exception scenarios) • Interrupts to the main flow

  49. Primary scenario • Use the Primary Scenario as the use case flow of events • List the Secondary Scenarios under a new section • Provide a separate document for each secondary scenario Checkout Flow of Events: Primary Scenario 1. The use case starts when the customer selects “go to checkout”. 2. The system displays the customer order. 3. The customer enters a valid customer number. 4. The system retrieves and displays customer information. … Secondary Scenarios Invalid Customer Number. Invalid Credit Card Details. Credit Card Expired.

  50. Secondary scenarios • One specific path through flow of events with no branching • Always state how the scenario begins Checkout Secondary Scenario: Invalid Customer Number Flow of Events : 1. The scenario begins in step 3 of the use case “Checkout” when the customer enters an invalid customer number. 2. For three invalid entries 2.1. Prompt the customer to enter their customer number again 3. The system asks the customer to enter new customer details 4. The customer enters new customer details. 5. The system generates a new customer number 6. …

More Related