Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Luca Vigan
Dipartimento di Informatica Universit di Verona
System Models II
1 / 95
To explain why the context of a system should be modeled as part of the requirements engineering process. To describe behavioral modeling, data modeling, and object modeling. To introduce some of the notations used in the Unied Modeling Language (UML). Today we will focus on Use Cases.
System Models II
2 / 95
Outline
1 2 3
Software lifecycle activities... and their models UML Requirements engineering and Use Cases Reusing Use Cases (include) Separating variant behavior (extend) Generalization and specialization Requirements elicitation: identifying Use Cases Conclusions Example solution of the last homework Homework
4 5 6
System Models II
3 / 95
The context
Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance
Goal: Specify the requirements as far as possible, but as abstractly as possible. Modeling languages and methods are used here!
Luca Vigan (Universit di Verona) System Models II Ingegneria del SW, 30.03.11 4 / 95
System Models II
5 / 95
/M O I /R
I : mapping of real things in reality R to abstractions in model M . fM : relationship between abstractions in M . fR : relationship between real things in R .
System Models II
6 / 95
System Models II
7 / 95
UML
Outline
1 2 3
Software lifecycle activities... and their models UML Requirements engineering and Use Cases Reusing Use Cases (include) Separating variant behavior (extend) Generalization and specialization Requirements elicitation: identifying Use Cases Conclusions Example solution of the last homework Homework
4 5 6
System Models II
9 / 95
UML
OO-Modeling
Many proposed methodologies: OMT, OOA/OOD, UML, ... Example: Object Modeling Technique (OMT) includes: Object model: class hierarchies and associations between classes (like ERA). Functional model: describes information ow between objects (like data-ow). Dynamic Model: event oriented, e.g. (extended) automata (specify control). Advantages
Supports modular development of reusable systems. Often corresponds to real (e.g. graphic) objects.
System Models II
10 / 95
UML
System Models II
11 / 95
UML
Non-proprietary standard for modeling software systems, OMG. Convergence of notations used in object-oriented methods:
OMT (James Rumbaugh and collegues). Booch (Grady Booch). OOSE (Ivar Jacobson).
Commercial tools: Rational (IBM), Together (Borland), Visual Architect (business processes, BCD)... Open Source tools: ArgoUML, StarUML, Umbrello... Commercial and Opensource: PoseidonUML (Gentleware)...
System Models II
12 / 95
UML
UML overview
Importance:
Recommended OMG (Object Management Group) standard notation. De facto standard in industrial software development.
Another alternative: Business Object Notation (BON), mainly used in the Eiffel community.
System Models II
13 / 95
UML
UML
dynamic
Main Concepts class, association, generalization, dependency, realization, interface use case, actor, association, extend, include, use case generalization component, interface, dependency, realization node, component, dependency, location state, event, transition, action state, activity, completion transition, fork, join interaction, object, message, activation collaboration, interaction, collaboration role, message package, subsystem, model constraint, stereotype, tagged values
Ingegneria del SW, 30.03.11 15 / 95
UML
Use Case diagrams: requirements of a system. Class diagrams: structure of a system. Interaction diagrams: message passing. Sequence diagrams. Collaboration diagrams. State and activity diagrams: actions of an object. Implementation diagrams: Component model: dependencies between code. Deployment model: structure of the runtime system. Object constraint language (OCL).
System Models II
16 / 95
UML
System Models II
17 / 95
UML
System Models II
18 / 95
UML
System Models II
19 / 95
UML
System Models II
20 / 95
UML
System Models II
21 / 95
UML
System Models II
22 / 95
UML
System Models II
23 / 95
UML
UML: Summary
We will consider only few selected parts of UML in this course. Lets start with Use Cases.
System Models II
24 / 95
Outline
1 2 3
Software lifecycle activities... and their models UML Requirements engineering and Use Cases Reusing Use Cases (include) Separating variant behavior (extend) Generalization and specialization Requirements elicitation: identifying Use Cases Conclusions Example solution of the last homework Homework
4 5 6
System Models II
25 / 95
Requirements elicitation
System Models II
26 / 95
System Models II
27 / 95
First step in identifying the requirements: system identication. Two questions need to be answered:
1 2
How can we identify the purpose of a system? What is inside, what is outside the system?
These two questions are answered during requirements elicitation and analysis: Requirements elicitation: denition of the system in terms understood by the customer (requirements specication). Analysis: denition of the system in terms understood by the developer (technical specication, analysis model).
System Models II
28 / 95
Difculties:
Identifying an appropriate system (dening the boundary). Providing an unambiguous specication. Communicating about the domain and the system accurately (leaving out unintended features).
Challenges:
People with different backgrounds must collaborate. Bridge the gap between end-users and developers. Client and end users with application (problem) domain knowledge. Developers have solution domain knowledge (design knowledge, implementation knowledge).
System Models II
29 / 95
Ambiguous specication
During a laser experiment, a laser beam was directed at a mirror on the Space Shuttle Discovery. The laser beam was supposed to be reected back towards a mountain top 10,023 feet high. The operator entered the elevation as 10023. The computer interpreted the number in miles...
System Models II
30 / 95
Unintended Feature
From the news: London underground train leaves station without driver! What happened? A passenger door was stuck and did not close. The driver left his train to close the door. Before leaving the train, he tightens the start button on the console with tape. He relied on the specication that prevents the train from moving if a door is open. When he shut the passenger door, the train left the station without him.
System Models II
31 / 95
Types of requirement
User requirements: statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. System requirements: a structured document setting out detailed descriptions of the systems functions, services, and operational constraints. Denes what should be implemented so may be part of a contract between client and contractor.
System Models II
32 / 95
Functional requirements: statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Non-functional requirements: constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Domain requirements: requirements that come from the application domain of the system and that reect characteristics of that domain.
System Models II
33 / 95
Sources of information
System Models II
35 / 95
Requirements elicitation
System Models II
36 / 95
The requirements document is the ofcial statement of what is required of the system developers. Should include both a denition of user requirements and a specication of the system requirements. It is NOT a design document. As far as possible, it should set off (describe clearly) WHAT the system should do rather than HOW it should do it.
System Models II
37 / 95
System Models II
38 / 95
Use Cases
Use Cases are used for high-level requirements analysis.
Focuses on requirements of particular (classes of) users. A user is anything outside of the system (e.g. human or another system).
Developed by Jacobson (ca. 1990), based on idea of scenarios. Very simple! Diagrams represent possible interactions between: Actors: prototypical users in certain roles. Use Cases: their tasks. Example: a library system Use Case
System Models II
39 / 95
Use Case
Generalizes scenarios to describe all possible cases. Focus on completeness.
Scenarios
Narrative description of what people do and experience as they try to make use of computer systems and applications. That is, a scenario is a real-life example of how a system can be used: it is a sequence of steps describing an interaction between a user and a system. They should include:
A description of the starting situation. A description of the normal ow of events. A description of what can go wrong. Information about other concurrent activities. A description of the state when the scenario nishes.
Scenario:
Bob uses a Bankomat. He enters his card and PIN into the Bankomat. He requests withdrawal of EURO 100. Bankomat checks availability of amount with the host. Bob receives a printed receipt, takes out his bank card and the money and leaves.
Observations:
Describes a single instance of using the system. Does not describe all possible ways the system can be used. The interaction with system could even fail (e.g. wrong PIN, or not enough money on account).
System Models II
42 / 95
A set of Use Cases should describe all possible interactions with the system. Sequence diagrams may be used to add detail to Use Cases by showing the sequence of event processing in the system.
Luca Vigan (Universit di Verona) System Models II Ingegneria del SW, 30.03.11 45 / 95
System Models II
46 / 95
N.B.: there is no standard way to write a Use Case, and different formats work well in different cases.
Luca Vigan (Universit di Verona) System Models II Ingegneria del SW, 30.03.11 47 / 95
Each step in a Use Case is an element of the interaction between an actor and the system.
Each step should be a simple statement and should clearly show who is carrying out the step. The step should show the intent of the actor, not the mechanics of what the actor does. Consequently, one does not describe the user interface in the Use Case (writing the Use Case usually precedes designing the user interface).
System Models II
49 / 95
Some of these issues can be specied with extensions or with other kinds of models.
Luca Vigan (Universit di Verona) System Models II Ingegneria del SW, 30.03.11 50 / 95
System Models II
51 / 95
System Models II
52 / 95
extend stereotype to provide special case: can be used to factor different behavior into a single scenario.
Syntax: dashed arrow now from exception to main case. Normal case species point at which the behavior may diverge (extension point). Extending case species condition under which the special case applies (as entry condition).
Luca Vigan (Universit di Verona) System Models II Ingegneria del SW, 30.03.11 58 / 95
System Steps
2. Bankomat displays options 4. Bankomat queries amount 5. Client enters amount 6. Bankomat returns bank card listed as extension point 7. Bankomat outputs specied amount
System Models II
59 / 95
Entry condition: Entered amount higher than money in account. System Steps: 6a. Bankomat displays error message; rejoin before 4.
System Models II
60 / 95
MemberOfStaff
borrows/returns 1 0..*
Journal
System Models II
65 / 95
System Models II
66 / 95
System Models II
67 / 95
System Models II
69 / 95
Identifying actors
Actors represent roles: an actor is a role that a user plays with respect to the system.
Actors carry out Use Cases: a single actor may perform many Use Cases, and conversely a Use Case may have several actors performing it. One person can have several roles, and many persons can have the same role. In companies, roles usually exist before system is built.
Actually, apparently there was a mistranslation from Swedish: the term actor is now standard but the proper term should have been role. Questions to ask:
Which user groups are supported by the system? Which user groups execute the systems main functions? Which user groups perform secondary functions (maintenance, administration)? With what external hardware and software will the system interact?
Luca Vigan (Universit di Verona) System Models II Ingegneria del SW, 30.03.11 70 / 95
During initial stages of actor identication, it is difcult to distinguish actors from objects. Example: database system can be
an actor (external software) or an object (part of the system).
System Models II
71 / 95
What are the tasks the actor wants the system to perform? What information does the actor access?
Who creates that data? Can it be modied or removed? By whom?
Which external changes does the actor need to inform the system about?
How often? When?
Which events does the system need to inform the actor about?
With what latency?
System Models II
72 / 95
Example: bankomat
What needs to be done to withdraw money? Who is involved in a withdrawal? What does the system do if there is not enough
money in the account? cash in the Bankomat?
What information does the client access? Can clients perform several tasks in one session?
System Models II
73 / 95
Sources of information
System Models II
74 / 95
Dialectic approach
System Models II
75 / 95
Types of scenarios
Visionary scenario: Used to describe a future system. Usually used in greeneld engineering and reengineering projects. Can often not be done by the user or developer alone. As-is scenario: Used in describing a current situation. Usually used in reengineering projects. The user describes the system. Evaluation scenario: User tasks against which the system is to be evaluated. Training scenario: Step by step instructions that guide a novice user through a system.
Luca Vigan (Universit di Verona) System Models II Ingegneria del SW, 30.03.11 76 / 95
Scenarios are generalized to high-level Use Cases. Name: a verb describing what the actor wants to accomplish. Initiating actor:
Helps to clarify roles. Helps identifying previously overlooked actors.
High-level description:
Entry and exit conditions (identify missing cases). Event ow (dene system boundary). Quality requirements (elicit non-functional requirements).
System Models II
77 / 95
Exit condition:
Client is authenticated.
Luca Vigan (Universit di Verona) System Models II Ingegneria del SW, 30.03.11 78 / 95
System Steps
2. Bankomat requests the input of a four-digit PIN listed as extension point 3. Client types in PIN Triggers for extending Use Cases (error conditions) are specied in extending Use Cases (as entry conditions).
System Models II
79 / 95
Exit condition:
Client receives an explanation from the Bankomat about why she was not authenticated.
Actor steps
System Steps 2a. Bankomat outputs the card, displays a message, and stops the interaction
System Models II
80 / 95
System Models II
82 / 95
Name of Use Case. Actors: description of actors involved in Use Case. Entry condition: This Use Case starts when... Flow of Events: free form, informal natural language. Exit condition: This Use Case terminates when... Exceptions: describe what happens if things go wrong. Special Requirements: non-functional requirements, constraints.
System Models II
83 / 95
Many Use Cases are rewritten several times. Focus: completeness and correctness. Activities during renement:
Add details to Use Cases. Specify low-level sequences of interactions. Specify access rights (which actor can invoke which Use Case). Identify missing exceptions and specify handling. Factor out common functionality.
System Models II
84 / 95
Communication relationships among actors and Use Cases: initiate vs. participate. Extend relationships:
Make common case simple. Used for exceptional, optional, or seldom-occurring behavior.
Include relationships:
Eliminate redundancies. Used for behavior shared by at least two Use Cases.
System Models II
85 / 95
Conclusions
Outline
1 2 3
Software lifecycle activities... and their models UML Requirements engineering and Use Cases Reusing Use Cases (include) Separating variant behavior (extend) Generalization and specialization Requirements elicitation: identifying Use Cases Conclusions Example solution of the last homework Homework
4 5 6
System Models II
86 / 95
Conclusions
Key points
Scenarios: Good way to establish communication with client. Use Cases: abstraction of scenarios. Use Cases bridge the gap between functional requirements and objects. Use Cases models are useful for initial requirements analysis. Idea is simple, but effective in stimulating analysis and provides simple structuring mechanisms. Further extensions are possible: Different icons for actors, interfaces, processes, ... Extensions show the spirit of UML, as well as advantages and disadvantages.
System Models II
87 / 95
Conclusions
Bibliography
Ian Sommerville. Software Engineering. Pearson Education Ltd. Martin Fowler. UML distilled (3rd ed.). Addison Wesley. Sinan Si Alhir. UML in a nutshell. OReilly. I. Jacobson, M. Christerson, P. Jonsson, G. vergaard. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison Wesley, 1992. A. Cockburn. Writing Effective Use Cases. Addison Wesley, 2001. See http://usecases.org To draw Use Case diagrams (and other UML diagrams):
Poseidon for UML (http://www.gentleware.com). ArgoUML (http://argouml.tigris.org/).
System Models II
88 / 95
Outline
1 2 3
Software lifecycle activities... and their models UML Requirements engineering and Use Cases Reusing Use Cases (include) Separating variant behavior (extend) Generalization and specialization Requirements elicitation: identifying Use Cases Conclusions Example solution of the last homework Homework
4 5 6
System Models II
89 / 95
DayBeginDuration
contains
PreferredDayBeginDurations
(scheduling variant) n
RoomOffer
n
Day Begin
Duration
1
contains
contains
contains
1 1 contains 1
Instructor
participates in
EventOffer
EventAssignment
n
Name Rank
ResearchGroup
contains
EventOfferID Title Type Requirements
ClassSchedule
System Models II
90 / 95
Two remarks. First, note that two entities in this diagram, namely PreferredDayBeginDurations and EventAssignment, have an aggregative character, i.e. they are collections (sets, lists, etc.) of entities. (They correspond to type-constructors in higher-order programming/specication languages.) In other words, an EventAssignment consists of a triple of an EventOffer (or its ID, EventOfferID ), a PreferredDayBeginDurations, and a collection (set, list, etc.) of Rooms (or their IDs, RoomID ), which are assigned to an event. Second, note that some of the relationships are implicitly directed, e.g. a PreferredDayBeginDurations contains several DayBeginDurations, an EventOffer contains several PreferredDayBeginDurations, and an EventOffer is contained in an EventAssignment, but not the other way round.
System Models II
91 / 95
Note: Following general data-modeling terminology, constraints are general consistency conditions for data; data entities not fullling their constraints are not considered as legal input into the system. In contrast, conicts (against the scheduling requirements) in the sense of the product sketch are not illegal, since CSS must handle class-schedule variants with conicts in order to choose better or worse variants. Having n conicts of type X is a dynamic property of a schedule variant; it depends on the actual state of the room data-base and event-offer data-base.
System Models II
92 / 95
Following the general problem description of the client, we can identify the following constraints: DayBeginDurations are constrained as follows: Day must be different from Saturday and Sunday; Begin must be between 8 and 17 oclock; the end (i.e. Begin + Duration) must occur not after 18 oclock. All IDs must be unique. An EventAssignment must contain only one PreferredDayBeginDurations, which must be contained also in the corresponding EventOffer. The number of assigned Rooms must correspond to the number of DayBeginDurations of the PreferredDayBeginDurations. The different PreferredDayBeginDurations of an event in an EventOffer must have different Day s. For example, a PreferredDayBeginDurations may contain the list [Tu:9:2, Th:14:2], but not the list [Tu:9:2, Tu:14:2]. All PreferredDayBeginDurations of an event in an EventOffer must have the same overall duration. For example, an EventOffer may be the list [[Tu:9:2, Tu:14:2], [Tu:11:2, Th:16:2]], but not the list [[Tu:9:2, Th:14:2], [Tu:11:2, Th:16:1]]. The ClassSchedule must assign an EventAssignment to each EventOffer.
System Models II
93 / 95
Homework
Outline
1 2 3
Software lifecycle activities... and their models UML Requirements engineering and Use Cases Reusing Use Cases (include) Separating variant behavior (extend) Generalization and specialization Requirements elicitation: identifying Use Cases Conclusions Example solution of the last homework Homework
4 5 6
System Models II
94 / 95
Homework
Homework
We continue with our Class Scheduling System software-project: give a high-level Use Case diagram, which illustrates the system participants (the actors) and the main Use Cases.
System Models II
95 / 95