Chapter 5

Determining what to Build:

Object Oriented Analysis

1
 5.1 System use Case Modeling
•During Analysis ,Your main goal is to evolve
your essential use case into system use cases
•What is the difference between essential use case
and system use case ?
•In systems use case you include high level
implementation details. For example, a system
use case refers to a specific user interface
components. Such as screens ,HTML pages or
report which you would not do in essential use
case.
2
•During analysis , you make decisions
regarding what will be built.

•A system use case model is composed of a

use case diagram and accompanying
documentation describing the use cases,
actors and associations .

3
 5.1.1 Writing system use cases

• Begin with essential use cases and modify them to

reflect the information captured with UML sequence
diagrams, UML activity diagrams ,user interface
prototype and the contents of supplementary
specification.

• Rework your use cases to reflect opportunities for

reuse by applying UML stereo types of <<include >>
and <<extend>> and as well as the OO inheritance
concepts.

4
There are two ways of writing system use cases
Narrative style
Action response Style

5
• An extend association, formerly called an
extends relationship in UML v1.2 and earlier,
is a generalization relationship where an
extending use case continues the behavior of a
base use case.

• The extending use case accomplishes this by

conceptually inserting additional action
sequences into the base use case sequence.

6
• When the appropriate extension point is reached in
the base use case and the extension condition is
fulfilled.

• When the extending use case activity sequence is

completed, the base use case continues.

• Extension points are placed in base use cases to

indicate where the logic of the extending use case
replaces that of the base use case.

7
• The extension point should be documented with in
the use case.
• E. g . 4. The system displays “UI 43 student
information entry”[Extension point :UC 34 Enroll
international student in University.]

8
• you see that the use case "Enroll International
Student in University" extends the use case
"Enroll in University", the notation for doing so is
simply a normal use case association with the
stereotype of <<extend>>. In this case "Enroll in
University" is the base use case and "Enroll
International Student in University" is the
extending use case.

9
• A second way to indicate potential reuse within use
case models exists in the form of include
associations.

• An include association, is a generalization

relationship denoting the inclusion of the behavior
described by another use case.

• The best way to think of an include association is

that it is the invocation of a use case by another one.

10
 Example in the figure above

• "Enroll in University" includes the use case "Enroll

in Seminar", the notation for doing so is simply a
normal use case association with the stereotype of
<<include>>.
• Use cases can inherit from other use cases, offering a
third opportunity to indicate potential reuse.

• Example in the figure: "Enroll Family Member in

University" inherits from the "Enroll In University"
use case

11
• Inheritance between use cases is not as
common as either the use of extend or
include associations but it is still possible.
The inheriting use case would completely
replace one or more of the courses of
action of the inherited use case.

12
 5.2 Sequence Diagrams

•Sequence diagrams are used to model the logic of

usage scenario , enable you to visually model the
logic of the system .
•Usage Scenario is the description of the potential
way the system is used.
•The logic of the usage scenario may be part of a
use case. Perhaps an alternate course.
•It may also be one entire pass through a use
case ,such as a logic described by the basic course
of action or portion of the basic course of action
plus one or more alternate scenarios
13
• It may also be a pass through a logic contained in
several use cases .
Example : a student enrolled in a university and then
enrolled in three seminars
• Objects ,classes and actors are depicted in sequence
diagrams.

14
• The boxes across the top of the diagram represent
classifiers or their instances, typically use cases,
objects, classes, or actors.

• Because you can send messages to both objects and

classes, objects respond to messages through the
invocation of an operation and classes do so through
the invocation of static operations, it makes sense to
include both on sequence diagrams.
• Sequence diagram Enroll in a seminar

15
•Because actors initiate and take an active
part in usage scenarios, they can also be
included in sequence diagrams.

•Objects have labels in the standard UML

format name: ClassName, where “name”
is optional (objects that haven’t been given
a name on the diagram are called
anonymous objects).

16
•Classes have labels in the format ClassName,
and actors have names in the format Actor
Name. Notice how object labels are underlined,
classes and actors are not .

17
•The instance of Student was given a
name because it is used in several places
as a parameter in messages, whereas the
instance of the Seminar didn’t need to be
referenced anywhere else in the diagram
and thus could be anonymous.

18
•Messages are indicated on UML sequence
diagrams as labeled arrows, when the
source and target of a message is an object
or class the label is the signature of the
method invoked in response to the message.

•Signature-The combination of the name ,

parameter names (in order) and the name
of the return value (if any ) of a method.

19
•However, if either the source or target is a human
actor, then the message is labeled with brief text
describing the information being communicated.
•F o r e x a m p l e , i n t h e f i g u re a b o v e t h e
EnrollInSeminar object sends the message
isEligibleToEnroll(theStudent) to the instance of
Seminar

