Modulo 02 - BMUMLv2001 - 04 - 00 (Compatibility Mode) PDF

Business Modeling with the UML
Module 2 – Using the Unified Modeling Language 2-1




Business Actor:
To fully understand the purpose of a business, you must know who the
business interacts with; that is, who puts demands on it, or is interested
in its output. The different types of "interactors" are represented as
business actors.
The term actor means the role someone or something plays while
interacting with the business. The following types of business users are
examples of potential business actors:
• Customers
• Suppliers
• Partners
• Potential customers (the "market place")
• Local authorities
• Colleagues in parts of the business not modeled.
Hence, an actor normally corresponds to a human user. However, there
are situations where, for instance, an information system plays the role
of an actor. If your bank’s online services are so good that your
business can manage most of its bank transactions from a PC on your
own premises, your use cases interacting with the "money supplier"
actor, the bank, will in fact interact with an information system.
An actor represents a particular type of business user rather than a real
physical user. Several physical users of a business can play the same
role in relation to it; that is, they act as instances of one and the same
actor. Also, the same user can act as several different actors. This
means that one and the same person can embody instances of different
actors.

Business Use Case:

The processes of a business are defined as a number of different
business use cases, each of which represents a specific workflow in the
business. A business use case defines what should happen in the
business when it is performed; it describes the performance of a
sequence of actions that produces a valuable result to a particular
business actor.
A business use case describes "a sequence of actions performed in a
business that produces a result of observable value to an individual
actor of the business." Hence, from an individual actor’s perspective, a
business use case defines the complete workflow that produces the
desired results. This is similar to what is generally called a "business
process," but "a business use case" has a much more precise definition.
The definition of the business use case concept contains a number of
keywords that are essential to understanding what a business use case
is:
Business use case instance – Defined above is really a specific
business workflow; that is, an instance. In reality, there are a great
number of possible workflows, many of them very similar.
To make the use-case model understandable, similar workflows are
grouped together into a business use case—a "class" in terms of the
object model. To identify and describe a business use case means to
identify and describe the class-like business use case, not the individual
use case instances.
An individual actor – The actor is probably the real key to finding the
correct business use case. Starting with individual actors—actually
instances of actors—helps avoid business use cases that are too
large or complex.

When determining suitable actors, first try to name at least two or three
different people who could perform as the actor in question, then
critically evaluate the support each individual requires. For example,
suppose you initially identify an actor called "customer." Later, as you
look deeper into the support each individual customer requires, you
might find three rather different customers: the normal "user" of the
product, the "purchaser" and the "evaluator," who are competent to
compare the product with its competitors. Each of these may require a
separate business use case, because they represent different roles that
can be played toward the business.
A result of observable value – This expression is very important in
determining the correct extent of a business use case, which should
be neither too small nor too big. Stating that the business use case
should give a result of observable value, that is, both perceived and
measurable, helps you to find a complete flow, and avoid business
use cases that are too small.
A good business use case helps an actor perform a task that has an
identifiable value. It may be possible to put a price on a successfully
performed business use case. A too-small business use case will have
a limited scope, thus also little re-engineering potential.
In a business – The words "actions performed in a business," mean
both that the business provides the business use case to the actor,
and that the business use case only covers what is actually done
within the business. Supporting work done elsewhere is not included.
Action – The actions are invoked either on request from an actor to
the business or at a certain point in time. Actions include internal
activities and decisions, as well as requests to either the invoked actor
or other actors.

Business services are described through different business use cases, each with a task of its own. The
collected set of business use cases constitutes all the possible ways of using the business.
Module 2 – Using the Unified Modeling Language 2 - ‹#›



The workflow of a business use case describes what needs to be done

