Chapter 4:Object Oriented Analysis

4.1 System Use case modeling

•A system use case model is composed of a use case diagram and
the accompanying documentation describing the use cases,
actors, and associations.
•The main difference between an essential use case and a system
use case is that in the system use case you include high-level
implementation decisions (e.g specific user- interface
components—such as screens, HTML pages, or reports).
•Because your use cases refer to user-interface components, and
because your user interface is worked on during design,
inevitably design issues will creep into your use cases.
•Because your user interface will work differently depending on
the implementation technology, the logic of your system use
cases, which reflect the flow of your user interface, will also be
affected.
Essential Use Case
System use case for the previous essential use case
There are several interesting changes.
 First, deployment decisions are now reflected in the diagram.
For example, you see that the post office is used to distribute
information to students. You also see that student marks are
input, instead of "recorded," implying the use of computer
technology. Similarly teaching schedules are printed now
instead of produced. Subtle differences, yet important ones.
 Relationships between some use cases have been introduced.

4.1.1 Writing System Use cases

 Writing system use cases is straightforward. If you have
created essential use cases then you can simply evolve them
into system use cases.
 Often an essential use case will evolve into several system
use cases. A system use case considers technical
considerations, such as usage issues resulting from user-
interface choices that you make.
ctor Administrator
re- condition: The user should be member of the school
1) The administrator selects create account link.
2) The system displays create account page.
asic courses of action
3) The administrator fills the required information and submit
4) The system validates the information.
5) The system registers the users into the system.
6) The use case ends.
ost- condition The account is successfully created.
lternative course of action A. Invalid information entry.
1. Go to step 2 to fill again.

Sections of System use case description

 Let us start by considering the types of use cases that you
will write as part of your initial requirements gathering
efforts during cycle 0 of your projects.
 The steps are written in very brief, bullet/point-form style.
They contain just enough information to get the idea across
and no more.
 It also takes technology issues into account; for example, the
text "Student inputs her name and address" implies some sort
of information system. The reference to the system also
implies the same. The next figure presents an alternate
version of the use case, this time as a manual process
involving a registrar (a person) instead of an automated
system. Choosing a manual process over a software-based
one is still a technical architecture decision, in this case a
low-tech architectural decision. The differences between the
two versions illuminates how system use cases are analysis
and arguably even design artifacts, not requirements artifacts.
Informal version of enroll in seminar use case
Informal version of the Enroll in Seminar use case for a manual System
 Manual Processes Are Not Out of Scope  It is perfectly fine
to have manual steps in use cases, such as working with paper
forms in the use case that follows, and some use cases are
completely manual as you saw above.
 This happens in the real world, some things are manual and
some are automated; therefore your use cases should reflect
this. The manual parts may be automated at some point in the
future and the automated parts may similarly be "manualized,"
all in the name of process improvement.
 It is important to realize that you still have significant
implementation issues surrounding manual processes. In this
case someone must define requirements for the form(s).
Someone must analyze and design the forms. Someone must
implement the forms. Someone must test how well those forms
work. Some must configure and change manage the form over
time. Someone must deploy the forms to their users. There is
more to development than just the creation of software.
 This version is much more detailed than the corresponding
use case, and is typical of the type of use cases that people
will write in documentation-intense environments. Frankly,
use cases like this are overkill for many projects yet many
project teams are required to write them in this manner (or
something similar) because senior management is convinced
that they require this level of documentation. My advice is to
keep your models as simple as possible and only document
them thoroughly if it adds actual value.
 It also includes alternate courses of action, i.e., infrequently
used path of logic in a use case.
 Sequence diagram
A sequence diagram is an interaction diagram that
details how operations are carried out: what
messages are sent and when. Sequence diagrams are
organized according to time. The time progresses as
you go down the page. The objects involved in the
operation are listed from left to right according to
when they take part in the message sequence.
example
Activity diagram
Activity diagrams are used to show how
different workflows in the system are
constructed, how they start and the possibly
many decision paths that can be taken from
start to finish. They may also illustrate
where parallel processing may occur in the
execution of some activities. Activity
diagram for login, add information, view
information, student registrations are shown
by the following diagram.
Activity diagram for login

Ope n the syste m

Syste m a sks use r

na me a nd pa ssw ord

Use r e nte r its use r

na me a nd pa ssw ord

Inva lid che ck va lidity

Va lid

Acce ss the pa ge
 Class diagrams

Class diagrams in the

Unified Modeling Language (UML) is a type
of static structure diagram that describes the
structure of a system by showing the system's
classes, their attributes, operations (or
methods), and the relationships among the
classes.
Cont….
 A Class Diagram is a diagram describing
the structure of a system
shows the system's
 classes
 Attributes
 operations (or methods),
 Relationships among the classes.
class
 Describes a set of objects having similar: –
Attributes (status)
– Operations (behavior)
– Relationships with other classes
• Attributes and operations may
– have their visibility marked:
– "+" for public
– "#" for protected
– "−" for private
– "~" for package
Representation of class
Class is represented with boxes which
contain three parts:
 Name
 Attributes
 Operations
Cont…

NAME: The top part contains the name of

the class. It is printed in Bold, centered
and the first letter capitalized.
ATTRIBUTES: The middle part contains
the attributes of the class. They are left
aligned and the first letter is lower case.
OPERATIONS: The bottom part gives the
methods or operations the class can take
or undertake. They are also left aligned
and the first letter is lower case.
example
Account_Name
Account_Name
 Customer Name
-Customer Name
- Balance +add Funds( )
- Balance
 +with Draw( )
+add Funds( )
+transfer(
+with Draw( )
+transfer( )
)
relationships
There are two kinds of Relationships
 Generalization (parent-child
relationship)
 Association (student enrolls in course)
Associations can be further classified as
 Aggregation
 Composition
Cont…
Generalization
 Generalization expresses a parent/child
relationship among related classes.
 Used for abstracting details in several
layers
Cont…
Association represent relationships
between instances of classes . An
association is a link connecting two
classes.
Bi-directional association Associations
are assumed to be bi-directional e.g.
Flight and plane notation:
Uni-directional association e.g. Order and
item notation:
Cont…
Composition
Composition: expresses a relationship
among instances of related classes. It is a
specific kind of Whole-Part relationship
 It expresses a relationship where an
instance of the Whole-class has the
responsibility to create and initialize
instances of each Part-class