CS8592-OBJECT ORIENTED ANALYSIS AND DESIGN

PART – A (10*2=20 marks)

1. Define object.
An object is a combination of data and logic; the representation of some real-world entity.
2. What is Unified process?
A software development process describes an approach to building, deploying and possibly maintaining
software. The unified process has emerged as a popular iterative software development process for
building object oriented system.
3. Define Use case and Actor.
Use cases are requirements; primarily they are functional requirements that indicate what the system will
do. An actor is something with behavior, such as a person (identified by role), computer system, or
organization; for example, a cashier.
4. What are the perspectives to apply UML?(May-17)
1. Conceptual perspective the diagrams are interpreted as describing things in a situation of the real
world or domain of interest.
2. Specification (software) perspective the diagrams (using the same notation as in the conceptual
perspective) describe software abstractions or components with specifications and interfaces, but no
commitment to a particular implementation (for example, not specifically a class in C# or Java).
3. Implementation (software) perspective the diagrams describe software implementations in a particular
technology (such as Java).
5. Define OOAD.
During object oriented analysis, there is an emphasis on finding and describing the objects or concepts in
the problem domain. For example in the case of the library information system, some of the concepts
include book, library and patron.
During object oriented design, there is an emphasis on defining software objects and how they
collaborate
to fulfill the requirements. For example, in the library system, a book software object may have a title
attribute and a get chapter method
6. Outline the purpose using use cases, to describe requirements?
Writing use cases is a simple intuitive means for capturing system requirements. Use cases are valuable
because they keep system development focused on the needs of the end user. ... A use case is a narrative
description of a goal-oriented interaction between the system under development and an external agent.
7. What are the primary goals to design of UML?
Provide users a ready to use expressive visual modeling language so they can develop and exchange
meaningful models.
Provide extensibility and specialization mechanism to extend the core concepts.
Encourage the growth of oo tools market.
Support higher level development concepts.
8. Define modular design.
Modular design, or "modularity in design", is an approach (design theory and practice) that subdivides a
system into smaller parts called modules or skids, that can be independently created and then used in
different systems.
9. What are the tasks performed by elaboration?
• Explore concepts from requirements/use cases
• Domain models: basic concepts and their inter-relationships
• Basic architectural concepts for system
• System sequence interactions – system events, UI basics
10. List the relationship used in class diagrams.
Instance-level relationships
Dependency
Aggregation
Composition
 Class-level relationships
Generalization/Inheritance
Realization/Implementation
PART – B (2*15=30 marks)
11. a.i. Outline the steps to be followed to identify actors and use cases (7)
Use Case Diagram objects
Use case diagrams consist of 4 objects.
 Actor
 Use case
 System
 Package
The objects are further explained below.
Actor
Actor in a use case diagram is any entity that performs a role in one given system. This could be a
person, organization or an external system and usually drawn like skeleton shown below.

Use Case
A use case represents a function or an action within the system. It’s drawn as an oval and named with
the function.

System
The system is used to define the scope of the use case and drawn as a rectangle. This an optional
element but useful when you’re visualizing large systems. For example, you can create all the use cases
and then use the system object to define the scope covered by your project. Or you can even use it to
show the different areas covered in different releases.

Package
The package is another optional element that is extremely useful in complex diagrams

Relationships in Use Case Diagrams

There are five types of relationships in a use case diagram. They are
 Association between an actor and a use case
 Generalization of an actor
 Extend relationship between two use cases
 Include relationship between two use cases
 Generalization of a use case
How to Create a Use Case Diagram
 Up to now, you’ve learned about objects, relationships and guidelines that are critical when drawing use
case diagrams. I’ll explain the various processes using a banking system as an example.
Identifying Actors
Actors are external entities that interact with your system. It can be a person, another system or an
organization. In a banking system, the most obvious actor is the customer. Other actors can be bank
employee or cashier depending on the role you’re trying to show in the use case.
Identifying Use Cases
Now it’s time to identify the use cases. A good way to do this is to identify what the actors need from the
system. In a banking system, a customer will need to open accounts, deposit and withdraw funds, request
check books and similar functions. So all of these can be considered as use cases.

A use case with most of the scenarios found in use case diagrams

ii. Explain in detail about interaction diagrams also notation (8)

Object-oriented design is concerned with defining software objects and their collaborations. A common
notation
To illustrate these collaborations is the interaction diagram. It shows the flow of messages between
software
objects, and thus the invocation of methods.
For example, assume that a software implementation of the dice game is desired. The interaction
diagram in Figure
illustrates the essential step of playing, by sending messages to instances of the DiceGame and Die
classes.
Notice that although in the real world a player rolls the dice, in the software design the DiceGame object
"rolls" the
dice (that is, sends messages to Die objects). Software object designs and programs do take some
inspiration from
real-world domains, but they are not direct models or simulations of the real world.
 (OR)
b. i. Explain about UML diagrams in detail with neat diagram (7)
The Use Case Model describes the proposed functionality of the new system. A Use Case represents a
discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single
unit of meaningful work; for example login to system, register with system and create order are all Use
Cases. Each UseCase has a description which describes the functionality that will be built in the proposed
system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its
own behavior.
A Use Case description will generally include:
1. General comments and notes describing the use case;
2. Requirements - Things that the use case must allow the user to do, such as <ability to update order>,
<ability to modify order> & etc.
3. Constraints- Rules about what can and can't be done. Includes
i) pre-conditions that must be true before the use case is run -e.g. <create order> must precede <modify
order>;
ii) post-conditions that must be true once the use case is run e.g. <order is modified and consistent>;
iii) invariants: these are always true - e.g. an order
4. Scenarios - Sequential descriptions of the steps taken to carry out the use case. May include multiple
scenarios, tocater for exceptional circumstances and alternate processing paths;
5. Scenario diagrams -Sequence diagrams to depict the workflow - similar to (4) but graphically
6. Additional attributes such as implementation phase, version number, complexity rating.
Actors
An Actor is a user of the system. This includes both human users and other computer systems. An Actor
uses a Use Case to perform some piece of work which is of value to the business. The set of Use Cases
an actor has access to define their overall role in the system and the scope of their action.
The formal specification of a Use Case includes:
1. Requirements. These are the formal functional requirements that a Use Case must provide to the end
user.
They correspond to the functional specifications found in structured methodologies. A requirement is a
contract that the Use Case will perform some action or provide some value to the system.
2. Constraints. These are the formal rules and limitations that a Use Case operates under, and includes
pre- post and invariant conditions.
A pre-condition specifies what must have already occurred or be in place before the Use Case may start.
A post-condition documents what will be true once the Use Case is complete. An invariant specifies what
will be true throughout the time the Use Case operates Scenarios.
Scenarios are formal descriptions of the flow of events that occurs during a Use Case instance. These
are usually described in text and correspond to a textual representation of the Sequence Diagram.
(for diagrams refer question no : 11.b.i)
 ii. What is inception? Outline the task that a project team performs during inception. (8)