by the business to provide the value the served business actor is
looking for. It consists of a sequence of activities that together produce
something for the business actor. The workflow often consists of a basic
flow, and one or several alternative flows. The structure of the workflow
can be described graphically with the help of an activity diagram.
An activity diagram is a special case of a statechart diagram in which all
or most of the states are activity states and in which all or most of the of
the transitions are triggered by completion of actions in the source
states.
Basic Activity Diagrams
An activity diagram can have the following elements:
• Activity states, which represent the performance of an activity or
step within the workflow.
• Transitions that show what activity state follows after another. This
type of transition can be referred to as a completion transition. It
differs from a transition in that it does not require an explicit trigger
event, it is triggered by the completion of the activity the activity
state represents.
• Decisions for which a set of guard conditions is defined. These
guard conditions control which transition of a set of alternative
transitions that follows once the activity has been completed. You
may also use the decision icon to show where the threads merge
again. Decisions and guard conditions allow you to show alternative
threads in the workflow of a business use case.
• Synchronization bars that you can use to show parallel subflows.
Synchronization bars allow you to show concurrent threads in the
Module 2 – Using the Unified Modeling Language 2 - 10

workflow of a business use case.






Business entities represent "things" handled or used by the business

workers as they execute a business use case. A business entity often
represents something of value to several business use cases or use-
case instances, so the business entity object is rather long-lived. In
general, it is good if the business entity holds no information about how
and by whom it is used.
Typically, a business entity represents a document or an essential part
of a product. Sometimes it represents something less tangible, like
important knowledge about a market or a customer. Examples of
business entities at the restaurant are Menu and Beverage; at the
airport, Ticket and Boarding Pass are important business entities.
You need to model as business entities only those phenomena that
other classes in the business object model must refer to. Other "things"
may be modeled as attributes of the relevant classes, or just described
textually in these classes.

Attributes
An attribute of a class represents a piece of information about an object
of the class that is kept with the object. An attribute has an attribute
type.
Each attribute and attribute type, respectively, has a name.
An object normally holds different pieces of information that describe
some of its characteristics. Such pieces of information can either be
described implicitly in the textual description of the object’s class, or
modeled explicitly as an attribute of the class.
An attribute is of a certain type. An attribute has a name, preferably a
noun that describes the attribute’s role in relation to the class. An
attribute type can be more or less primitive, starting from a simple
number or string. Different classes can have attributes with identical
structures. Those attributes should share a description; that is, they
should share attribute type.
Note: You should only model attributes to make a class more
understandable!
Responsibilities
An operation defines the tool with which a business entity is
manipulated. The access is initiated by a message. A tool that can be
used to manipulate a business entity object is represented as an
operation of the business entity class, with a name and, optionally,
parameters. The access of a business entity unit is shown as a
message being sent to the business entity object.
To perform its responsibilities, the person acting as a business worker
uses one or several tools to manipulate the business entities. You can
either define these tools generally, or explicitly, with the help of

operations and messages, representing the tools used and the accesses made.

Each operation is defined by a name, which should tell its purpose, and
optionally, a number of parameters. The parameters specify what an
object of the class should expect to receive from an object that is
requesting support or making an access, and what the object will
provide when the operation has been performed. As an example, you
can give parameters that reflect when a business worker should take a
step in the worker operation, or when he should access a certain
business entity by initiating one of the business entity’s operations.
Parameters can also represent more or less tangible things that are
handed over.
Operations can be defined informally, or in more detail, depending on
the importance or required level of detail in a use case. A "more
detailed" description might describe a behavior sequence that tells
which attributes and relationships are dealt with during its performance,
how objects of other classes are contacted, and how it is terminated.
Characteristics of a Good Business Entity
• Its name and description are clear and understandable.
• Business entity relationships do not depend on each other.
• Each relationship is used in the workflow of at least one business
use case.
• All "things" in the business, such as products, documents,
contracts, and so on, are modeled as business entities.
• It participates in at least one business use case.
• It has an owner; that is a business worker or business actor
responsible for the business entity.



A business worker represents an abstraction of a human that acts within

the business. A business worker object interacts with other business
worker objects and manipulates business entity objects in order to
realize a business use-case instance. We use worker individual as a
synonym for business worker object.
A worker is instantiated ("manned") when the workflow of its
corresponding use-case instance is started or, at the latest, just in time
for the person doing the job to play his role in the use-case instance. A
worker object often "lives" (the person is engaged) as long as the use
case executes.
Attributes
An attribute may be more or less tangible. For instance, you might
model as an attribute the information that a certain business worker
must keep in mind as he executes a business use case. Another
example of a potential attribute is a checklist that a business worker
should follow.
understandable!

