CH- 3 Object Oriented Analysis

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 53

OOSAD

Chapter Three

Object Oriented Analysis


Introduction to OO Analysis

• Your requirements model, although affective for


understanding what your users want to have built, is not as
effective at understanding what will be built.

• Requirements engineering focuses on understanding users


and their usage, whereas analysis focuses on understanding
what needs to be built.

• Object-oriented analysis techniques are used to bridge the


gap between requirements and system design.

Unity University 2
Cont.
Analysis Artifacts and their relationships
Essential Use
CaseModel UseCase
Model
Business
Rules
Sequence
CRCModel Diagram

Activity
User Interface Diagram
Flow Diagram
ClassModel

EssentialUser
Interface
Prototype User Interface
Prototype
Unity University 3
System Use Case Modeling

• 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.

• A system use case model is composed of a use case diagram


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

Unity University 4
Cont.

• Use Case describes a sequence of actions that provide a


measurable value to an actor and is drawn as a horizontal ellipse

• An actor is a person, organization or external system that plays a


role in one or more interactions with your systems
• Drawn as stick figures

• Associations between actors and classes are indicated in use case


diagrams, a relationship exists whenever an actor is involved with
an interaction described by a use case
• Depicted as a line (arrows are optional)

Unity University 5
Cont.

• Writing system use cases is straightforward.

• If you have created essential use cases then you can simply evolve
them into system use cases.

• A system use case considers technical considerations, such as


usage issues resulting from user-interface choices that you make.

• For example, a system use case refers to specific user- interface


components—such as screens, HTML pages, or reports—
something you would not do in an essential use case.

Unity University 6
Cont.
Reuse in Use case models
• One of your goals during analysis is to identify potential
opportunities for reuse;

• Potential reuse can be modeled through four generalization


relationships supported by UML use case models:
extend relationships between use cases,
include relationships between use cases,
inheritance between use cases,
and inheritance between actors.

Unity University 7
Cont.
Extend Associations between use cases

• The <<extend>> stereotype is used to indicate an extend


association

• It is a generalization relationship where an extending use


case continues the behavior of a base use case

• Accomplishes this by conceptually inserting


Additional action sequences into the base use case
sequence
Alternate course of the base use case

Unity University 8
Cont.
Extend Associations between use cases

• Introduce an extending use case when


The logic for the alternate course of action is at a
complexity level similar to that of the basic course of
action
There is a need for an alternative course for an
alternative course of action

Unity University 9
Cont.

Include Associations between use cases

• Denoted by the <<include>> stereotype

• Generalization relationship denoting the inclusion of the behavior


described by another use case

• Invocation of a use case by another one

• Used when a use case needs the behavior of another

Unity University 10
Cont.

Unity University 11
Cont.

Unity University 12
Use Case Documentation (Use Case Description) Cont.
• When you document your use case, the following sections are
included:

Unity University 13
• There are two Cont.
common styles
exist for writing use
cases:

1. Narrative Style –
it is used to write the
basic and alternative
courses of action one
step at a time.

Unity University 14
Narrative Style Cont.

Unity University 15
Cont.

• There are two common styles exist for writing use cases:

2. Action-Response Style – it is used to present use case steps in


columns, one column for each actor and a second column for the
system.

The advantage of the action-response style is, it is easier to see


how actors interact with the system and how the system
responds.

The disadvantage is, it is little harder to understand the flow of


logic of the use case.

Unity University 16
Action-Response
Style Cont.

Unity University 17
Cont.
Use Case Modeling Tips and Techniques
Association between actors and use cases imply the need for
interfaces

You should be able to exit from a use case anytime

Write from the point of view of the actor in the active voice

Write scenario text, not functional requirements

Organize your use case diagrams consistently

Don’t forget the system response to the actions of actors

Alternate courses of action are important

Don’t get hung up on <<include>> and <<extend>> associations

Unity University 18
Sequence Diagrams
• It is an interaction diagram that shows how the objects and classes
involved in the scenario operate with one another and the
sequence of messages exchanged.

• It is used to model the logic of usage scenarios.

• A usage scenario is exactly what its name indicates – the


description of a potential way your system is used.

• The logic of a usage scenario may be part of a use case.

• It may also be one entire pass through a use case or the logic
contained in several use cases

Unity University 19
Cont.

• 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.

• Because actors initiate and take an active part in usage


Unity University 20
scenarios, they are also included in sequence diagrams.
Notations in sequence diagrams Cont.
• Objects – format – “Object name: Classname”

• Classes – format –“ClassName”

• Actors – format – “ActorName”, <<actor>>

• User Interface elements - <<UI>>

• Dashed lines – object lifelines

• Long thin boxes – method invocation boxes indicating that


processing is being performed by the target object/class to fulfill a
message

• X at the bottom of a method invocation box – object have been


Unity University 21
removed
Notations in sequence diagrams Cont.
• Messages – 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

 If either the source or target is a human actor, then the


message is labeled with brief text describing the
information being communicated

 Return values are optionally indicated as using a dashed


arrow with a label indicating the return value
Unity University 22
How to draw sequence diagrams Cont.

Unity University 23
How to draw sequence diagrams Cont.

Unity University 24
How to draw sequence diagrams Cont.

Unity University 25
Alternate course of action Cont.

Unity University 26
A way to indicate looping logic Cont.

Unity University 27
How to draw sequence diagrams Cont.
 Identify the scope of the sequence diagram

 List the use case steps down the left hand side

 Introduce boxes for each actor

 Introduce a box for each major UI element

 Introduce a box for each included use case

 Identify appropriate messages for each use case step

 Add a method – invocation box for each invocation of a


method

Unity University 28
How to draw sequence diagrams Cont.
 Add destruction messages where appropriate

 Add your business classes and objects

 Update your class model

 Update your user interface model

 Update your use case model

