Transcript Business Use case symbols

Business analysis - Naiburg and
Maksinchuk (UML for database design )
• The first phase systems analysis.
• Identify business actors and their roles
prior to system use cases.
• Distinguish between
– Business actors.
– Actors.
• In ARGOUML these can be represented
as stereotypes.
UML for database design
1
Business Use case elements
• Distinguish between
– Business use cases.
– System Use cases.
• Activity diagrams are used to indicate the
activities carried out by actors involved in use
cases.
• At least one activity diagram per use case.
• Initial business models are built.
• Database designers can see required elements
for databases.
UML for database design
2
Business Use case symbols
UML for database design
3
Build up a context of the system to
be examined
UML for database design
4
Look in side the context for
activities
• Initial analysis of EAB reveals 30 use cases so
W.A.V.E. some away.
• Does the use case describe What to do and not
how?
• Is the use case described from the Actors point
of view.
• Does the use case include Value for the actor.
• Is the flow of events an Entire business process.
UML for database design
5
Business Use case model expanded.
UML for database design
6
Activity Diagrams in EAB
• Used to explain the detailed interaction
between the Actors and the use case.
• Describes one use case usually.
• Describes the sequence of activities
contained within the use case.
• Graphical alternative to textual
templates.
UML for database design
7
EAB Activity example
UML for database design
8
Identify Business Objects
• Differentiate between
–
–
–
–
Business actors.
Business workers.
Business entities.
These too can be defined
using classes with
stereotypes in ARGOUML.
After all actors are special
instances of classes.
Business
object model
for Respond
to Inquiry
business
use case
Inquirer
Facility Manager
UML for database design
Clinical Records
9
Representing Business Objects in
ARGOUML and Rational Rose
• We use the class modelling
ARGOUML has a business, worker,
element to represent the
and entity stereotype already.
relationships between
business objects.
• Create an ordinary class
objects but set the stereotype
to business entity or one of the
others.
• To create the stereotype. Press
the up arrow until you get to
the model level in the
hierarchy of model elements.
You will recognise it by the
menu bar.
• Then choose the add
stereotype button.
UML for database design
10
Representing Business Objects in
ARGOUML and Rational Rose
• Once a stereotype is created then you can attach it to any
class definition. Thus we can get the equivalent representation
as shown. Note the attribute and operation compartments are
hidden.
• The same effect can be achieved in rational rose.
• The relationship between objects is important from the point
view of the database designer as it can indicate
– Access to data object by certain entities (workers and actors)
– Information which will need to be stored (business entities)
UML for database design
11
Sequence diagrams and business
objects
• Sequence diagram show the detailed
interaction between objects.
• Can be used to show the interaction
between business objects.
• From these diagrams we can gather new
information for the object model.
UML for database design
12
Example from EAB of business
object model development
• From the following
part of the Use Case
model.
UML for database design
13
Activity diagram for manage clinical
records
UML for database design
14
Sequence diagram for transfer records in
UML for database design
15
Divulging further information about
business models
• From sequence diagrams and activity diagrams
we can get an indication elements of a business
object model and their nature and relationships.
• For example from the sequence diagram we can
see that there are two types of clinical records.
We also see who has access to the clinical
records. This is important for the database
designer.
• From this information and a few more sequence
diagrams we get a business object model for this
part of the system.
UML for database design
16
Business object model for manage
clinical records ARGOUML Notation
UML for database design
17
A complete Business object model for
manage clinical records - book notation
UML for database design
18
A complete business object model for
manage clinical records ARGOUML
• Looking at further activities and sequence diagrams
(see text book) we get a more complete picture.
UML for database design
19
Stipulating roles of actors
• Again Use class generalisation (hierarchy) to represent roles of
various actors with stereotypes.
Only part
Of
Diagram show
Here See text for
Complete
Diagrams.
UML for database design
20
Stipulating roles of actors Book
notation
UML for database design
21
Why Business Model?
• Business practices and actors roles change when a
computer system is introduced.
• Interaction between different types of actors gives an
initial object model, which can be used for both
– database design
– class diagrams.
• Preloads system use case diagrams.
• A lot of the time there will be little difference between
business and system use case models, if the business
practices are initially well structured (although the role of
some individuals might still change.
UML for database design
22
Moving to the System Model
•
•
All business modelling elements must be included in the system model.
We look at all the models developed
–
–
–
–
Business use case model.
Activity diagrams and use case templates if available.
Sequence diagrams.
Business object model
In the Business Model
In the System Model
Business use Cases
Become
Subsystems
Business Actors
Become
Actors
Business workers
Become
Actors or Use Cases
Business workers’
activities
Become
Use Cases
UML for database design
23
Moving to the System Model
• We look to automate the activities of some of the
business workers.
• We can do this by looking at the activity
diagrams involving the business actors and
combining activities carried out into a use case.
• We also want to carry over the external business
actors to the system use case
• We also look at the Actor generalisations.
– We use the generalised name on the system use
case.
– We look for overlap in the functions carried out by
actors to come up with common use cases.
UML for database design
24
System Use Case EAB
•
By examining the various artefacts
produced in the business analysis
we come up with the following
system diagram.
UML for database design
25
EAB system Use case Assess
Clinical Records sub-use case
UML for database design
26