Operations
An operation of a business worker class represents a specific activity to
be performed by an individual of that class. The operation of a business
worker is initiated by a message from another worker individual or from
an actor. An operation has a name and, optionally, parameters.
An operation describes a task a worker may be asked to perform. It is
initiated by a message. A business worker represents a role played by
an employee. To perform the job in a use case, the person acting as a
business worker performs one, or several activities.
When designing a business worker—that is, when defining what a
business worker must be able to do in order to produce the desired
results of a business use case—you have two alternatives. You can
either:
• Write a general textual description of the work, or
• Explicitly define each activity in the form of an operation, which in
turn should be described textually. For each operation, you define
what message initiates its execution.
handed over.


Characteristics of Good Business Workers
• Each business worker has an association to the business entities it
must know about.
• Each business worker has a link to the other business workers it
must communicate with.
• A business worker’s relationships do not depend on each other.
• Each business worker participates in at least one business use
case.
use case.
• Each of the business worker’s operations is performed in the
workflow of at least one business use case.

Attributes
An attribute may be more or less tangible. For instance, you might
model as an attribute the information that a certain business worker
must keep in mind as he executes a business use case. Another
example of a potential attribute is a checklist that a business worker
should follow.
understandable!

Responsibility
A Responsibility of a business worker class represents a specific activity
to be performed by an individual of that class. The operation of a
business worker is initiated by a message from another worker
individual or from an actor. An operation has a name and, optionally,
parameters.
An operation describes a task a worker may be asked to perform. It is
initiated by a message. A business worker represents a role played by
an employee. To perform the job in a use case, the person acting as a
business worker performs one, or several activities.
When designing a business worker—that is, when defining what a
business worker must be able to do in order to produce the desired
results of a business use case—you have two alternatives. You can
either:
• Write a general textual description of the work, or
• Explicitly define each activity in the form of an operation, which in
turn should be described textually. For each operation, you define
what message initiates its execution.
handed over.


Characteristics of Good Business Workers
• Each business worker has an association to the business entities it
must know about.
• Each business worker has a link to the other business workers it
must communicate with.
• A business worker’s relationships do not depend on each other.
• Each business worker participates in at least one business use
case.
use case.
• Each of the business worker’s operations is performed in the
workflow of at least one business use case.






An association represents structural relationships between instances of

business workers and business entities in the business object model. It
is information that must be preserved for some duration, and does not
simply show procedural dependency relationships. Each association
has a name and a multiplicity. The multiplicity defines how many objects
of the connected class can be connected. It is either a constant or a
range (e.g., 0..5) that shows the number of objects that can be
connected.
Example:
An agent who checks in airline passengers follows a set of instructions
that describe his activities in the check-in business use case. Each
employee acting as a check-in agent should know these procedures by
heart in order for the check-in use case to work smoothly. The business
worker class Check-in Agent should have an association to a business
entity class representing the set of instructions.

Sometimes a group of people act as a single unit in a use case, or,

more generally, a phenomenon is composed of other independent
phenomena. For example, School Class consists of Students. Such a
phenomenon is called an aggregate.
Aggregates are modeled with a separate class for the composite
phenomenon. Such classes have aggregations to the classes that
represent its constituents. This construction makes it possible to both
refer to the components individually and handle them as a single unit.
The uniting class does not necessarily have many properties of its own.
Its essential characteristic may very well be the aggregations of the
different components.
Example:
A company’s board of directors consists of the chairman, the chief
executive officer, and several owner representatives.

Many things in real life have common properties. For example, both
dogs and cats are animals. Classes can have common properties as
well. Relationships of this type between classes can be clarified by
means of a generalization. By extracting common properties into
classes of their own, the business model will be easier to change in the
future.
A class that inherits general characteristics from another class is called
a descendant. The class from which the descendant has inherited is
called the ancestor. A generalization shows that one class inherits from
another. This means that the definition of the ancestor, including any
attributes or operations, is also valid for the descendant. The ancestor’s
relationships are also inherited.
Generalization can take place in several stages, which makes it possible
to model complex, multi-leveled inheritance hierarchies, although the
number of levels should be restricted for easier understanding. General
properties are placed in the upper part of the inheritance hierarchy, and
special properties lower down in the hierarchy. In other words, the
generalization-relationship can be used to model specializations of a
more general concept.
Example:
Passengers arriving at the airport check-in bring different kinds of
baggage, Normal Baggage, Hand Baggage and Special Baggage. From
the airline's viewpoint, they have a few common properties, besides
being baggage—each bag has an owner and a weight, for example.
These common properties can be modeled by attributes and operations
in a separate class called Baggage. Normal Baggage, Hand Baggage
and Special Baggage will inherit from this class.






