Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]

4,949 views

Published on

This presentation is about a lecture I gave within the "Software Modeling" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam.

http://www.ivanomalavolta.com

Published in: Technology
  • Discover How Thousands of Men and Women Worldwide Have Already Used The Reverse Diabetes Today™ System To Lower Blood Sugar To Normal And Safely Reverse Their Type 2 Diabetes Without Drugs or Insulin. ♣♣♣ https://bit.ly/2swQ6OO
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 1 cup burns 1lb of diabetic fat every 72 hours... ●●● https://bit.ly/2mBJACQ
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • This Deadly Molecule Causes Diabetes (not belly fat)... ★★★ https://tinyurl.com/y2956vb5
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 1 cup burns 1lb of diabetic fat every 72 hours... ■■■ https://bit.ly/2n5cFHd
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]

  1. 1. Software and Services research group (S2) Department of Computer Science, Faculty of Sciences Vrije Universiteit Amsterdam VRIJE UNIVERSITEIT AMSTERDAM Requirements engineering with UML Software modeling (401016) – 2016/2017 Ivano Malavolta i.malavolta@vu.nl
  2. 2. VRIJE UNIVERSITEIT AMSTERDAM Announcement The template for Deliverable 1 will be available today on BlackBoard! 2
  3. 3. VRIJE UNIVERSITEIT AMSTERDAM Roadmap • Introduction to UML • What is UML? • Main characteristics of UML • UML diagrams • Requirement engineering • Use case diagrams 3
  4. 4. VRIJE UNIVERSITEIT AMSTERDAM What is UML? • In the 80s there were multiple OO approaches • each approach had its own notation • then Rational Inc. (now IBM) 4 Booch notation Jacobson‘s OOSE Rumbaugh's Technique
  5. 5. VRIJE UNIVERSITEIT AMSTERDAM What is UML? • UML = Unified Modeling Language • De facto standard software design language • Developed by OMG • A “Swiss Army Knife” of notations 5
  6. 6. VRIJE UNIVERSITEIT AMSTERDAM Why UML in this course? The most used language for modeling software 6 34 job postings requiring UML in Amsterdam (as of last week)
  7. 7. VRIJE UNIVERSITEIT AMSTERDAM Who uses UML? 7
  8. 8. VRIJE UNIVERSITEIT AMSTERDAM Main characteristics of UML • It is not tied to any development process • à waterfall, agile, whatever… • Can be used across the whole life cycle • promotes iterative refinement of models • General purpose • it can be used for modeling a mobile app, but also a satellite • It has different representations: • graphical • textual • others… 8
  9. 9. VRIJE UNIVERSITEIT AMSTERDAM Main characteristics of UML • It is comprehensive • all parts of a system can be described using UML • It is scalable • you can zoom in with additional details when needed • Originally intended for descriptive models • Now it also supports prescriptive models • models execution • code generation • but more importantly… 9
  10. 10. VRIJE UNIVERSITEIT AMSTERDAM Main characteristics of UML UML is a formal modeling language à all its concepts have a well-defined meaning 10 Modeling with code Informal model UML model
  11. 11. VRIJE UNIVERSITEIT AMSTERDAM Where are the “meanings” of UML concepts? The UML superstructure 640 pages like this! à Don’t read it, use it only as a manual in case of doubts http://www.omg.org/spec /UML/2.5/ 11
  12. 12. VRIJE UNIVERSITEIT AMSTERDAM UML diagrams A UML model is represented graphically by diagrams 12
  13. 13. VRIJE UNIVERSITEIT AMSTERDAM UML structure diagrams • Emphasize the static description of the elements of the system being modeled • ex: student submission system à • Structural elements may have an associated behavior 13
  14. 14. VRIJE UNIVERSITEIT AMSTERDAM UML behavioural diagrams • Behavior = the direct consequences of an action of at least one object • It affects how the states of objects change over time • Behavior can either be • specified through the actions of a single object • • result from interactions between multiple objects à 14 Submission
  15. 15. VRIJE UNIVERSITEIT AMSTERDAM Which diagrams you will see in this course • Use case diagram • to specify the basic functionality of a software system • aka requirements • Class diagram • to define which objects or which classes are involved in the realization of this functionality • State machine diagram • to define the intra-object behavior • Sequence diagram • specifies the inter-object behavior and communication 15 In your project you can use additional UML diagrams à BONUS in the final grade
  16. 16. VRIJE UNIVERSITEIT AMSTERDAM Models != diagrams • A UML model contains everything related to your system • it is complete • Diagrams are just “windows” on your model • technically they can be considered as projections of the same model • a particular diagram will show some parts of your model but not necessarily everything (recall abstraction?) 16 represented by System Model Class diagram Sequence diagram State machine diagram
  17. 17. VRIJE UNIVERSITEIT AMSTERDAM Models and diagrams in Papyrus 17 Diagram creation
  18. 18. VRIJE UNIVERSITEIT AMSTERDAM Models and diagrams in Papyrus 18The model The diagrams
  19. 19. VRIJE UNIVERSITEIT AMSTERDAM Requirements engineering 19
  20. 20. VRIJE UNIVERSITEIT AMSTERDAM Requirements engineering • The process of establishing • the services that a customer requires from a system • the constraints under which it operates and is developed • A requirement may range between • a high-level abstract statement of a service • Example: all the robots must avoid obstacles autonomously • a detailed mathematical functional specification • Example: each robot must communicate its position to the central station every 1 second 20
  21. 21. VRIJE UNIVERSITEIT AMSTERDAM Functional and non-functional requirements Functional requirements a. Services the system should provide b. How the system should react to particular inputs c. How the system should behave in particular situations d. May state what the system should not do Non-functional requirements a. Constraints on the services or functions offered by the system I. example: timing constraints, constraints on the development process, standards, etc. b. Often apply to the system as a whole rather than individual features or services 21
  22. 22. VRIJE UNIVERSITEIT AMSTERDAM Functional requirements • Precise • Ambiguous requirements may be interpreted in different ways by developers and users à problems • Complete • They should include descriptions of ALL facilities required • Consistent • There should be no conflicts or contradictions in the descriptions of the system facilities • In UML they are represented using Use case diagrams 22
  23. 23. VRIJE UNIVERSITEIT AMSTERDAM Non-functional requirements • System properties and constraints • e.g. reliability, response time and storage requirements • Constraints are I/O device capability, system representations, etc. • Non-functional requirements may be more critical than functional requirements • e.g., safety requirements • Non-functional requirements may affect the overall architecture of a system rather than the individual components • For example, to ensure that performance requirements are met, you may have to organize your system to minimize communications between robots 23
  24. 24. VRIJE UNIVERSITEIT AMSTERDAM Types of non-functional requirements 24 Performance requirements Space requirements Usability requirements Efficiency requirements Dependability requirements Security requirements Regulatory requirements Ethical requirements Legislative requirements Operational requirements Development requirements Environmental requirements Safety/security requirements Accounting requirements Product requirements Organizational requirements External requirements Non-functional requirements
  25. 25. VRIJE UNIVERSITEIT AMSTERDAM Robotic systems MUST be dependable 25
  26. 26. VRIJE UNIVERSITEIT AMSTERDAM Ways of writing requirements specifications 26 Notation Description Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. Structured natural language The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement. Design description languages This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications. Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. Mathematical specifications These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract
  27. 27. VRIJE UNIVERSITEIT AMSTERDAM Natural language specification • Requirements are written as natural language sentences • Used for writing requirements because it is expressive, intuitive and universal. • These requirements can be understood by users and customers • Guidelines: • Invent a standard format and use it for all requirements • Use language in a consistent way • Use “shall” for mandatory requirements, “should” for desirable requirements • Use text highlighting to identify key parts of the requirement • Avoid the use of computer jargon • Include an explanation (rationale) of why a requirement is necessary 27
  28. 28. VRIJE UNIVERSITEIT AMSTERDAM Example 28 R1. The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.) R2. The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.)
  29. 29. VRIJE UNIVERSITEIT AMSTERDAM Requirement validation checklist 29 • Validity • Does the system provide the functions which best support the customer’s needs? • Consistency • Are there any requirements conflicts? • Completeness • Are all functions required by the customer included? • Realism • Can the requirements be implemented given available budget and technology • Verifiability • Can the requirements be checked? I will use it when grading your project
  30. 30. VRIJE UNIVERSITEIT AMSTERDAM Use case diagrams 30
  31. 31. VRIJE UNIVERSITEIT AMSTERDAM Contents • Introduction • Use cases • Actors • Relationships between use cases and actors • Relationships between use cases • Relationships between actors • Description of use cases • Best practices • Typical errors • Notation elements 31
  32. 32. VRIJE UNIVERSITEIT AMSTERDAM Introduction Use case diagrams express the expectations of the customers/stakeholders § essential for a detailed design The use case diagram is used during the entire analysis and design process We can use a use case diagram to answer the following questions: § What is being described? (The system) § Who interacts with the system? (The actors) § What can the actors do? (The use cases) 32
  33. 33. VRIJE UNIVERSITEIT AMSTERDAM Example: Student Administration System System (what is being described?) § Student administration system Actors (who interacts with the system?) § Professor Use cases (what can the actors do?) § Query student data § Issue certificate § Announce exam
  34. 34. VRIJE UNIVERSITEIT AMSTERDAM Use Case • Describes functionality expected from the system under development • Provides tangible benefit for one or more actors that communicate with this use case • Set of all use cases describes the functionality that a system shall provide • Alternative notations:
  35. 35. VRIJE UNIVERSITEIT AMSTERDAM Actor (1/3) Actors interact with the system § by using use cases, i.e., the actors initiate the execution of use cases § by being used by use cases, i.e., the actors provide functionality for the execution of use cases. Actors represent roles that users adopt § Specific users can adopt and set aside multiple roles simultaneously Actors are not part of the system, i.e., they are outside of the system boundaries Alternative notations:
  36. 36. VRIJE UNIVERSITEIT AMSTERDAM Actor (2/3) Usually user data is also administered within the system. This data is modeled within the system in the form of objects and classes. Example: actor Assistant § The actor Assistant interacts with the system Laboratory Assignment by using it § The class Assistant describes objects representing user data (e.g., name, ssNr, …).
  37. 37. VRIJE UNIVERSITEIT AMSTERDAM Actor (3/3) Human § E.g., Student, Professor Non-human § E.g., E-Mail Server Primary: has the main benefit of the execution of the use case Secondary: receives no direct benefit Active: initiates the execution of the use case Passive: provides functionality for the execution of the use case Examples: 8 Non-human Secondary Passive Human Primary Active Human Primary Active Human Secondary Active
  38. 38. VRIJE UNIVERSITEIT AMSTERDAM Relationships between Use Cases and Actors • Actors are connected with use cases via solid lines (associations) • Every actor must communicate with at least one use case • An association is always binary • Multiplicities may be specified
  39. 39. VRIJE UNIVERSITEIT AMSTERDAM The behavior of one use case (included use case) is ALWAYS integrated in the behavior of another use case (base use case) Example: Relationships between Use Cases «include» - Relationship Base use case requires the behavior of the included use case to be able to offer its functionality Included use case may be executed on its own
  40. 40. VRIJE UNIVERSITEIT AMSTERDAM Relationships between Use Cases «extend» - Relationship • The behavior of one use case (extending use case) may be integrated in the behavior of another use case (base use case) but does not have to • Both use cases may also be executed independently of each other • A decides if B is executed • Extension points define at which point the behavior is integrated • Conditions define under which circumstances the behavior is integrated Base use case Extending use case
  41. 41. VRIJE UNIVERSITEIT AMSTERDAM Relationships between Use Cases «extend» - Relationship: Extension Points • Extension points are written directly within the use case • Specification of multiple extension points is possible • Example:
  42. 42. VRIJE UNIVERSITEIT AMSTERDAM Relationships between Use Cases Generalization of Use Cases Use case A generalizes use case B. B inherits the behavior of A and may either extend or overwrite it. B also inherits all relationships from A. B adopts the basic functionality of A but decides itself what part of A is executed or changed. A may be labeled {abstract} § Cannot be executed directly § Only B is executable Example: Base use case Sub use case
  43. 43. VRIJE UNIVERSITEIT AMSTERDAM Relationships between Actors Generalization of Actors Actor A inherits from actor B A can communicate with X and Y B can only communicate with Y Multiple inheritance is permitted Abstract actors are possible Example: Super-actor Sub-actor Professor AND Assistant needed for executing Query student data Professor OR Assistant needed for executing Query student data
  44. 44. VRIJE UNIVERSITEIT AMSTERDAM Description of Use Cases Structured approach § Name § Short description § Precondition: prerequisite for successful execution § Postcondition: system state after successful execution § Error situations: errors relevant to the problem domain § System state on the occurrence of an error § Actors that communicate with the use case § Trigger: events which initiate/start the use case § Standard process: individual steps to be taken § Alternative processes: deviations from the standard process [A. Cockburn: Writing Effective Use Cases, Addison Wesley, 2000]
  45. 45. VRIJE UNIVERSITEIT AMSTERDAM Description of Use Cases - Example Name: Reserve lecture hall Short description: An employee reserves a lecture hall at the university for an event. Precondition: The employee is authorized to reserve lecture halls. Postcondition: A lecture hall is reserved. Error situations: There is no free lecture hall. System state in the event of an error: The employee has not reserved a lecture hall. Actors: Employee Trigger: Employee requires a lecture hall. Standard process: (1) Employee logs in to the system. (2) Employee selects the lecture hall. (3) Employee selects the date. (4) System confirms that the lecture hall is free. (5) Employee confirms the reservation. Alternative processes: (4’) Lecture hall is not free. (5’) System proposes an alternative lecture hall. (6’) Employee selects alternative lecture hall and confirms the reservation.
  46. 46. VRIJE UNIVERSITEIT AMSTERDAM Best Practices Identifying Actors • Who uses the main use cases? • Who needs support for their daily work? • Who is responsible for system administration? • What are the external devices/(software) systems with which the system must communicate? • Who is interested in the results of the system?
  47. 47. VRIJE UNIVERSITEIT AMSTERDAM Best Practices Identifying Use Cases • What are the main tasks that an actor must perform? • Does an actor want to query or even modify information contained in the system? • Does an actor want to inform the system about changes in other systems? • Should an actor be informed about unexpected events within the system?
  48. 48. VRIJE UNIVERSITEIT AMSTERDAM Best Practices Typical Errors To Avoid (1/5) Use case diagrams do not model processes/workflows!
  49. 49. VRIJE UNIVERSITEIT AMSTERDAM Best Practices Typical Errors To Avoid (2/5) Actors are not part of the system, hence, they are positioned outside the system boundaries!
  50. 50. VRIJE UNIVERSITEIT AMSTERDAM Best Practices Typical Errors To Avoid (3/5) § Use case Issue information needs EITHER one actor Assistant OR one actor Professor for execution ü
  51. 51. VRIJE UNIVERSITEIT AMSTERDAM Best Practices Typical Errors To Avoid (4/5) Many small use cases that have the same objective may be grouped to form one use case ü
  52. 52. VRIJE UNIVERSITEIT AMSTERDAM Best Practices Typical Errors To Avoid (5/5) The various steps are part of the use cases, not separate use cases themselves! -> NO functional decomposition ü
  53. 53. VRIJE UNIVERSITEIT AMSTERDAM Name Notation Description System Boundaries between the system and the users of the system Use case Unit of functionality of the system Actor Role of the users of the system Notation Elements (1/2)
  54. 54. VRIJE UNIVERSITEIT AMSTERDAM Name Notation Description Association Relationship between use cases and actors Generalization Inheritance relationship between actors or use cases Extend relationship B extends A: optional use of use case B by use case A Include relationship A includes B: required use of use case B by use case A Notation Elements (2/2)
  55. 55. VRIJE UNIVERSITEIT AMSTERDAM Exercise Problem: flight booking system (FBS) A travel agency needs to manage flight bookings for its customers: 1) Airline companies offer various flights. It is the airline itself that decides to open and close the bookings for each flight, and that communicates it to the travel agencies. 2) A customer can book multiple flights and for different passengers. 3) A booking concerns a single flight and a single passenger. A booking can be opened, and then cancelled or confirmed. 4) When confirmed, the tickets are issued and delivered to the customer. 5) A flight has a departure airport and an arrival airport. A flight has a departure day and time, and an arrival day and time. 6) A flight may have stopovers in airports; a stopover has an arrival time and a departure time. 7) Each airport serves one or more cities. 55 Legenda Red: candidate actors Blue: candidate use cases
  56. 56. VRIJE UNIVERSITEIT AMSTERDAM What this lecture means to you? • UML = general purpose modeling language • tailored to object-oriented software systems • 1 UML model, many diagrams • Requirements • functional vs non-functional • Functional = the WHAT • text + use case diagrams + use case descriptions • Non-functional = the HOW • text + rationale • Use case diagrams rules and best practices 56
  57. 57. VRIJE UNIVERSITEIT AMSTERDAM Readings • UML@Classroom: An Introduction to Object-Oriented Modeling” – chapters 2 and 3 • Learning UML 2.0 – chapters 1 and 2 57

×