Requirements engineering with UML [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018]
2 likes2,394 views
This document provides a comprehensive overview of the Unified Modeling Language (UML) and its application in requirements engineering and software design, emphasizing its importance in modeling software systems. It outlines key characteristics of UML, including its non-reliance on any specific development process, and covers various diagram types such as use case diagrams, class diagrams, and state machine diagrams. Furthermore, it discusses the differentiation between functional and non-functional requirements, and best practices for writing and validating requirements specifications.
![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]](https://image.slidesharecdn.com/02requirements-180213083117/85/Requirements-engineering-with-UML-Software-Design-Computer-Science-Vrije-Universiteit-Amsterdam-2017-2018-43-320.jpg)
Requirements engineering with UML [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018]
- 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 design (400170) – 2017/2018 Ivano Malavolta [email protected]
- 2. VRIJE UNIVERSITEIT AMSTERDAM Announcement The template for Deliverable 1 is already available on Canvas! 2
- 3. VRIJE UNIVERSITEIT AMSTERDAM Roadmap • Introduction to UML • What is UML? • Main characteristics of UML • UML diagrams • Requirements engineering • Use case diagrams 3
- 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. 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. VRIJE UNIVERSITEIT AMSTERDAM Why UML in this course? The most used language for modeling software 6 38 job postings requiring UML in Amsterdam (as of today)
- 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. 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. 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. 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. VRIJE UNIVERSITEIT AMSTERDAM UML diagrams A UML model is represented graphically by diagrams 12
- 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. 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 be either • specified through the actions of a single object • result from interactions between multiple objects à 14 Submission
- 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 data structures within the system • State machine diagram • to define intra-object behavior • Sequence diagram • specifies inter-object behavior and communication 15 In your project you can use additional UML diagrams à BONUS in the final grade
- 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. VRIJE UNIVERSITEIT AMSTERDAM Models and diagrams in Papyrus 17 Diagram creation
- 18. VRIJE UNIVERSITEIT AMSTERDAM Models and diagrams in Papyrus 18The model The diagrams
- 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. 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. 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. 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. 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. VRIJE UNIVERSITEIT AMSTERDAM Robotic systems MUST be dependable 25
- 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. 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. 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. 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
- 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. VRIJE UNIVERSITEIT AMSTERDAM Introduction Use case diagrams express the expectations of the customers/stakeholders § essential for a detailed design 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. 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. VRIJE UNIVERSITEIT AMSTERDAM Use Case • Describes functionality expected from the system under development • The set of all use cases describes the functionality that a system shall provide • Alternative notations:
- 35. VRIJE UNIVERSITEIT AMSTERDAM Actor (1/2) 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 have multiple roles simultaneously Actors are not part of the system, i.e., they are outside of the system boundaries Alternative notations:
- 36. VRIJE UNIVERSITEIT AMSTERDAM Actor (2/2) 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
- 37. 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
- 38. 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
- 39. 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
- 40. 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:
- 41. 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
- 42. 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 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
- 43. 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]
- 44. 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.
- 45. 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?
- 46. 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?
- 47. VRIJE UNIVERSITEIT AMSTERDAM Best Practices Typical Errors To Avoid (1/5) Use case diagrams do not model processes/workflows!
- 48. 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!
- 49. VRIJE UNIVERSITEIT AMSTERDAM Best Practices Typical Errors To Avoid (3/5) § Beware of incorrect associations! § Use case Issue information needs EITHER one Assistant OR one Professor ü
- 50. VRIJE UNIVERSITEIT AMSTERDAM Best Practices Typical Errors To Avoid (4/5) Too many use cases, one for each possible situation à Many small use cases that have the same objective may be grouped to form one use case ü
- 51. VRIJE UNIVERSITEIT AMSTERDAM Best Practices Typical Errors To Avoid (5/5) Detailed functional decomposition à The various steps of a functionality are part of the same use case, not separate use cases themselves! ü
- 52. 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)
- 53. 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)
- 54. 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 • UML use case diagrams rules and best practices 55
- 55. VRIJE UNIVERSITEIT AMSTERDAM Readings • UML@Classroom: An Introduction to Object-Oriented Modeling” – chapters 2 and 3 • Learning UML 2.0 – chapters 1 and 2 56