Unity University 29
Cont.
Why and When should you draw sequence diagrams

 Sequence diagrams are a great ways to validate and flesh


out your logic

 Great mechanism for detecting bottle necks in your


design.

 Gives a feel for, which classes in your application are


going to be complex

Unity University 30
Conceptual Modeling using class Diagrams
• Class models are the mainstay of the OO analysis and design.
• Class models show the classes of the system, their
interrelationships (including inheritance, aggregation, and
association) and the operations and attributes of the classes.
• The conceptual models are used to depict your detailed
understanding of the problem space and solution for your system.
• The easiest way to begin conceptual modeling is to convert the
CRC (as a base) directly to UML class diagram.
• While a CRC model provides an excellent overview of a system, it
doesn‘t provide the details needed to actually build it.

Unity University 31
Cont.
• The CRC model for the University represented here below:

Unity University 32
Cont.
• The collaborators on the CRC cards indicate the need for an
association, aggregation, or dependency between classes.

• Dependencies are modeled between UI classes and the


business classes with which they collaborate because UI
classes are transitory in nature, implying the associations
they are involved with are transitory.

Unity University 33
Cont.
• The corresponding class model of the CRC model:

Unity University 34
Cont.
• To create and evolve a class model, you need to model:
Classes
Methods or operations
Attributes
Associations
Dependencies

Unity University 35
Cont.
Modeling Classes, Methods and Attributes

• Representation of an object, template of which objects are


created Name
Attribute
• Modeled as rectangle with three sections
Method
• Model your classes to an appropriate level of detail

Eg. Take out address as a class

Unity University 36
Cont.
Modeling Classes, Methods and Attributes

• Class normalization – refactoring the behavior of classes to


increase their cohesion and/or to reduce the coupling between
classes

Unity University 37
Cont.
Modeling Associations

• Objects are often associated with other objects

• Modeled as lines connecting the two classes whose instances


are involved in the relationship

• Identifying the multiplicities of an associations is an


important part of modeling it

Unity University 38
Modeling Associations Cont.
• Indicate the direction in which the label should be read

When it is not clear which way a label should be read


This is depicted using a filled triangle, called a direction indicator

• Roles may also be indicated only when the information adds value
• It is not clear from the association label what the roles are
• If there is recursive association
• If there are several associations between two classes

Unity University 39
Cont.
Modeling Dependencies

• Are used to model transitory associations


When one of the two classes is not persistent

• UI classes

• Use Dashed arrow

• Transitory classes are not three sectioned boxes

• Only indicate name of the class

Seminar
EnrollInSeminar

Unity University 40
• the concrete classes that made class diagrams: Cont.

Unity University 41
Activity Diagrams

• Activity diagrams are used to document the logic of


• a single operation/ method
• a single use case
• the flow of logic of a business process

• it is the object-oriented equivalent of flow charts and data-


flow diagrams (DFD) from structured development.

Unity University 42
Cont.
The filled circle represents the starting point of the activity diagram

The filled circle with a border represents the ending point.

The rounded rectangles represent processes or activities that are


performed.

The diamond represents decision points.

The arrows represent transitions between activities

The text on the arrows represent conditions that must be fulfilled to


proceed along the transition and are always described using the
format [condition]

The thick bars represent the start and end of potentially parallel
processes Unity University 43
Cont.

Unity University 44
Cont.

Unity University 45
How to draw Activity Diagrams Cont.
• Identify the scope of the activity diagram.
• Is it a single use case? A portion of a use case? A business process that includes
several use-cases? A single method of a class?

• Add start and end points.


• Every activity diagram has one starting point and one ending point, so you
might as well add them right way.

• Add activities.

• Add transitions from the activities.


• It is always mandatory to exit from the activity, even if it is simply to an ending
point

• Whenever there is more than one transition out of an activity, you must label
Unity University 46
each transition appropriately.
Cont.
How to draw Activity Diagrams

• Add decision points.


• Sometimes the logic of what you are modeling calls for a decision to be made.

• Identify opportunities for parallel activities.


• Two activities can occur in parallel when no direct r/ship exists between them
and they must both occur before a third activity can.

Unity University 47
User Interface Prototyping

• It 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:


It is an analysis technique because it enables you to explore the problem
space your system addresses.

It 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.

•.

Unity University 48
Cont.

• There are four high-level steps are in the UI prototyping


process:
Determine the needs of your users
Build the prototype
Evaluate the prototype
Determine if you are finished.

Unity University 49
Determine the needs of Users Cont.
• Evolve all or part of your essential user interface prototype

• Convert your hand drawings, flip chart paper and sticky notes into
something a little more substantial

• Begin this process by making platform decisions


 Browser or GUI, Java, mainframe based
Building the Prototype

• Use prototyping tool or high level language develop the screens, pages,
and reports

• Don’t invest a lot of time in making the code “good” because, chances
are high you will scrap large portions of your prototype code, when
Unity University 50
portions or all of your prototype fail the evaluation
Evaluating the prototype
Cont.
• Evaluation is done by the Stakeholders to verify that it meets their
needs

• Three basic questions


• What is good about the UI prototype?
• What is bad about the UI prototype?
• What is missing from the UI prototype?

• After evaluating the prototype, you may find you need to scrap parts of
it, modify parts, and even add brand-new parts.

• You want to stop the UI prototyping process when you find the
evaluation process is no longer generating any new ideas or it is
Unity University 51
generating a small number of not-so-important ideas
Cont.

Unity University 52
Your project
At this stage

• Model your system use case (with system use case description)

• Draw sequence diagrams for your use cases (determined by your


system complexity)

• Model your Analysis class diagram

• Draw Activity diagrams (determined by system complexity)

Unity University 53

You might also like