Transcript use case

Software Development
2D1385
Karl Meinke
NADA
KTH
[email protected]
1.1. Lab Exercises
•
•
•
•
Labs 1,2 Java API, Graphics, event handling
Lab 3 client-server with sockets
Lab 4 XML, syntax and parsing
Lab 5 interprocess communication with
CORBA
• Lab 6 build a web browser using Java
Swing components
1.2. Course Book
“Software Design” by Eric Braude, 2004
Chpt: 0-2 Programming Concepts
3: Unified Modeling Language UML
4-5: Software Design Principles
6-9: Design Patterns
10-12: Software Components (Beans .NET)
13-14: Software architecture
1.3. Goals of the Course
• Software Design Theory and Practice
• Starts where programming and data structure
courses end
• Understanding how to satisfy requirements
specifications (application is correct and
adequate)
• Obtain robust, flexible reusable applications
• Apply abstraction, encapsulation and
modularity
1.4. Good Program Modules
• A program module should be simple, clear
and minimal
• It shouldn’t surprise the end-user
• Dependencies between modules should be
few
• Modules should be usable, correct, robust,
flexible and maintainable.
1.5. Checklist for Submitting
Work
• Which engineering/management model has
been used?
• Show your UML –diagram for the lab
• Demonstrate using a program execution that
the functional and design requirements are
satisfied
• Explain how robustness, and reusability are
satisfied
1.5. Checklist (2)
• How have you achieved abstraction,
encapsulation and modularity
• Which design patterns have been used?
• Which classes have you reused from earlier
labs? (With refactoring?)
• Which new classes have you used, and
why?
1.5. Checklist (3)
• How have you performed functional
testing?
• How have you documented your program
(comments, javadoc etc.)
• Point out the most critical pieces of code.
• In retrospect, what would you have done
differently if the project had continued?
1.6. UML
The Unified Modeling Language (2.0)
• Class/Object diagrams (static)
• Sequence diagrams (dynamic)
• Activity diagrams (dynamic)
• Statecharts (dynamic)
Standard developed by OMG adopts earlier
ideas (Booch, Rumbaugh, Jacobson)
1.6.1. Models
Models express requirements, architecture &
detailed design. (Video Game examples)
Use Case Model: In this situation do the
following …
e.g. how to engage a foreign character
Object / Class Model: with objects of these
classes …
Object provides a set of services, e.g.
engagement class.
State Model: by reacting to these events …
state/event  reaction
e.g. if foreign character shoots while we are
friendly … run away
Data Flow Model: in this way …
e.g. bullet objects flow from foreign character
object to player object.
Use Cases
Class Model
Target App
Data Flow
State Model
2. O-O Analysis & Design
The basic OOA&D approach (iterative)
1. State the main use cases
2. Convert the use cases to sequence
diagrams
3. Select the resulting domain classes
4. If not finished goto 1.
2.1. UML Use Case Diagrams
UML gives us a graphical language to
organize all our use case scenarios into
one overview:
Use Case Diagrams
These display:
• actors
• use cases
• associations, i.e. which actors are involved in
which scenario
Activate
Clerk
Check in
Check out
Stocker
Add video
Precondition: app has
been activated
1. Actor clicks
“check out”
2. Actor swipes bar
code ….
Postcondition: video
is registered to
customer
2.2. Use Case Modeling
In O-O based IT projects, we can begin the
requirements analysis phase with a
Use Case Analysis
A use case is a common or representative
situation where one or more external users
and/or systems interact with the system to
solve an instance of a common problem
Notice the underlined word “common”
Software seems to obey the statistical
Pareto Law
90% of time is spent executing just 10%
of the code
Therefore care in designing just this 10% of
code is “cheap” and will give a good product
90% of the time (at least in theory!)
Note: we want to decouple
specific users (e.g. John Smith)
From their roles, e.g.
student, teacher, systems administrator, etc.
A role will be called an actor.
A specific proper noun (object)
e.g. Karl Meinke, may play several roles:
teacher, researcher, sysadmin ...
Use Case Modeling involves three steps
that may be repeated until we are satisfied.
Step 1. Identify, name and define each actor
in terms of:
(a) Goals, i.e. what the actor wants to do,
(b) Needs, i.e. what services from the system
the actor requires to meet each goal.
Step 2. For each system service
(identified in Step 1), informally describe the
• preconditions and
• results of the service, and its,
• interaction with the actors in:
– a typical case (sunny day scenario).
– exceptional and error cases (rainy day scenario)
Such a service description is called an
informal description of a use case
scenario.
Step 3. For each informal description which
is:
– mission critical
– unclear, or
– ambiguous
formalise the interaction of the system and
the relevant actors using a sequence diagram
Step 4. [If necessary, repeat Steps 1-3]
Makes an iterative requirements analysis
1. Actors
3. Sequence
Diagrams
2. Use
cases
2.3. Example
Let us analyse requirements on a
Warehouse management system
Step 1. We begin by identifying actors
(perhaps by looking at a particular warehouse
and identifying job titles). This might give
the following:
• Foreman: responsible for one warehouse.
• Warehouse Worker: works in a warehouse
loading and unloading goods.
• Truck Driver: drives a truck between
different warehouses
• Forklift Operator: drives a forklift in a
warehouse
• Office Staff?, Customers? Security Staff??
…
Table 2.3.1
These actor definitions are short, but enough
to get started on Step 2. By iterating again
later we can add more details.
Step 2 asks to focus on the services which the
system (warehouse management software)
must provide.
We build a list of informal use case scenarios.
Notice how in Table 2.3.1 we underlined:
• Nouns: e.g. foreman, warehouse, …
• Verbs: e.g. loading, unloading …
• Relational Phrases: e.g. responsible for,
works in, … (prepositions?)
(Notice the possible overlap between verbs
and relational phrases.)
This identification work is the heart of O-O
analysis and design, since …
2.3.2. Central O-O Dogma
• Common Nouns e.g. warehouse, truck,
correspond to classes and attributes
• Proper Nouns e.g. Karl, Fido, KTH,
correspond to objects
• Verbs e.g. unload, correspond to methods
• Relational Phrases e.g. responsible for,
works with correspond with system and/or
software “structure”
Not every noun will be an actor …
(does a forklift truck have any goals ???)
… but every actor will be a noun, so:
Actors  Nouns
Step 2 requires us to look at each actor in turn
(in our case there are 4 actors) and ask:
• What does this actor want to do (all verbs)?
• What does the actor need from the system
to accomplish each activity (each verb)?
Let’s look at the 1st actor “foreman” and try
to analyse the verb “responsible”.
(a) A foreman has to be able to move items
between warehouses with or without a
customer order. This use case scenario is
called “manual redistribution between
warehouses”
(b) A foreman also wants to check how far a
customer order has been processed. We call
this use case scenario “check status of a
customer order”.
Let’s try to informally define the 1st use case
scenario: “manual redistribution between
Warehouses”.
This could be broken down into 4 steps
(1) Initialisation: when a foreman gives a
request to do a redistribution.
(2) Planning: when the system plans how to
co-ordinate the various transports, and
issues transport requests
(3) Loading: when a truck fetches the items
from a source warehouse.
(4) Unloading: when a truck delivers items
to a destination warehouse.
Is there anything wrong with this use case?
(1) It is very short!
- but we can add detail later!
(2) It doesn’t say what happens if things go
wrong.
- We need to add exception/error cases.
- The more of these we add, the more
robust our system will be.
2.4. UML Sequence Diagrams
A use case scenario describes a
sequence of interactions
or
messages
between a
collection of actors and the system
in order to carry out some task
Often we would like to formally model
a use case scenario, to study:
•
•
•
•
•
timing aspects (relative or absolute)
communication patterns
system states
exception behavior
alternative paths or behaviors
2.4.1. Elementary Concepts
A basic sequence diagram depicts a set of objects or
processes each of which has its own timeline.
Conventionally, objects go across the diagram
horizontally, while time goes down the diagram
vertically. Down the timelines, between
objects, we show messages.
Here is our earlier sequence diagram drawn as an SD/MSC:
SD Print
object/process
C : Computer
>lpr
file
>done
(time)
timeline
P : Print_server
print(file, device)
done
message
print(file,size)
done
D : Device
Notice that:
• This basic SD has 3 objects and 6 messages
• 1 message comes from the environment:
>lpr file (from the keyboard??)
• 1 message goes to the environment
>done(time) (to the screen??)
• The environment is an implicit actor
• Each timeline has a terminating block at the
bottom, which does not mean that the object
dissappears/ gets deleted, life goes on!!
2.4.2. The Time Concept
An SD/MSC must show
dynamic behavior over time
Down each timeline we see a set of events .
Each event may either be:
• sending of a message (arrow tail)
• receiving of a message (arrow head)
Each timeline shows the local relative order
between events, but not the absolute time
interval between events.
Thus the basic model of time is relative
(instead of absolute).
Also, for every message m:
send(m) occurs before receive(m)
This means that, e.g.
receive(>lpr file) occurs before
send( print(file, device) )
which occurs before
receive(done)
which occurs before
send(>done(time) )
and e.g. send(done)
occurs before receive(done)
We don’t know the absolute time between sending
and receiving a message, i.e. message delay.
e.g these two diagrams express the same scenario.
SD 2
SD 1
A
B
A
B
“a”
“a”
“b”
“b”