20
•both the method’s name and the name of the
parameters are included , if any, passed into it.
•The Student actor provides information to the
SecurityLogon object via the messages
labeled name and student number (these really
aren’t messages, they are actually user
interactions).

21
•Return values are optionally indicated using a
dashed arrow with a label indicating the return
value.
• For example, the return value theStudent is
indicated coming back from the Student class as
the result of invoking a message, whereas no
return value is indicated as the result of sending
the message isEligibleToEnroll(theStudent) to
Seminar.

22
•No need to indicate the return values
when it’s obvious what is being returned
•Which avoids cluttering of the diagram
•an alternate way to indicate return values
using the format message: returnValue for
m e s s a g e s , a s y o u w i t h
isEligibleToEnroll(theStudent): false.

23
•Notice the use of stereotypes throughout the
diagram. For the boxes, the stereotypes
<<actor>>, <<controller>>, and <<UI>>
indicating they represent an actor, a controller
class, or a user interface (UI) class,
respectively.
•A controller class in the analysis phase is a
place holder for one or more classes that
would be flashed out during the design to
implement the business logic of the system.

24
• Another common practice on UML diagrams is to
indicate creation and destruction messages with
the stereotypes of <<create>> and <<destroy>>,
respectively
• For example, you see the SecurityLogon object is
created in this manner (actually, this message
would likely be sent to the class that would then
result in a return value of the created object, This
object later destroys itself in a similar manner,
most probably when the window is closed.

25
 How to draw sequence diagrams

1. Identify the scope of the sequence diagram (is it

the basic course of action? The alternate course
of actions?)
2. List the use case steps down the left hand side.
3. Introduce boxes for each actor across the top of
the diagram.
4. Introduce controller class(es) whose purpose is
to mediate the logic described by the use case
steps.(one of the layers in the design phase)

26
5. Introduce a box for each major UI elements. make them
with a stereo type<<UI>>
6. Introduce a box for each included use case. make them with
a stereo type <<use case>>.and give them a name in the
format “id:use case name” e.g. (UC17:Enroll in seminar)
7. Identify appropriate message for each use case step.
8. Add a method invocation box for each invocation of a
method. Every time an object or class receives a message a
method is invoked. To represent it you should include a
message invocation box.

27
9. Add distraction messages when appropriate. At the
end of a method invocation, the target object may
be destroyed. This is common for transitory objects
such as UI elements and for business objects
deleted as a result of an operation.
Transitory Object -An object that is not saved in
permanent storage.
10. Add business classes and objects. As you identify
messages you also need to identify targets to those
messages, targets that will inevitably be classes or
objects. The classes should be in your conceptual
model. If not on the conceptual model add them to
the conceptual model.

28
11. Update the class model. As you are sequence
diagramming ,you will identify new responsibilities
for the classes and objects. some times ,even for
new classes
12. Update the user interface model.
13. Update the use case model. As you sequence
diagramming ,you may find errors in your original
use case logic. You need to fix those errors both
your sequence diagram and in use cases. Do with
the SMEs

29
Conceptual modeling :Class Models (UML)
•Class models are the basis of object-oriented
analysis and design, and before the UML most
methodologies called them object models
instead of class models.
•Class models show the classes of the system,
their inter-relationships (including inheritance,
aggregation, and association), and the
operations and attributes of the classes.

30
31
• The figure above shows a design class model which provides examples of a
wider range of the notation that you may use in a UML class model.

32
Modeling Associations
• Objects are often associated with ,or related to ,other
objects
• E.g. Academic staff teaches subject
• Identifying the multiplicities of an association is an
important part of modeling team.
• Model a role when an association is recursive or when
several associations exist between two classes.
• Association: a relationship among instances of object
classes
• Association role: the end of an association where it
connects to a class
• Multiplicity: indicates how many objects participate in a
give relationship

33
Modeling dependencies
• Collaborations from a user interface class implies a
dependency where as a collaborations from
business/domain classes imply either association or
aggregation between the classes.

• A dependency relationship exists between class A and

Class B when instances of class A interact with
instance of class B. Dependency relationships are used
when no direct relationship (inheritance ,aggregation
or association ) exists between the two classes.

34
35
Introducing Reuse between classes via
inheritance
• Similarities often exist between different classes
• Very often two or more classes share the same
attribute and/or methods
• You do not want to have to write the same code
repeatedly.
• The mechanism is to use inheritance
• Inheritance models “is a” or “ is like “ relationship.

36
E.g. in the above figure
• Student is UniversityMember
• AcademicStaff is UniversityMember

37
 Modeling Aggregation Associations

• Some times an object is made up of other objects.

•E . g . a n a i r p l a n e i s m a d e u p o f f u s e l a g e ,
wings ,engines ,landing gear, flaps and so on
• A team consists of two or more employees
• A delivery shipment constrains one or more packages

38
 Activity diagramming (UML)
•U s e d t o d o c u m e n t t h e l o g i c o f a s i n g l e
operation/method, use case or the flow of logic of a
business process.
• Activity diagram is the object oriented equivalent of
flow charts and data follow diagrams (DFDs) from the
structured development.
• The following figure depicts the business logic for
how some one new to the university would enroll for
the first time.

39
40
• The filled circle represents the starting point of the
activity diagram.
• The filled circle with a border represents the ending
point.
• The rounded rectangle represents processes or
activities that are performed.
• Activities are much more fined grained particularly
when representing the logic of a method.

41
• The diamond represents decision points.
• Arrows represent transitions between activities
–modeling the flow order between different activities .
• The text on the arrows represent conditions that must
be fulfilled to proceed along the transition.
Represented by the format “[condition]”

42
How to draw activity diagram
1. Identify the scope of activity diagram. is it a
single use case? A business process that includes
several use cases? A single method of a class ?
• Once you identify the scope the diagram ,add a label
at the top, using a note, indicating an appropriate title
for the diagram
2. Add Start and end points.
3. Add activities
• Introduce an activity for each major step initiated by an actor.
4. Add transitions from the activities
• When ever there is more than one transition add appropriate label
5. Identify opportunities for parallel processing
• Two activities can occur in parallel when no direct relationship
between them.
• They must both occur before the third activity occurs

43
 User interface prototyping
• User interface (UI) prototyping is an iterative
analysis technique in which users are actively
involved in the mocking-up of the UI for a
system.
• UI prototyping has two purposes:
• First, it is an analysis technique because it enables you
to explore the problem space that your system
addresses.
• Second, UI prototyping enables you to explore the
solution space of your system, at least from the point
of view of its users, and provides a vehicle for you to
communicate the possible UI design(s) of your system.

44
Initial user interface prototype for a
university system

45
• As you see in the activity diagram depicted in
figure below, there are four high-level steps to the
UI prototyping process.
1. Determine the needs of your users
2. Build the prototype
3. Evaluate the prototype
4. Determine if you are finished

46
47
48
User interface prototyping Evolving your
supplementary specification

• The actual usage of the software very much depends on

the quality (usability and ergonomics) of its user
interface (UI), which provides user’s input usually
by keyboard, mouse or by touch screen.

• Because users’ experience, knowledge and skills to learn

how to use the system are never the same, many
contextual factors must be included in order to plan and
develop appropriate usability characteristics.

49
• Therefore, it is not a straightforward task to design a
good UI, which should fulfil eight domain-independent
properties such as: clear, concise, familiar, responsive,
consistent, attractive, efficient and forgiving.
• Otherwise, poorly designed UI can lead to difficult
interaction, user frustration and poor work performance.
• The significance of prototyping in the user interface
development process should be highlighted for the
following reasons:

• UI prototype is an operational model of developed

system, which shows not only interaction between a user
and a system, but also exposes some subset of its
functionality;
50
• UI prototype is a solid foundation for discussion
between project stakeholders (designers and users),
giving opportunities to learn more about product
features and design.
• UI prototype usability testing enables to thoroughly
validate user formal requirements and informal
expectations in regard to developed system .

• User interface prototyping is a testing and evaluation

approach which is a crucial component of User-Centred
Design (UCD) methodology, widely used in IT projects
since the 1990s.

51
Applying Analysis patterns Effectively

• Analysis patterns support the creation of the conceptual

model of an application. An analysis pattern provides a
re-usable, well-proven model representation of a
recurrent sub-problem.
• Thus, analysis patterns facilitate the proper
transformation of a concrete problem into an analysis
model.

52
• Analysis patterns can be classified into domain-specific and domain-independent
patterns. Domain specific patterns provide model fragments of sub-problems that
occur in a specific domain,

• for example, insurance companies, energy suppliers etc. Domain-independent

(or domain-less) analysis patterns are not limited to one domain; instead, they
model problems that are cross-domain.

53
User documentation
• Technical documentation refers to the documentation
that describes how a product or service operates.
• For example, software code documentation, technical
s p e c i f i ca t i o n s a n d A P I d o c u m e n ta t i o n . Te c h n i ca l
documentation can also describe how to install software.

• User documentation refers to the documentation for a

product or service provided to the end users. The user
documentation is designed to assist end users to use the
product or service. This is often referred to as user
assistance. The user documentation is a part of the
overall product delivered to the customer.

54
Organizing your models with packages
• Packages are used to organize the elements of a model
just as folders are used to organize files.
• The contents of a package are any kind of element that
is part of a model, including other packages.
• Since they are a general grouping thing, it is up to usage
scenarios to suggest what the best practices are for using
packages.
• First and foremost, use packages to organize your model,
regardless of the model purpose.
•Second, use the package diagram to provide
visualizations of that organization.

55
Thank You!

56