Usually a business is structured by organizing the employees in

departments, sections, groups and so on, according to various criteria.
This is modeled by placing the business workers and business entities
in organization units.
An organization unit is a construct for structuring a business by dividing
it into smaller parts. Organization units can contain not only business
workers and business entities, but also other organization units, which
allow you to build a hierarchy of organization units. A business worker or
business entity can only be a direct member of one organization unit.

A business use-case model describes a business in terms of business

actors and business use cases corresponding to customers and
business processes. The business use-case model includes workflow
descriptions that identify what is done. How the work is performed in
each business use case is described in the business object model.
A set of worker individuals who perform the work of a business use
case, together with the business objects they access and manipulate as
part of the job, is called the business use-case realization. Objects of
the same class can participate in several different business use-case
realizations, reflecting that the same kind of resource from one time to
another works in different processes.


Using Activity Diagrams

The first choice to document the realization of a business use case is to
draw an activity diagram, where swimlanes (or partitions) represent the
participating business workers. For each business use-case realization,
there may be one or more activity diagrams to illustrate the workflow. A
common way to organize is to have one overview diagram without
swimlanes that cover the whole workflow, and where you show "macro
activity" that are at a high level. Then, for each such macro activity,
there is a more detailed activity diagram that shows the swimlanes and
the activities at the business worker level. For readability reasons, a
goal should be that each diagram fit on a page.
Using Collaboration and Sequence Diagrams
For each business use-case realization, there can be one or more
interaction diagrams depicting its participating business workers and
business entities, and their interactions. There are two types of
interaction diagrams: Sequence diagrams and collaboration diagrams.
They express similar information, but show it in different ways:
• Sequence diagrams show an explicit sequence of events and are
better than activity diagrams for more complex scenarios.
• Collaboration diagrams show the communication links and
messages between objects and are better for understanding all of
the effects on a given object.
• If alternative flows are few, but there are many business entities
involved, interaction diagrams are often a better choice than the
activity diagram to show the realization of the workflow.
Using Class Diagrams
For each business use-case realization, there may be one or more class
diagrams depicting its participating business workers and business

entities. A diagram of this kind can be a useful help when coordinating all the requirements on a
business worker or business entity that participates in several business use-case realizations.







The approach to Business Modeling presented in the Rational Unified

Process includes a concise and straightforward way to generate
requirements on supporting information systems. A good understanding
of business processes is important to be able to build the right systems.
Even more value is added if you also use people's roles and
responsibilities, as well as definitions of what "things" are handled by the
business as a basis for building the system. It is from this more internal
view of the business (captured in a business object model) that you can
see the tightest link to what the models of the system should look like.


There are three main reasons for structuring the business use-case
model:
• To make the business use cases easier to understand.
• To reuse parts of workflows that are shared among many business
use cases.
• To make the business use-case model easier to maintain.
To structure the business use cases, we have three kinds of
relationships. You will use these relationships to factor out pieces of
business use cases that can be reused in other business use cases, or
that are specializations or options to the business use case. The
business use case that represents the modification we call the addition
use case. The business use case that is modified we call the base use
case.

If there is a part of a base use case that represents a function of which

the business use case only depends on the result, not the method used
to produce the result, you can factor that part out to an addition use
case. The addition is explicitly included in the base use case, using the
include-relationship.
If there is a part of a base use case that is optional, or not necessary to
understand the primary purpose of the use case, you can factor that part
out to an addition use case in order to simplify the structure of the base
use case. The addition is implicitly included in the base use case, using
the extend-relationship.
If there are business use cases that have commonalities in behavior and
structure and that have similarities in purpose, their common parts can
be factored out to a base use case (parent) that is inherited by addition
use cases (children). The child use cases can insert new behavior and
modify existing behavior in the structure they inherit from the parent use
case.