Inception in one sentence:
Envision the product scope, vision, and business case.
The main problem solved in one sentence:
Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious
investigation?
Inception: An Analogy
In the business, when a new field is being considered, some of the steps include:
1. Decide if there is enough evidence or a business case to even justify exploratory drilling.
2. If so, do measurements and exploratory drilling.
3. Provide scope and estimate information.
4. Further steps...
 The inception phase is like step one in this analogy. In step one people do not predict how much oil
there is, or the cost or effort to extract it. It is premature—there is insufficient information.
 Although it would be nice to be able to answer "how much" and "when" questions without the cost and
effort of the exploration, in the oil business it is understood to not be realistic.
 In UP terms, the realistic exploration step is the elaboration phase.
 The preceding inception phase is akin to a feasibility study to decide if it is even worth investing in
exploratory drilling. Only after exploration (elaboration) do we have the data and insight to make
somewhat believable estimates and plans.
 Therefore, in iterative development and the UP, plans and estimates are not to be considered reliable in
the inception phase. They merely provide an order-of-magnitude sense of the level of effort, to aid the
decision to continue or not.

12.a.i. Write short notes on Association.(7)

Association
Association is a relationship between two objects. In other words, association defines the multiplicity
between objects. You may be aware of one-to-one, one-to-many, many-to-one, many-to-many all these
words define an association between objects. Aggregation is a special form of association. Composition
is a special form of aggregation.

Example: A Student and a Faculty are having an association.

ii. Write short notes on domain model.(8)

A domain model captures the most important types of objects in the context of the
business. The domain model represents the ‘things’ that exist or events that transpire in the business
environment.”
Foundation for use case/workflow modeling Based on the defined structure, we can describe the state of
the problem domain at any time.
Features of a domain model
 The following features enable us to express time invariant static business rules for a domain:-
Domain classes – each domain class denotes a type of object.
 Attributes – an attribute is the description of a named slot of a specified type in a domain class
each instance of the class separately holds a value.
 Associations – an association is a relationship between two (or more) domain classes that describe
links between their object instances. Associations can have roles, describing the multiplicity and
participation of a class in the relationship.
 Additional rules – complex rules that cannot be shown with symbology can be shown with
attached notes
 FINDING CONCEPTUAL CLASSES AND DESCRIPTION CLASSES:
A class diagram 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 objects. Class diagrams can also be used for data modeling.
The classes in a class diagram represent both the main objects, interactions in the application and the
classes to be programmed.
A class with three sections.
In the diagram, classes are represented with boxes which contain three parts:
The top part contains the name of the class. It is printed in bold and centered, and the first letter is
capitalized.
The middle part contains the attributes of the class. They are left-aligned and the first letter is lowercase.
The bottom part contains the methods the class can execute. They are also left-aligned and the first letter
is lowercase.

(OR)
b. i. (i) Describe the UML notation for class diagram with example.(8)
UML - Class Diagram
Class diagram is a static diagram. It represents the static view of an application. Class diagram is not only
used for visualizing, describing, and documenting different aspects of a system but also for constructing
executable code of the software application.
Purpose of Class Diagrams
The purpose of class diagram is to model the static view of an application. Class diagrams are the only
diagrams which can be directly mapped with object-oriented languages and thus widely used at the time
of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the
application, however class diagram is a bit different. It is the most popular UML diagram in the coder
community.
The purpose of the class diagram can be summarized as −
 Analysis and design of the static view of an application.
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.
How to Draw a Class Diagram?
Class diagrams are the most popular UML diagrams used for construction of software applications. It is
very important to learn the drawing procedure of class diagram.
Class diagrams have a lot of properties to consider while drawing but here the diagram will be considered
from a top level view.
 The name of the class diagram should be meaningful to describe the aspect of the system.
 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be clearly identified
 For each class, minimum number of properties should be specified, as unnecessary properties will make
the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram. At the end of the drawing it should
 First of all, Order and Customer are identified as the two elements of the system. They have a one-to-
many relationship because a customer can have multiple orders.
 Order class is an abstract class and it has two concrete classes (inheritance relationship) SpecialOrder and
NormalOrder.

Where to Use Class Diagrams?

Class diagram is a static diagram and it is used to model the static view of a system. The static view
describes the vocabulary of the system.
Class diagram is also considered as the foundation for component and deployment diagrams. Class
diagrams are not only used to visualize the static view of the system but they are also used to construct
the executable code for forward and reverse engineering of any system.
Generally, UML diagrams are not directly mapped with any object-oriented programming languages but
the class diagram is an exception.
Class diagram clearly shows the mapping with object-oriented languages such as Java, C++, etc. From
practical experience, class diagram is generally used for construction purpose.
In a nutshell it can be said, class diagrams are used for −
 Describing the static view of the system.
 Showing the collaboration among the elements of the static view.
 Describing the functionalities performed by the system.
 Construction of software applications using object oriented languages.

(ii).Describe the concepts of link, association and Inheritance (7)

Inheritance
Inheritance is the mechanism that permits new classes to be created out of existing classes by extending
and refining its capabilities.
The existing classes are called the base classes/parent classes/super-classes, and the new classes are
called the derived classes/child classes/subclasses.
The subclass can inherit or derive the attributes and methods of the super-class(es) provided that the
super-class allows so. Besides, the subclass may add its own attributes and methods and may modify any
of the super-class methods. Inheritance defines an “is – a” relationship.
Example
From a class Mammal, a number of classes can be derived such as Human, Cat, Dog, Cow, etc. Humans,
cats, dogs, and cows all have the distinct characteristics of mammals. In addition, each has its own
particular characteristics. It can be said that a cow “is – a” mammal.
Types of Inheritance
 Single Inheritance − A subclass derives from a single super-class.
 Multiple Inheritance − A subclass derives from more than one super-classes.
 Multilevel Inheritance − A subclass derives from a super-class which in turn is derived from another
class and so on.
 Hierarchical Inheritance − A class has a number of subclasses each of which may have subsequent
subclasses, continuing for a number of levels, so as to form a tree structure.
 Hybrid Inheritance − A combination of multiple and multilevel inheritance so as to form a lattice
structure.
The following figure depicts the examples of different types of inheritance.

Link
A link represents a connection through which an object collaborates with other objects. Rumbaugh has
defined it as “a physical or conceptual connection between objects”. Through a link, one object may
invoke the methods or navigate through another object. A link depicts the relationship between two or
more objects.
Association
Association is a group of links having common structure and common behavior. Association depicts the
relationship between objects of one or more classes. A link can be defined as an instance of an
association.
Degree of an Association
Degree of an association denotes the number of classes involved in a connection. Degree may be unary,
binary, or ternary.
 A unary relationship connects objects of the same class.
 A binary relationship connects objects of two classes.
 A ternary relationship connects objects of three or more classes.
Cardinality Ratios of Associations
Cardinality of a binary association denotes the number of instances participating in an association. There
are three types of cardinality ratios, namely −
 One–to–One − A single object of class A is associated with a single object of class B.
 One–to–Many − A single object of class A is associated with many objects of class B.
 Many–to–Many − An object of class A may be associated with many objects of class B and conversely
an object of class B may be associated with many objects of class A.

Staff InCharge HoD