Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit...
-
Upload
ivano-malavolta -
Category
Technology
-
view
460 -
download
0
Transcript of Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit...
![Page 1: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/1.jpg)
Software and Services research group (S2)
Department of Computer Science, Faculty of SciencesVrije Universiteit Amsterdam
VRIJEUNIVERSITEITAMSTERDAM
Requirements engineering with UML
Software modeling (401016) – 2016/2017
Ivano [email protected]
![Page 2: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/2.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Announcement
The template for Deliverable 1 will be available today on BlackBoard!
2
![Page 3: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/3.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Roadmap
• Introduction to UML• What is UML?• Main characteristics of UML• UML diagrams
• Requirement engineering• Use case diagrams
3
![Page 4: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/4.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 5: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/5.jpg)
VRIJEUNIVERSITEITAMSTERDAM
What is UML?
• UML = Unified Modeling Language• De facto standard software design language
• Developed by OMG
• A “Swiss Army Knife” of notations
5
![Page 6: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/6.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Why UML in this course?
The most used language for modeling software
6
34 job postings requiring UML in Amsterdam (as of last week)
![Page 7: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/7.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Who uses UML?
7
![Page 8: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/8.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 9: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/9.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 10: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/10.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 11: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/11.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 12: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/12.jpg)
VRIJEUNIVERSITEITAMSTERDAM
UML diagrams
A UML model is represented graphically by diagrams
12
![Page 13: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/13.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 14: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/14.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
Su
bm
issi
on
![Page 15: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/15.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 16: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/16.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
representedby
System Model
Class diagram
Sequence diagram
State machinediagram
![Page 17: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/17.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Models and diagrams in Papyrus
17
Diagram creation
![Page 18: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/18.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Models and diagrams in Papyrus
18The model
The diagrams
![Page 19: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/19.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Requirements engineering
19
![Page 20: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/20.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 21: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/21.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Functional and non-functional requirements
Functional requirementsa. Services the system should provideb. How the system should react to particular inputs c. How the system should behave in particular situationsd. May state what the system should not do
Non-functional requirementsa. 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
![Page 22: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/22.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 23: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/23.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 24: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/24.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Types of non-functional requirements
24
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Dependabilityrequirements
Securityrequirements
Regulatoryrequirements
Ethicalrequirements
Legislativerequirements
Operationalrequirements
Developmentrequirements
Environmentalrequirements
Safety/securityrequirements
Accountingrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
![Page 25: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/25.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Robotic systems MUST be dependable
25
![Page 26: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/26.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Ways of writing requirements specifications
26
Notation DescriptionNatural language The requirements are written using numbered sentences in natural language.
Each sentence should express one requirement.
Structured naturallanguage
The requirements are written in natural language on a standard form ortemplate. Each field provides information about an aspect of the requirement.
Design descriptionlanguages
This approach uses a language like a programming language, but with moreabstract features to specify the requirements by defining an operational modelof the system. This approach is now rarely used although it can be useful forinterface specifications.
Graphicalnotations
Graphical models, supplemented by text annotations, are used to define thefunctional requirements for the system; UML use case and sequence diagramsare commonly used.
Mathematicalspecifications
These notations are based on mathematical concepts such as finite-statemachines or sets. Although these unambiguous specifications can reduce theambiguity in a requirements document, most customers don’t understand aformal specification. They cannot check that it represents what they want andare reluctant to accept it as a system contract
![Page 27: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/27.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 28: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/28.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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.)
![Page 29: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/29.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 30: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/30.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Use case diagrams
30
![Page 31: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/31.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 32: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/32.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 33: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/33.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 34: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/34.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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:
![Page 35: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/35.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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 boundariesAlternative notations:
![Page 36: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/36.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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, …).
![Page 37: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/37.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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 caseSecondary: receives no direct benefitActive: initiates the execution of the use casePassive: provides functionality for the execution of the use case
Examples:
8
Non-humanSecondaryPassive
HumanPrimaryActive
HumanPrimaryActive
HumanSecondaryActive
![Page 38: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/38.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 39: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/39.jpg)
VRIJEUNIVERSITEITAMSTERDAM
The behavior of one use case (included use case) is ALWAYSintegrated in the behavior of another use case (base use case)
Example:
Relationships between Use Cases«include» - Relationship
Base use caserequires the behavior of the included use case to be able to offer its functionality
Included use case may be executed on its own
![Page 40: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/40.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 41: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/41.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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:
![Page 42: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/42.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Relationships between Use CasesGeneralization 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
![Page 43: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/43.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Relationships between ActorsGeneralization of Actors
Actor A inherits from actor BA can communicate with X and YB can only communicate with YMultiple inheritance is permittedAbstract actors are possible
Example:
Super-actor
Sub-actor
Professor AND Assistant neededfor executing Query student data
Professor OR Assistant neededfor executing Query student data
![Page 44: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/44.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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]
![Page 45: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/45.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Description of Use Cases - Example
Name: Reserve lecture hallShort 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: EmployeeTrigger: 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.
![Page 46: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/46.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Best PracticesIdentifying 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?
![Page 47: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/47.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Best PracticesIdentifying 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?
![Page 48: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/48.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Best PracticesTypical Errors To Avoid (1/5)
Use case diagrams do not model processes/workflows!
![Page 49: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/49.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Best PracticesTypical Errors To Avoid (2/5)
Actors are not part of the system, hence, they are positioned outside the system boundaries!
![Page 50: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/50.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Best PracticesTypical Errors To Avoid (3/5)
§ Use case Issue information needs EITHER one actor Assistant OR one actor Professor for execution
ü
![Page 51: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/51.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Best PracticesTypical Errors To Avoid (4/5)
Many small use cases that have the same objective may be grouped to form one use case
ü
![Page 52: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/52.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Best PracticesTypical Errors To Avoid (5/5)
The various steps are part of the use cases, not separate use cases themselves! -> NO functional decomposition
ü
![Page 53: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/53.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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)
![Page 54: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/54.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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 usecase B by use case A
Include relationship
A includes B: required use of usecase B by use case A
Notation Elements (2/2)
![Page 55: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/55.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
LegendaRed: candidate actorsBlue: candidate use cases
![Page 56: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/56.jpg)
VRIJEUNIVERSITEITAMSTERDAM
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
![Page 57: Requirements engineering with UML [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]](https://reader031.fdocuments.us/reader031/viewer/2022030207/58aa70261a28abbc1e8b4b71/html5/thumbnails/57.jpg)
VRIJEUNIVERSITEITAMSTERDAM
Readings
• UML@Classroom: An Introduction to Object-Oriented Modeling” – chapters 2 and 3
• Learning UML 2.0 – chapters 1 and 2
57