Modulo 02 - BMUMLv2001 - 04 - 00 (Compatibility Mode) PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Modulo 02 - BMUMLv2001 - 04 - 00 (Compatibility Mode) PDF

Загружено:

Авторское право:

Доступные форматы

Business Modeling with the UML

Module 2 – Using the Unified Modeling Language 2-1

Module 2 – Using the Unified Modeling Language 2-2

Module 2 – Using the Unified Modeling Language 2-3

Module 2 – Using the Unified Modeling Language 2-4

Module 2 – Using the Unified Modeling Language 2-5

Business Use Case:

Module 2 – Using the Unified Modeling Language 2-6

Module 2 – Using the Unified Modeling Language 2-7

Module 2 – Using the Unified Modeling Language 2 - ‹#›

Module 2 – Using the Unified Modeling Language 2-8

Module 2 – Using the Unified Modeling Language 2-9

The workflow of a business use case describes what needs to be done

Module 2 – Using the Unified Modeling Language 2 - 10

Module 2 – Using the Unified Modeling Language 2 - ‹#›

Module 2 – Using the Unified Modeling Language 2 - 11

Module 2 – Using the Unified Modeling Language 2 - 12

Module 2 – Using the Unified Modeling Language 2 - 13

Module 2 – Using the Unified Modeling Language 2 - 14

Module 2 – Using the Unified Modeling Language 2 - 15

Business entities represent "things" handled or used by the business

Module 2 – Using the Unified Modeling Language 2 - 16

Module 2 – Using the Unified Modeling Language 2 - 17

Module 2 – Using the Unified Modeling Language 2 - ‹#›

Module 2 – Using the Unified Modeling Language 2 - 18

Module 2 – Using the Unified Modeling Language 2 - 19

Module 2 – Using the Unified Modeling Language 2 - 20

A business worker represents an abstraction of a human that acts within

Module 2 – Using the Unified Modeling Language 2 - 21

Module 2 – Using the Unified Modeling Language 2 - 22

Operations can be defined informally, or in more detail, depending on

Module 2 – Using the Unified Modeling Language 2 - 23

Module 2 – Using the Unified Modeling Language 2 - 24

Module 2 – Using the Unified Modeling Language 2 - 25

Operations can be defined informally, or in more detail, depending on

Module 2 – Using the Unified Modeling Language 2 - 26

Module 2 – Using the Unified Modeling Language 2 - 27

Module 2 – Using the Unified Modeling Language 2 - 28

Module 2 – Using the Unified Modeling Language 2 - 29

Module 2 – Using the Unified Modeling Language 2 - 30

Module 2 – Using the Unified Modeling Language 2 - 31

An association represents structural relationships between instances of

Module 2 – Using the Unified Modeling Language 2 - 32

Sometimes a group of people act as a single unit in a use case, or,

Module 2 – Using the Unified Modeling Language 2 - 33

Module 2 – Using the Unified Modeling Language 2 - 34

Module 2 – Using the Unified Modeling Language 2 - 35

Module 2 – Using the Unified Modeling Language 2 - 36

Module 2 – Using the Unified Modeling Language 2 - 37

Module 2 – Using the Unified Modeling Language 2 - 38

Module 2 – Using the Unified Modeling Language 2 - 39

Usually a business is structured by organizing the employees in

Module 2 – Using the Unified Modeling Language 2 - 40

A business use-case model describes a business in terms of business

Module 2 – Using the Unified Modeling Language 2 - 41

Module 2 – Using the Unified Modeling Language 2 - 42

Using Activity Diagrams

Module 2 – Using the Unified Modeling Language 2 - 43

Module 2 – Using the Unified Modeling Language 2 - ‹#›

Module 2 – Using the Unified Modeling Language 2 - 44

Module 2 – Using the Unified Modeling Language 2 - 45

Module 2 – Using the Unified Modeling Language 2 - 46

Module 2 – Using the Unified Modeling Language 2 - 47