1 / 45

F28SD Software Design

F28SD Software Design . MF Lecture 2 Introduction to UML Use Cases Activity Diagrams. Monica Farrow G.30/4160 monica@macs.hw.ac.uk Material on Vision. What is (the) UML?. Unified Modeling Language

fai
Télécharger la présentation

F28SD Software Design

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. F28SD Software Design MF Lecture 2 Introduction to UML Use Cases Activity Diagrams Monica FarrowG.30/4160 monica@macs.hw.ac.uk Material on Vision UML Intro, Use Cases

  2. What is (the) UML? • Unified Modeling Language • A language for specifying, visualising and constructing the descriptive diagrams and documentation of software system • A family of mainly graphical notations • “a picture is worth 1000 words” • Helps in designing and describing software systems, particularly object-oriented systems • Industry standard for object-oriented modelling UML Intro, Use Cases

  3. Object-oriented Design questions • We’re aiming for a well-designed, robust and maintainable object-oriented system which meets the users’ requirements • What does the user require? • Which classes should there be? • What responsibilities should each class have? • How should objects interact? UML Intro, Use Cases

  4. Where did UML come from ? • From the late 1980’s to the early 1990s, many languages were developed for modelling object-oriented design graphically • In 1997 Booch, Rumbaugh,Jacobson (called ‘3 Amigos’) combined the best ideas into UML • It’s an open standard controlled by the Object Management Group, a consortium of companies • www.omg.org • UML2 is the later version, so you may see small differences in older books or websites UML Intro, Use Cases

  5. How it can be used • Sketch - recommended • Informal • Selective – ONLY use it if the problem is complex and therefore the diagram helps • Blueprint • Complete • Usually too time-consuming, especially if design changes • Programming language • Diagrams transformed to executable code • Not widespread UML Intro, Use Cases

  6. What is it not? • The UML provides notation, but it does not define a particular development process UML Intro, Use Cases

  7. Books & Websites • There are many good books on UML, such as • Teach Yourself UML in 24 hours by Joseph Schmuller • UML Distilled Third Edition • by Martin Fowler : Addison Wesley ISBN 0-321-19368-7 • Chatty, compact, with advice from experience • There are also a lot of websites with suitable material such as : • http://bdn.borland.com/article/0,1410,31863,00.html • http://www.agilemodeling.com/essays/umlDiagrams.htm UML Intro, Use Cases

  8. Tools for UML – there are many • Optional • Advantages • Less likely to create incorrect diagrams • May generate skeleton code • Disadvantage • Learning time • ArgoUML is available in the Riccarton campus. It can be freely downloaded for your own computer. There are many other good tools. • There is a basic introduction to ArgoUML on Vision • http://argouml.tigris.org/ UML Intro, Use Cases

  9. Topics covered in this module • Use cases • How people interact with the system • Activity diagrams • Shows workflow, how software and human activities interact • Class diagrams • Used both from the conceptual and the software perspective (i.e. design and documentation) • Sequence and collaboration diagrams • Interaction between the classes for common scenarios • State machine diagram • Shows changes in the state of an object • Package and deployment diagrams • Class organisation and location UML Intro, Use Cases

  10. Use Cases How people interact with the system UML Intro, Use Cases

  11. Use cases • Use-cases are a scenario based technique in the UML which describe the interaction between an actor and the high level functions within the system. • Diagram and textual description • Typically between 2 – 10 use cases per system • Keep high-level, don’t divide into lots of sub use cases • Library Use Case: Borrow book • VCR Use Case: Set Timer • IT Help Desk Use Case: Log issue • A set of use cases should describe all possible interactions with the system. • An actor can be a person, another information system, or a hardware device : anything that triggers or is involved in the system UML Intro, Use Cases

  12. Use Case • A description of the processes in the system, from the users’ perspective. • They describe the interaction between a user and the high level functions within the system. • A user can be a person, another information system, or a hardware device : anything that triggers or is involved in the system • E.g. • Library Use Case: Borrow book • VCR Use Case: Set Timer • IT Help Desk Use Case: Log issue UML Intro, Use Cases

  13. Use Case • Use Cases consist of: • A textual description (always) • A diagram (when useful) • All the other components of UML consist of diagrams only • The next 2 slides show an example UML Intro, Use Cases

  14. join reserve book borrower borrow book return book add stock librarian remove stock Use Case Diagram for Library Here’s an example of a use case diagram showing all the use cases for a library UML Intro, Use Cases

  15. The textual description for the ‘Borrow’ Use case USE CASE: Borrow GOAL: To borrow a library book ACTORS: Borrower, System • Main success scenario • Provide card with membership bar code • Provide book with bar code • System checks membership • System records loan to borrower for 3 weeks • Borrower leaves with the book • Alternatives 3a Borrower already has borrowed maximum number of books • The loan cannot happen UML Intro, Use Cases

  16. High-level use cases • A set of use cases should describe all possible interactions with the system. • Typically you will have between 2 and 10 use cases • Keep them at the top level • What initiates an interaction in the system? • An interaction should be described by one use case, not by a sequence of them • E.g. ‘borrow’ should not be shown as ‘find book’, ‘take to desk’, ‘show card’, ‘check out’ • This sequence should be described in the text of the description, not in the diagram UML Intro, Use Cases

  17. Diagrams and textual description • You should always make a list of use cases and for each one, write a textual description. • There’s not a lot of point drawing a use case diagram with 1 actor and 2 or 3 use cases – a simple list of the use cases would do • Use the diagram whenever the situation is more complex UML Intro, Use Cases

  18. Use Case Diagram - notation SYSTEM BOUNDARY ACTOR LINK borrower borrow book USE CASE UML Intro, Use Cases

  19. Actors • An actor indicates a role played by an external person or system which is involved in a use case • The same person or system may play the role of more than one actor, depending on the context • E.g. maybe a librarian is also a borrower • An actor may be involved in more than one use case • Actors initiate and/or respond to use cases e.g. • Sales rep logs call • Driver starts car • Alarm system alerts duty officer • Timer triggers email UML Intro, Use Cases

  20. Scenarios • A Scenario is a sequence of steps describing an interaction between a user and a system. • Each use case is likely to have several scenarios • The ideal or ‘happy’ scenario is when the process works as normal This is the primary business flow : it does not cater for any errors in the system or any user entry errors. E.g. money is withdrawn from ATM book is borrowed from library • ‘Unhappy’ scenarios, or ‘extensions’ are when things don’t go so well e.g. wrong pin number entered member has maximum number of books out already UML Intro, Use Cases

  21. Notes On The Description • The borrower is the actor that initiates the loan • The inputs to the use case are identified • The book code, the membership code • The outcomes are identified • The borrower leaves with the book, the loan is recorded in the system • The exceptions are identified and the alternative outcomes are given. • The borrower already has 6 books out : loan refused • This use case is adequate for the users to agree that it is accurate, without becoming a design. • The cheapest place to sort out errors in the requirements is at this stage UML Intro, Use Cases

  22. Use Cases : include (used to be ‘uses’) • Some use cases may share one or more common steps Reserve book <<includes>> Check membership borrower <<includes>> Borrow book UML Intro, Use Cases

  23. Use cases : extension • An extension is a significant exception to the normal case Borrowing refused <<extends>> borrower borrow book UML Intro, Use Cases

  24. borrow book Borrower : books only borrower borrow CD Borrower : books and CDs Use Cases: generalisation • Actors and use cases can be generalised, showing that one is simply a special case of the other • This is like inheritance in object-oriented design • Suppose that to borrow a CD, users must have additional registration and pay per CD. UML Intro, Use Cases

  25. Finally • Don’t get too involved with the diagrams. Remember that the textual description is more important. • You will see slight variations in the use of use cases, due to different use and versions of UML • There is no one right answer to any question associated with design. UML Intro, Use Cases

  26. F28SD Software Design MF Lecture 3 Activity diagrams Monica FarrowG.30/4160 monica@macs.hw.ac.uk Material on Vision UML Intro, Use Cases

  27. Activity Diagrams overview • Activity diagrams model flow of control in a system • States have transitions to other states • States may be either • action states: atomic action • activity states: actions that can be broken down • They may have decisions, explained by conditions, and merges • They may have forks and joins for modelling simultaneous activities (not covered here) UML Intro, Use Cases

  28. The basic notation Process loan Action / Activity • Long rounded rectangle Start / Initial State • unique with only one transition line End State • not necessarily unique Transition • Lines indicate sequential flow of actions. Must be labelled after a decision. • Arrows indicate direction of next action Activity is shown in more detail in another diagram UML Intro, Use Cases

  29. [sunny] [rainy] socks sandals shoes Decision Points and Guards • Decision point : diamond • Single entry transition line • Multiple exit transition lines • each with Guard (condition) • Exit lines must cover all eventualities • There could be a problem with the decisions in this diagram. What do you think it is? UML Intro, Use Cases

  30. Merge Points • Merge : diamond • Are used to indicate a merge after a decision • Multiple entry, single exit • In UML1, more than one transition line can enter an activity. • In UML2 (and in this module!), use merge diamonds. [sunny] [rainy] socks sandals shoes sandals shoes go out go out UML1 UML Intro, Use Cases

  31. The activity diagram's purpose • Activity diagrams are used to • Communicate effectively • Clarity and simplicity • Model the procedural flow of actions that are part of a larger activity • Model a specific use case at a more detailed level • Model business-level function or flow of program code UML Intro, Use Cases

  32. A mathematical formula, showing process flow n! = n * (n-1) * (n-2) * … * 1 Notes In the format n! = result result = 1 counter = 1 [n== 0, n== 1] [n>1] print ( result ,n ) result = counter * result counter += 1 [counter > n] [counter <=n] UML Intro, Use Cases

  33. The activity diagram's focus • Focuses on the action sequence of execution and the conditions that trigger or guard those actions. • Focused on the activity's internal actions and not on external actions • Activity diagrams show all potential sequence flows in an activity, whereas a sequence diagram (covered in a later lecture)typically shows only one flow of an activity UML Intro, Use Cases

  34. Take-away meal • Draw an activity diagram for this situation: When I order a take-away meal, I phone the Chinese restaurant, give him my phone number, and his computer will automatically display my address if I’ve ordered before. But if I’m a new customer calling for the first time, he must get my address before he takes my order. UML Intro, Use Cases

  35. Take-away meal diagram UML Intro, Use Cases

  36. Synchronisation • When modelling activities, you sometimes need to show that certain action sequences can be done in parallel (synchronously, concurrently, simultaneously). • Fork • Shows start of concurrent actions • The thread within each exit can be executed at the same time as the other thread • Single entry, multiple exits • Join • Shows end of concurrent actions • The exit cannot occur until all entry threads have been completed • Multiple entry, single exit UML Intro, Use Cases

  37. Shopping in Argos (assuming payment ok) Fill in form Process order • The fork shows that the collection slip can be printed at the same time as the items are being picked out and sent for collection. • The join shows that you can’t collect them until the slip has been printed and also the items have been picked out and sent for collection [order cancelled] [order ok] process payment Items picked Collection slip printed Sent for collection Collect items UML Intro, Use Cases

  38. Synchronization and decisions • Beginners often get confused here. • Use a fork/join if the actions can be done • at the same time • if the order does not matter • but both must be done before continuing • In the Argos example, the items may not be picked until after the slip has been printed. The fork shows that these actions CAN be done at the same time – but they don’t have to be. The join shows that they must both be done before continuing. • Do NOT use a join after a decision – use a merge. UML Intro, Use Cases

  39. Swimlanes / partitions • Useful to model activity's procedural flow of control between objects • Use vertical columns • Assign column object’s name • placed at the top of the column • Place each action associated with an object in that object's swimlane UML Intro, Use Cases

  40. Swimlanes / partitions • Useful to model activity's procedural flow of control between objects • Use vertical columns • Assign column object’s name • placed at the top of the column • Place each action associated with an object in that object's swimlane UML Intro, Use Cases

  41. Swimlanes/ partitions example : argos Member Till staff Warehouse staff Fill in form Process order [Order cancelled] [order ok] Process payment Items picked Collection slip printed Sent for collection Collect items UML Intro, Use Cases

  42. Expanding one action : process order Process order Item entered into computer [not in stock] Remove item [in stock] [all items processsed] [more items] UML Intro, Use Cases

  43. Activity diagrams, statechart diagrams & UML2 • In UML1 they were considered to be a special case of statechart diagrams (covered later in the course) • Not really appropriate • UML2 • Not a special case of statechart diagrams • Always use merge or join explicitly • Further features • They can be used to show more details such as timing and parameters (not covered in this module) UML Intro, Use Cases

  44. Send reservation Wait 48 hours Reservation confirmed Signals (optional) Whichever flow finishes first, terminates the other flow Accept signal Plan holiday Book holiday Cancel holiday Send signal Time signal UML Intro, Use Cases

  45. Thu workshop • You may understand but can you write your own? • Come on Thursday ready to try writing your own use cases and activity diagrams • No marks for this but essential practice for the assignment • You could read through the lecture notes beforehand • Sit in small groups (4?), bring paper and pencil UML Intro, Use Cases

More Related