BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
1. Discuss the importance of object orientation during system development.
Ans:
Object Oriented Development (OOD) has been touted as the next great advance in software
engineering. It promises to reduce development time, reduce the time and resources
required to maintain existing applications, increase code reuse, and provide a competitive
advantage to organizations that use it. While the potential benefits and advantages of OOD
are real, excessive hype has lead to unrealistic expectations among executives and
managers. Even software developers often miss the subtle but profound differences
between OOD and classic software development.
Expected Benefits of OOD
Many benefits are cited for OOD, often to an unrealistic degree. Some of these potential
benefits :
Faster Development: OOD has long been touted as leading to faster development.
Many of the claims of potentially reduced development time are correct in principle, if
a bit overstated.
Reuse of Previous work: This is the benefit cited most commonly in literature,
particularly in business periodicals. OOD produces software modules that can be
plugged into one another, which allows creation of new programs. However, such
reuse does not come easily. It takes planning and investment.
Increased Quality: Increases in quality are largely a by-product of this program
reuse. If 90% of a new application consists of proven, existing components, then only
the remaining 10% of the code has to be tested from scratch. That observation
implies an order-of-magnitude reduction in defects.
Modular Architecture: Object-oriented systems have a natural structure for modular
design: objects, subsystems, framework, and so on. Thus, OOD systems are easier
to modify. OOD systems can be altered in fundamental ways without ever breaking
up since changes are neatly encapsulated. However, nothing in OOD guarantees or
requires that the code produced will be modular. The same level of care in design
and implementation is required to produce a modular structure in OOD, as it is for
any form of software development.
Suresh Kumar Suthar Roll : 52077676 1
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
Client/Server Applications: By their very nature, client/server applications involve
transmission of messages back and forth over a network, and the object-message
paradigm of OOD meshes well with the physical and conceptual architecture of
client/server applications.
Better Mapping to the Problem Domain: This is a clear winner for OOD, particularly
when the project maps to the real world. Whether objects represent customers,
machinery, banks, sensors or pieces of paper, they can provide a clean, self-
contained implication which fits naturally into human thought processes.
Therefore, OOD offers significant benefits in many domains, but those benefits must be
considered realistically. There are many pitfalls that await those who venture into OOD
development. These pitfalls threaten to undermine the acceptance and use of object-
oriented development before its promise can be achieved. Due to the excitement
surrounding OOD, expectations are high and delays and failures, when they come, will have
a greater negative impact.
The purpose of this paper is to summarize different types of pitfalls that developers should
try to avoid when developing applications in an OOD environment. In addition, suggested
approaches to avoid these pitfalls can enable system developers to truly capitalize on the
benefits of OOD.
Suresh Kumar Suthar Roll : 52077676 2
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
2. What are the different types of object relationships?
Ans:
A relationship may be seen as a named family of typed tuples. They are typed in the sense
that the nth element in a tuple is an instance from a specific domain or class. The signature
of a relationship is just a listing of these types. For example, the signature of the Ownership
relationship is ( Client, Account) since it has a family of 2-tuples where the first domain is the
class of Clients and the second domain is the class of Accounts.
Following the tradition of the data modeling community and other OOA methods, a diamond
is used to depict a relationship in our graphical notation. A diamond is connected via edges
to the domains of the tuple elements. Obviously, we will always have at least two edges. For
example, to indicate that class Client and class Account are connected by the relationship
Own:
In the same way that we may want to refer to particular instances of classes in a particular
target system, we may want to express that certain instances actually belong to a
relationship. For example, we may want to express that a particular client owns a particular
account. An instance of a relation is represented with a diamond containing a filled circle:
Suresh Kumar Suthar Roll : 52077676 3
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
Graphical notation can sometimes cause an ambiguity when a relationship connects
identical domains. For example, the Supervise relationship between two Persons is
described in textual representations by ordering the arguments, as in:
Supervise(Person, Person).
We can agree that the first argument represents the supervisor and the second argument
the ``supervisee'' (person that is being supervised). To avoid ambiguity in diagrams we can
add role names, as in (letting Spv stand for Supervise):
The arity, or number of elements in the signature is another way of classifying relationships.
Binary relations (such as Own and Supervise) have tuples of length two. Ternary relations
have tuples of length three. Examples include:
InBetween,
a relationship among three Locations. For example, Chicago is in between San
Francisco and New York.
TravelTimeBetween,
a relationship among two Locations and a TimeInterval. For example, the travel time
between New York and San Francisco is six hours.
ParentsOf,
a relationship among three Persons. For example, John and Mary are the parents of
Susanna.
ResideInSince,
a relationship among a Person, a Location, and a Date. For example, John resides in
Stockholm since December.
BorrowedFrom,
a relationship among two Persons and a Thing. For example, John borrowed a lawn
mower from Mary. (`` Thing'' here is perhaps too broad. Can someone borrow the
Sun?)
Suresh Kumar Suthar Roll : 52077676 4
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
We can have relations with tuple lengths larger than three as well. Graphically, more than
two edges are obviously required for relationships with arity greater than two. For example,
we may construe Transfer as a relation among a pair of accounts, an amount, and a date
(letting Trans stand for Transfer(fromAccount, toAccount, amount, date)):
Suresh Kumar Suthar Roll : 52077676 5
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
3. Explain the use case driven approach to object oriented systems development
process.
Ans:
Use cases describe the interaction between one or more actors (an actor that is the initiator
of the interaction may be referred to as the 'primary actor') and the system itself,
represented as a sequence of simple steps. Actors are something or someone which exists
outside the system ('black box') under study, and that take part in a sequence of activities in
a dialogue with the system to achieve some goal. Actors may be end users, other systems,
or hardware devices. Each use case is a complete series of events, described from the point
of view of the actor.[1]
There is no standard template for documenting detailed use cases. There are a number of
competing schemes, and individuals are encouraged to use templates that work for them or
the project they are on. Standardization within each project is more important than the detail
of a specific template. There is, however, considerable agreement about the core sections;
beneath differing terminologies and orderings there is an underlying similarity between most
use cases. Different templates often have additional sections, e.g., assumptions,
exceptions, recommendations, technical requirements. There may also be industry specific
sections.
Use case name
A use case name provides a unique identifier for the use case. It should be written in
verb-noun format (e.g., Borrow Books, Withdraw Cash), should describe an
achievable goal (e.g., Register User is better than Registering User) and should be
sufficient for the end user to understand what the use case is about.
Goal-driven use case analysis will name use cases according to the actor's goals,
thus ensuring use cases are strongly user centric. Two to three words is the
optimum. If more than four words are proposed for a name, there is usually a shorter
and more specific name that could be used.
Version
Suresh Kumar Suthar Roll : 52077676 6
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
Often a version section is needed to inform the reader of the stage a use case has
reached. The initial use case developed for business analysis and scoping may well
be very different from the evolved version of that use case when the software is
being developed. Older versions of the use case may still be current documents,
because they may be valuable to different user groups.
Goal
Without a goal a use case is useless. There is no need for a use case when there is
no need for any actor to achieve a goal. A goal briefly describes what the user
intends to achieve with this use case.
Summary
A summary section is used to capture the essence of a use case before the main
body is complete. It provides a quick overview, which is intended to save the reader
from having to read the full contents of a use case to understand what the use case
is about. Ideally, a summary is just a few sentences or a paragraph in length and
includes the goal and principal actor.
Actors
An actor is someone or something outside the system that either acts on the system
– a primary actor – or is acted on by the system – a secondary actor. An actor may
be a person, a device, another system or sub-system, or time. Actors represent the
different roles that something outside has in its relationship with the system whose
functional requirements are being specified. An individual in the real world can be
represented by several actors if they have several different roles and goals in
regards to a system.These interact with system and do some action on that.
Stakeholders
A stakeholder is an individual or department that is affected by the outcome of the
use case.[6] Individuals are usually agents of the organization or department for
which the use case is being created. A stakeholder might be called on to provide
input, feedback, or authorization for the use case.[7] The stakeholder section of the
use case can include a brief description of which of these functions the stakeholder
is assigned to fulfill.
Preconditions
A preconditions section defines all the conditions that must be true (i.e., describes
the state of the system) for the trigger (see below) to meaningfully cause the initiation
Suresh Kumar Suthar Roll : 52077676 7
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
of the use case. That is, if the system is not in the state described in the
preconditions, the behavior of the use case is indeterminate. Note that the
preconditions are not the same thing as the "trigger" (see below): the mere fact that
the preconditions are met does NOT initiate the use case.
However, it is theoretically possible both that a use case should be initiated
whenever condition X is met and that condition X is the only aspect of the system
that defines whether the use case can meaningfully start. If this is really true, then
condition X is both the precondition and the trigger, and would appear in both
sections. But this is rare, and the analyst should check carefully that they have not
overlooked some preconditions which are part of the trigger. If the analyst has erred,
the module based on this use case will be triggered when the system is in a state the
developer has not planned for, and the module may fail or behave unpredictably.
Triggers
A 'triggers' section describes the event that causes the use case to be initiated. This
event can be external, temporal or internal. If the trigger is not a simple true "event"
(e.g., the customer presses a button), but instead "when a set of conditions are met",
there will need to be a triggering process that continually (or periodically) runs to test
whether the "trigger conditions" are met: the "triggering event" is a signal from the
trigger process that the conditions are now met.
There is varying practice over how to describe what to do when the trigger occurs but
the preconditions are not met.
One way is to handle the "error" within the use case (as an exception).
Strictly, this is illogical, because the "preconditions" are now not true
preconditions at all (because the behavior of the use case is determined even
when the preconditions are not met).
Another way is to put all the preconditions in the trigger (so that the use case
does not run if the preconditions are not met) and create a different use case
to handle the problem. Note that if this is the local standard, then the use
case template theoretically does not need a preconditions section!
Basic course of events
Suresh Kumar Suthar Roll : 52077676 8
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
At a minimum, each use case should convey a primary scenario, or typical course of
events, also called "basic flow", "happy flow" and "happy path". The main basic
course of events is often conveyed as a set of usually numbered steps. For example:
1. The system prompts the user to log on,
2. The user enters his name and password,
3. The system verifies the logon information,
4. The system logs user on to system.
Alternative paths
Use cases may contain secondary paths or alternative scenarios, which are
variations on the main theme. Each tested rule may lead to an alternative path and
when there are many rules the permutation of paths increases rapidly, which can
lead to very complex documents. Sometimes it is better to use conditional logic or
activity diagrams to describe use case with many rules and conditions.
Exceptions, or what happens when things go wrong at the system level, may also be
described, not using the alternative paths section but in a section of their own.
Alternative paths make use of the numbering of the basic course of events to show
at which point they differ from the basic scenario, and, if appropriate, where they
rejoin. The intention is to avoid repeating information unnecessarily.
An example of an alternative path would be: "The system recognizes cookie on
user's machine", and "Go to step 4 (Main path)". An example of an exception path
would be: "The system does not recognize user's logon information", and "Go to step
1 (Main path)"
According to Anthony J H Simons and Ian Graham (who openly admits he got it
wrong - using 2000 use cases at Swiss Bank), alternative paths were not originally
part of use cases. Instead, each use case represented a single user's interaction
with the system. In other words, each use case represented one possible path
through the system. Multiple use cases would be needed before designs based on
them could be made. In this sense, use cases are for exploration, not
documentation. An Activity diagram can give an overview of the basic path and
alternative path.
Postconditions
Suresh Kumar Suthar Roll : 52077676 9
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
The post-conditions section describes what the change in state of the system will be
after the use case completes. Post-conditions are guaranteed to be true when the
use case ends.
Business rules
Business rules are written (or unwritten) rules or policies that determine how an
organization conducts its business with regard to a use case. Business rules are a
special kind of requirement. Business rules may be specific to a use case or apply
across all the use cases, or across the entire business. Use cases should clearly
reference business rules that are applicable and where they are implemented.
Business Rules should be encoded in-line with the Use Case logic and execution
may lead to different post conditions. E.g. Rule2. that a cash withdraw will lead to an
update of the account and a transaction log leads to a post condition on successful
withdrawal - but only if Rule1 which says there must be sufficient funds tests as true.
Notes
Experience has shown that however well-designed a use case template is, the
analyst will have some important information that does not fit under a specific
heading. Therefore all good templates include a section (eg "Notes to Developers")
that allows less-structured information to be recorded.
Author and date
This section should list when a version of the use case was created and who
documented it. It should also list and date any versions of the use case from an
earlier stage in the development which are still current documents. The author is
traditionally listed at the bottom, because it is not considered to be essential
information; use cases are intended to be collaborative endeavors and they should
be jointly owned.
Suresh Kumar Suthar Roll : 52077676 10
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
5. Explain in detail about Software Architecture and different UML views.
Ans:
The software architecture of a program or computing system is the structure or structures of
the system, which comprise software components, the externally visible properties of those
components, and the relationships between them. The term also refers to documentation of
a system's software architecture. Documenting software architecture facilitates
communication between stakeholders, documents early decisions about high-level design,
and allows reuse of design components and patterns between projects.
Software application architecture is the process of defining a structured solution that meets
all of the technical and operational requirements, while optimizing common quality attributes
such as performance, security, and manageability. It involves a series of decisions based on
a wide range of factors, and each of these decisions can have considerable impact on the
quality, performance, maintainability, and overall success of the application.
Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a
definition of architecture based on work by Mary Shaw and David Garlan (Shaw and Garlan
1996). Their definition is:
“Software architecture encompasses the set of significant decisions about the organization
of a software system including the selection of the structural elements and their interfaces
by which the system is composed; behavior as specified in collaboration among those
elements; composition of these structural and behavioral elements into larger subsystems;
and an architectural style that guides this organization. Software architecture also involves
functionality, usability, resilience, performance, reuse, comprehensibility, economic and
technology constraints, tradeoffs and aesthetic concerns.”
Considering that the UML diagrams can be used in different stages in the life cycle of a
system, let us take a look at the "4+1 view" of UML diagrams. The 4+1 view offers a different
perspective to classify and apply UML diagrams. The 4+1 view is essentially how a system
can be viewed from a software life cycle perspective. Each of these views represents how a
system can be modeled. This will enable us to understand where exactly the UML diagrams
fit in and their applicability.
Suresh Kumar Suthar Roll : 52077676 11
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
These different views are:
Design View: The design view of a system is the structural view of the system.
This gives an idea of what a given system is made up of. Class diagrams and object
diagrams form the design view of the system.
Process View: The dynamic behavior of a system can be seen using the process
view. The different diagrams such as the state diagram, activity diagram, sequence
diagram, and collaboration diagram are used in this view.
Component View: Next, you have the component view that shows the grouped
modules of a given system modeled using the component diagram.
Deployment View: The deployment diagram of UML is used to identify the
deployment modules for a given system. This is the deployment view of the
Use case View: Finally, we have the use case view. Use case diagrams of UML
are used to view a system from this perspective as a set of discrete activities or
transactions.
Suresh Kumar Suthar Roll : 52077676 12
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
6. How is responsibility-driven design used as a guide for deciding how to
allocate operations to classes?
Ans:
Responsibilities in an object oriented system
Responsibilities are the foundation of an object oriented system. We imagine an object
oriented system as a cage in which objects live. When a request is fired to the system, the
objects work together to fulfill the request. Every object does what it can do best and
delegates the rest to its collaborators – the other objects it works together with.
Responsibility Driven Design is just about that. It focuses on what an object can do (Wirfs-
Brock & McKean, 2003).
We find our objects by identifying relevant concepts in a domain. Candidates are concepts
that we mention repeatedly while talking about the domain. The candidates we find are
typically passive concepts from the real world without any behavior. For example, a task in a
workflow system is a passive thing being executed by a real world person and an invoice is
something passive being paid for by a real world client.
We find responsibilities by making passive things active. We assign responsibilities to the
passive concepts that are associated with them. For example, a workflow task gets the
responsibility to execute itself. An invoice gets the responsibility to pay itself. All messages
that the object responds to should match its responsibilities.
We can simulate a usage scenario of the system, by letting objects respond to messages
and delegate tasks that other objects can do better to those objects. Next, we look for what
an object needs to know to fulfill its responsibilities. This drives us towards putting
information where we directly need it.
As a result of localizing this knowledge to objects, changes to the resulting system tend to
be localized as well. Changes in one place do not ripple through the design and will not
affect other parts. This reduces the risk of introducing defects.
While system as a whole may be complicated, the objects within the system, combining
behavior and associated state, remain small and easy to understand. As a result, making
changes is therefore easy and fast.
Suresh Kumar Suthar Roll : 52077676 13
BCA VI-Sem BC0057-(01) – Object Oriented Analysis and Design
We see that, by working responsibility driven, you achieve low coupling and high cohesion
(well known software design principles). A cohesive object has responsibilities that fit well
together and contains all information it needs to fulfill its responsibilities. Low cohesion
means an unclear object doing many unrelated things or an object without any
responsibilities, making it hard to understand and change.
Low coupling means that dependencies between objects are well managed. There are only
a few dependencies between objects. Dependencies are unidirectional and exist for the
purpose of delegating responsibilities, not for obtaining information from others to fulfill
responsibilities.
Contrast this with the procedural approach we see a lot in practice: thinking primarily in
sequences of actions and collecting whatever information required from wherever that
information is lying around. In this approach, functions are highly cohesive and isolated in
one place, but data is grabbed from many other objects. Functions depend on the internal
details of many objects. Changes in a function may require changes in several objects. It is
difficult to judge the impact of changes to a single object, because many other functions
depend on it as well. Functions become sensitive to changes across the system.
The art of good design is placing responsibilities close to the knowledge required to fulfill
these responsibilities. This results in small, understandable objects loosely coupled to their
environment
Suresh Kumar Suthar Roll : 52077676 14