IMPORTANT QUESTIONS

1. What do you mean by object oriented analysis and design? Discuss in detail
the object oriented analysis and design process with a suitable example.
2. What is UML and its need? Name basic building Blocks of UML? Discuss
in detail the object architecture of UML.
3. What is Collaboration diagram and its need? Take an example problem
and draw the Collaboration and Sequence diagram for the same.
4. Discuss in detail the modeling techniques for component diagrams.
5. Write Short Notes on the following:
(a) Component Diagrams.
(b) Deployment Diagrams
6. What is a use case? What are its key attributes? Explain the use case
relationships with examples?

7.

Define state, initial state, final state and event. Explain the use of state chart

diagram with example?

8. Explain in brief behavior modeling?

In software and systems engineering, a use case is a list of steps, typically defining interactions
between a Actor and a system, to achieve a goal. The actor can be a human, an external system, or
time.

Use Case attributes are:

USE CASE SPECIFICATIONS

<This template should be copied and completed for each individual use case. If a requirements
management tool is available, the requirements management tool should automate the Use Case
Identification and History section>
Use Case Identification and History
Use Case ID: PROJ.UC.1.1.1 <Assign a unique name to each use case>
Use Case Name:

Information of
Document,
Description,

End Objective:

<Name concise results orientedname with an action verb and a

noun. >

Version No:

Contains info Small info about

System and Actors
Detailed info

< The directly observable purpose of this use case >

Created by:

On (date):

Last Update by:

On (date):

Approved by:

On (date):

User/Actor:

<Description of the person who uses the system to accomplish tasks>

Contact
Details:

Business Owner Name:

Trigger:
Frequency of Use:

<Who (system or user) triggers this use case>

<How often does this series of activities occurs>

Preconditions

<What is true of the system state before this flow of actions begins>

Basic Flow <The optimal or normal ("good day") flow of events. The basic flow of events should describe
the events that walk through a successful scenario. The basic flow should not include and/if scenarios>
Step
1

User Actions

<Phrase saying what user

does>

System Actions

<Description of system response>

1. Information of Document,

The introduction section of the use-case diagram provides a clear, concise overview of the purpose and
functionality of the system.The use case diagram clearly presents the behavior of the system; it is easy
to understand what the system does by reviewing the diagram

3. OBJECTIVE,

4. ACTORS, ACTORS

Have you found all the actors? That is, have you accounted for and diagramed all roles in the
system's environment? Although you should check this, you cannot be sure until you have found
and described all the use cases.

Is each actor involved with at least one use case? Remove any actors not mentioned in the use-case
descriptions, or any actors without communicates-associations with a use case. However, an actor
mentioned in a use-case description is likely to have a communicates-association with that
particular use case.

Can you name at least two people who would be able to perform as a particular actor? If not, check
if the role the actor diagrams is part of another one. If so, you should merge the actor with another
actor.

5.Pre-conditions,

6.Data-element desriptions,
7.post conditions, 8.primary flow, 9. Alternative flow

Alternate Flow <may be more than one>

Step
User Actions
1

System Actions
<Description of alternative flow step(s) (number each

<Phrase saying what user does,

distinct step)>
identify prior basic step #
where alternative flow begins
and subsequent basic step #
where basic flow continues (if
it does) after performing
alternate flow>

<Example: The User overrides

the make, model or year of

<Example: System requests confirmation by the user>

vehicle (Basic Flow, Step 3)>

<Repeat as needed>

<Repeat>

and
Business rules/interaction implimentations and etc..

Business Rules
1. <Identify any business rules or constraints particular to this specific use case. Example of a
business rule would be: When an Account of a subscription has a Credit Card on File, all
subscriptions under that account rollover month-to-month.>

Other Notes (Assumptions, Issues,)

< Any special considerations that need to be kept in mind for this use case only; identify the
type of item with a tag like

Assumptions:

Issues:

Use Case Diagram

Relationships

in

Use

Case

Diagram:

Use cases share different kinds of relationships. A relationship between two use cases is basically a
dependency between the two use cases. Defining the relationship between two use cases is the decision
of the modeler of the use case diagram. This use of an existing use case using different types of
relationships reduces the overall effort required in defining use cases in a system. Use case relationships
can be one of the following:

Communicates: The participation of an actor in a use case is shown by connecting the actor
symbol to use case symbol by a solid path. The actor is said to 'communicates' with the use case.
This is only relation between an actor and use cases. See figure 3.4.

Figure 3.4 Communicates relationship

Extends: An extends shows the relationships between use cases. Relationship between use case
A and use case B indicates that an instance of use case B may include (subject to specified in the
extension) the behavior specified by A. An 'extends' relationship between use cases is depicted
with a directed arrow having a dotted shaft. The tip of arrowhead points to the parent use case
and the child use case is connected at the base of the arrow. The stereotype <extends>
identifies as an extend relationship as shown in figure 3.5.

Figure 3.5 An example of an extend relationship

For example, validating the user for a system. A invalid password is extension of validating password use
case as shown in figure 3.5.

Include or uses: When a use case is depicted as using functionality of another functionality of
another use case, this relationship between the use cases is named as an include or uses
relationship. In other words, in an include relationship, a use case includes the functionality
described in the another use case as a part of its business process flow. A uses relationship from
use case A to use case B indicates that an instance of the use case will also include the behavior
as specified by B. An include relationship is depicted with a directed arrow having a dotted shaft.
The tip of arrowhead points to the child use case and the parent use case connected at base of
the arrow. The stereotype <include> identifies the relationship as an include relationship.

Figure 3.6 An example of an include relationship

The system boundary is potentially the entire system as defined in the requirements document. For large
and complex systems, each modules may be the system boundary. For example, for an ERP system for
an organization, each of the modules such as personal, payroll, accounting, etc. can form a system
boundary for use cases specific to each of these business functions. The entire system can span all of
these modules depicting the overall system boundary.

Generalization: A generalization relationship is also a parent-child relationship between use

cases. The child use case in the generalization relationship has the underlying business process
meaning, but is an enhancement of the parent use case. In a use case diagram, generalization is
shown as a directed arrow with a triangle arrowhead. The child use case is connected at the base
of the arrow. The tip of the arrow is connected to the parent use case.

Figure 3.7 An example of generalization relationship

On the face of it, both generalization and extends appear to be more or less similar. But there is a subtle
difference between a generalization and an extend relationship. When a generalization relationship is
established between use cases, this implies that the parent use case can be replaced by the child use
case without breaking the business flow. On the other hand, an extend relationship between use cases
implies that the child use case enhances the functionality of the parent use case into a specialized
functionality. The parent use case in an extend in an extend relationship can't be replaced by the child
use
case.
From the diagram of a generalization relationship (Figure 3.7), you can that Store_patient_records
(paper file) (parent) use case is depicted as a generalized version of the Store_patient_records
(computerized file) (child) use case. Defining a generalization relationship between two implies that any
occurrence of Store_patient_records (paper file) use case in the business flow of the system can be
replaced with the Store_patient_records (computerized file) use case without impacting any business
flow. This means that in future you might choose to store patient records in a computerized file instead of
as
paper
documents
without
impacting
other
business
actions.
Now, consider example of Invalid Password use case which is extension of Login use case. The Login
use case can't be replaced by Invalid Password use case. If you try to do this, you would not be able to
seamlessly replace the occurrence of the Login use case with Invalid Password use case.