UNIT 3 OBJECT ORIENTED ANALYSIS

Business Object Analysis - Use Case Driven Object Oriented Analysis - Business
Process Modeling - Use Case model - Developing Effective Documentation - Object
Analysis Classification: Classification Theory - Noun Phrase Approach - Common
Class Patterns Approach - Use-Case Driven Approach - Classes Responsibilities and
Collaborators - Naming Classes - Identifying Object Relationships, Attributes and
Methods: Association - SuperSubclass Relationships - A-part of Relationships.
 Analysis

 Analysis is the process of extracting the needs of a system and what the system must do to satisfy
the users' requirement.

 The goal of object oriented analysis is to understand the domain of tile problem and the system's
responsibilities by understanding how the users use or will use the system.

 The first step in finding an appropriate solution to a given problem is to understand the problem and
its domain.

 The main objective of the analysis is to capture a complete, unambiguous, and consistent picture of
the requirements of the system and what the system must do to satisfy the users' requirements and
needs.

 This is accomplished by constructing several models of the system that concentrate on describing
what the system does rather than how it does it.


 Separating the behavior of a system from the way that behavior is implemented requires
viewing the system from the perspective of the user rather than that of the machine.

 Analysis is the process of transforming a problem definition from a fuzzy set of facts and
myths into a coherent statement of a system's requirements.

Reason for Analysis is a Difficult Activity:

 Analysis is a creative activity that involves understanding the problem, its associated
constraints, and methods of overcoming those constraints.

 This is an iterative process that goes on until the problem is well understood .Norman
explains the three most common sources of requirement difficulties:
 1. Fuzzy descriptions - such as "fast response time" or "very easy and very secure updating
mechanisms." A requirement such as fast response time is open to interpretation, which might
lead to user dissatisfaction if the user's interpretation of a fast response is different from the
systems analyst's interpretation

 2. Incomplete requirements - mean that certain requirements necessary for successful

system development are not included for a variety of reasons.

 These reasons could include the users' forgetting to identify them, high cost, politics within
the business, or oversight by the system developer.

 However, because of the iterative nature of objectoriented analysis and the unified approach
most of the incomplete requirements can be identified in subsequent tries.
 3. Unnecessary features - When addressing features of the system, keep in mind
that every additional feature could affect the performance, complexity, stability,
maintenance, and support costs of an application.

 Features implemented by a small extension to the application code do not

necessarily have a proportionally small effect on a user interface.

 Analysis is a difficult activity. You must understand the problem in some

application domain and then define a solution that can be implemented with
software.

 Experience often is the best teacher. If the first try reflects the errors of an
incomplete understanding of the problems, refine the application and try another
run.
 BUSINESS OBJECT ANALYSIS:

 Business object analysis is a process of understanding the system's requirements

and establishing the goals of an application.

 The main intent of this activity is to understand users' requirements.

 The outcome of the business object analysis is to identify classes that make up the
business layer and the relationships that play a role in achieving system goals.
 Usecase Driven Object Oriented Analysis: The Unified Approach

 The object-oriented analysis (OOA) phase of the unified approach uses actors and
use cases to describe the system from the users' perspective.

 The actors are external factors that interact with the system ;use cases are scenarios
that describe how actors use the system.

 The use cases identified here will be involved throughout the development process.

 The OOA process consists of the following steps :

 1. Identify the actors: *.Who is using the system? *.
 Or, in the case of a new system, who will be using the system?
 2. Develop a simple business process model using UML activity diagram.
 3. Develop the use case: .
 *. What are the users doing with the system?.
 *. Or, in case of the new system, what will users be doing with the system?
 *. Use cases provide us with comprehensive documentation of the system under
 study.
 4.Prepare interaction diagrams:*. Determine the
 sequence.
 *. Develop collaboration diagrams.
 5. Classification -develop a static UML class diagram:
 *. Identify classes.
 *. Identify relationships.
 *. Identify attributes.
 *. Identify methods.
 6. Iterate and refine: If needed, repeat the preceding steps
 Business Process Modeling:
 This may include modeling as-is processes and the applications that support
them and any number of phased, would-be models of reengineered processes
or implementation of the system.

 These activities would be enhanced and supported by using an activity

diagram.

 Business process modeling can be very time consuming, so the main idea
should be to get a basic model without spending too much time on the process.
 The advantage of developing a business process model is that it makes you more
familiar with the system and therefore the user requirements and also aids in
developing use cases.

 For example, let us define the steps or activities involved in using your school
library.

 These activities can be represented with an activity diagram.

 Developing an activity diagram of the business process can give us a better

understanding of what sort of activities are performed in a library by a library
member.
 Use-case Model

 Use cases are scenarios for understanding system requirements.

 A use-case model can be instrumental in project development, planning, and documentation of systems
requirements.

 A use case is an interaction between users and a system; it captures the goal of the users and the
responsibility of the system to its users). For example, take a car; typical uses of a car include "take you
different places" or "haul your stuff" or a user may want to use it "off the road.“

 The use-case model describes the uses of the system and shows the courses of events that can be
performed.

 A use-case model also can discover classes and the relationships among subsystems of the systems.


 Use-case model can be developed by talking to typical users and discussing
the various things they might want to do with the application being
prepared.

 Each use or scenario represents what the user wants to do.

 Each use case must have a name and short textual description,no more
than a few paragraphs.

 Since the use-case model provides an external view of a system or

application, it is directed primarily toward the users or the "actors" of the
systems, not its implementers
Library System
 The UML class diagram, also called an object model, represents the static
relationships between objects, inheritance, association, and the like.

 The object model represents an internal view of the system, as opposed to the
usecase model, which represents the external view of the system.

 The object model shows how the business is run. Jacobson, Ericsson, and Jacobson
call the use-case model a "what model," in contrast to the object model, which is a
"how model.".
 Guidelines for developing Use Case Models:
 Use Cases under the Microscope
 Uses and Extends Associations
 Identifying the Actors
 Guidelines for Finding Use Cases
 How Detailed Must a Use Case Be? When to Stop Decomposing and
When to Continue
 Dividing Use Cases into Packages
 Naming a Use Case
 Use Cases under the Microscope: Use cases represent the things that the user is
doing with the system, which can be different from the users' goals.

 "A Use Case is a sequence of transactions in a system whose task is to yield results
of measurable value to an individual actor of the system."

 Now let us take a look at the key words of this definition:

 Use case - Use case is a special flow of events through the system. By definition,
many courses of events are possible and many of these are very similar.

 Actors - An actor is a user playing a role with respect to the system. When dealing
with actors, it is important to think about roles rather than just people and their job
titles.
 A measurable value- A use case must help the actor to perform a task that has some
identifiable value.

 Transaction. - A transaction is an atomic set of activities that are performed either

fully or not at all. A transaction is triggered by a stimulus from an actor to the
system or by a point in time being reached in the system.
 1.Use-case name: Borrow books. A member takes books from the library to
read at home, registering them at the checkout desk so the library can keep
track of its books.. Depending on the member's record, different courses of
events will follow.

 2.Use-case name: Get an interlibrary loan. A member requests a book that the
library does not have. The book is located at another library and ordered
through an interlibrary loan.

 3.Use-case name: Return books. A member brings borrowed books back to the
library.

 4.Use-case name: Check library card. A member submits his or her library card to
theclerk, who checks the borrower's record.
 5. Use-case name: Do research. A member comes to the library to do research. The
member can search in a variety of ways (such as through books, journals, CDROM,
WWW) to find information on the subjects of that research.

 6. Use-case name: Read books, newspaper. A member comes to the library for a
quiet place to study or read a newspaper, journal, or book.

 7.. Use-case name: Purchase supplies. The supplier provides the books, journals,
and newspapers purchased by the library.
 Uses and Extends Associations: A use-case description can be difficult to understand if it
contains too many alternatives or exceptional flows of events that are performed only if
certain conditions are met as the use-case instance is carried out.

 A way to simplify the description is to take advantage of extends and uses associations.

 The extends association is used when you have one use case that is similar to another use case
but does a bit more or is more specialized; in essence, it is like a subclass.

 The uses association occurs when you are describing your use cases and notice that some of
them have subflows in common.

 To avoid describing a subflow more than once in several use cases, you can extract the
common subflow and make it a use case of its own.

 This new use case then can be used by other use cases. The relationships among the other use
cases and this new extracted use case are called a uses association
 A user may play more than one role. For instance, a member of a public library also may play
the role of volunteer at the help desk in the library.

 However, an actor should represent a single user; in the library example, the member can
perform tasks some of which can be done by others and others that are unique.

 However, try to isolate the roles that the users can play.(Fig)

 You have to identify the actors and understand how they will use and interact with the system
 Another issue worth mentioning is that actors need not be human, although actors
are represented as stick figures within a use case diagram.

 An actor also can be an external system. For example, an accounting system that
needs information from a system to update its accounts is an actor in that system .
 Guidelines for Finding Use Cases: When you have defined a set of actors, it is time to
describe the way they interact with the system.

 This should be carried out sequentially, but an iterated approach may be necessary. Here
are the steps for finding use cases :

 1. For each actor, find the tasks and functions that the actor should be able to perform or
that the system needs the actor to perform.

 The use case should represent a course of events that leads to a clear goal (or, in some
cases, several distinct goals that could be alternatives for the actor or for the system).

 2. Name the use cases

 3. Describe the use cases briefly by applying terms with which the user is familiar. This
makes the description less ambiguous.
 Once you have identified the use-cases candidates, it may not be apparent that all of these use cases
need to be described separately; some may be modeled as variants of others. Consider what the
actors want to do.

 It is important to separate actors from users. The actors each represent a role that one or several
users can play.

 Therefore, it is not necessary to model different actors that can perform the same use case in the
same way.

 The approach should allow different users to be different actors and play one role when performing
a particular actor's use case.

 Thus, each use case has only one main actor. To achieve this, you have to

 Isolate users from actors.

 Isolate actors from other actors (separate the responsibilities of each actor).
 Isolate use cases that have different initiating actors and slightly different behavior
 5. How Detailed Must a Use Case Be? When to Stop Decomposing and When to
Continue

 A use case, as already explained, describes the courses of events that will be carried out
by the system.

 Jacobson et al. believe that, in most cases, too much detail may not be very useful.

 During analysis of a business system, you can develop one use-case diagram as the
system use case and draw packages on this use case to represent the various business
domains of the system.

 For each package, you may create a child usecase diagram. On each child use-case
diagram, you can draw all of the use cases of the domain, with actions and interactions.
You can further refine the way the use cases are categorized.

 The extends and uses relationships can be used to eliminate redundant modeling of
scenarios.
 When should use cases be employed? Use cases are an essential tool in capturing
requirements and planning and controlling any software development project.

 Capturing use cases is a primary task of the analysis phase. Although most use
cases are captured at the beginning of the project, you will uncover more as you
proceed.

 The UML specification recommends that at least one scenario be prepared for each
significantly different kind of use case instance.
 Dividing Use Cases into Packages Each use case represents a particular scenario in
the system.

 You may model either how the system currently works or how you want it to work.
A design is broken down into packages. You must narrow the focus of the scenarios
in your system.

 For example, in a library system, the various scenarios involve a supplier

providing books or a member doing research or borrowing books.

 In this case, there should be three separate packages, one each for Borrow books,
Do research, and Purchase books.

 Many applications may be associated with the library system and one or more
databases used to store the information (see Figure).
 7. Naming a Use Case Use-case names should provide a general description of the
use-case function.

 The name should express what happens when an instance of the use case is
performed." Jacobson et al. recommend that the name should be active, often
expressed in the form of a verb (Borrow) or verb and noun (Borrow books).

 The naming should be done with care; the description of the use case should be
descriptive and consistent.

 For example, the use case that describes what happens when a person deposits
money into an ATM machine could be named either receive money or deposit
money.

 A library system can be divided into many packages, each of which encompasses
multiple use cases
 Developing Effective Documentation
 Documenting your project helps reveal issues and gaps in the analysis and design.

 A document can serve as a communication vehicle among the project's team members, or it
can serve as an initial understanding of the requirements.

 Blum concludes that management has responsibility for resources such as software, hardware,
and operational expenses.

 In many projects, documentation can be an important factor in making a decision about

committing resources.

 Application software is expected to provide a solution to a problem. It is very difficult, if not

impossible, to document a poorly understood problem.

 The main issue in documentation during the analysis phase is to determine what the system
must do.
 Decisions about how the system works are delayed to the design phase.

 Blum raises the following questions for determining the importance of

documentation:

 How .will a document be used? (If it will not be used, it is not necessary.)

 What is the objective of the document?

 What is the management view of the document?

 Who are the readers of the document?

 1. Organization Conventions for Documentation :

 The documentation depends on the organization's rules and regulations. Most organizations
have established standards or conventions for developing documentation.

 However, in many organizations, the standards border on the nonexistent. In other cases, the
standards may be excessive.

 Too little documentation invites disaster; too much documentation, as Blum put it, transfers
energy from the problem solving tasks to a mechanical and unrewarding activity.

 Each organization determines what is best for it, and you must respond to that definition and
refinement.
2. Guidelines for Developing Effective Documentation

 Bell and Evans provide us the following guidelines for making documents fit the
needs and expectations of your audience:

 1.Common cover. All documents should share a common cover sheet that
identifies the document, the current version, and the individual responsible for the
content. As the document proceeds through the life cycle phases, the responsible
individual may change. That change must be reflected in the cover sheet .

 2.80-20 rule. As for many applications, the 80-20 rule generally applies for
documentation : 80 percent of the work can be done with 20 percent of the
documentation. The trick is to make sure that the 20 percent is easily accessible and
the rest (80 percent) is available to those (few) who need to know.
 3.Familiar vocabulary. The formality of a document will depend on how it is used and who
will read it. When developing a documentation use a vocabulary that your readers understand
and are comfortable with. The main objective here is to communicate with readers and not
impress them with buzz words.

 4.Make the document as short as possible. Assume that you are developing a manual. The key
in developing an effective manual is to eliminate all repetition; present summaries, reviews,
organization chapters in less than three s; and make chapter headings task oriented so that the
table of contents also could serve as an index .

 5.Organize the document. Use the rules of good organization (such as the organization's
standards, college handbooks, Stunk and White's Elements of Style or the University of
Chicago Manual of Style) within each section. Appendix A provides a template for
developing documentation for a project. Most CASE tools provide documentation capability
by providing customizable reports. The purpose of these guidelines is to assist you in creating
an effective documentation
 Object Analysis : Classification:

 CLASSIFICATIONS THEORY Classification, the process of checking to see if an object

belongs to a category or a class, is regarded as a basic attribute of human nature

 . Booch explains that, intelligent classification is part of all good science. Classification
guides us in making decisions about modularization

 We may choose to place certain classes and objects together in the same module or in
different modules, depending upon the sameness we find among these declarations; coupling
and cohesion are simply measures of this sameness.

 Classification also plays a role in allocating processes to procedures.

 We place certain processes together in the same processor or different processors, depending
upon packaging, performance, or reliability concerns.
 Human beings classify information every instant of their waking lives. We
recognize the objects around us, and we move and act in relation to them.

 A human being is sophisticated information system, partly because he or she

possesses a superior classification capability .

 For example, when you see a new model of a car, you have no trouble
identifying it as a car.

 What has occurred here, even though you may never have seen this particular
car before, is that you not only can immediately identify it as a car, but you
also can guess the manufacturer and model.

 Clearly, you have some general idea of what cars look like, sound like, do, and
are good for-you have a notion of car-kind or, in object-oriented terms, the
class car.
 Classes are an important mechanism for classifying objects. The chief role of a class is to
define the attributes, methods, and applicability of its instances.

 The class car, for example, defines the property color. Each individual car (formally, each
instance of the class car) will have a value for this property, such as maroon, yellow, or white.

 It is natural to partition the world into objects that have properties (attributes)and methods
(behaviors).

 It is common and useful partitioning or classification, but we also routinely divide the world
along a second dimension: We distinguish classes from instances.

 A class is a specification of structure, behavior, and the description of an object.

Classification is concerned more with identifying the class of an object than The individual
objects within a system.
 The problem of classification may be regarded as one of discriminating things, not
between the individual objects but between classes, via the search for features or
invariant attributes or behaviors among members of a class.

 Classification can be defined as the categorization of input data (things) into

identifiable classes via the extraction of significant features of attributes of the data
from a background of irrelevant detail.

 Another issue in relationships among classes is studied.

Approaches for Identifying Classes :

 we look at four alternative approaches for identifying classes:

 1. The Noun Phrase approach;

 2. The Common Class Patterns approach;

 3. The Use case Driven, Sequence/Collaboration Modeling approach;

 4. The Classes, Responsibilities, and Collaborators (CRC) approach.

 The first two approaches have been included to increase your understanding of the
subject; the unified approach uses the use-case driven approach for identifying
classes and understanding the behavior of objects.

 However, you always can combine these approaches to identify classes for a given
problem. Another approach that can be used for identifying classes is Classes,
Responsibilities, and Collaborators (CRC) developed by Cunningham, Wilkerson,
and Beck. Classes, responsibilities, and Collaborators, more technique than
method, is used for identifying classes responsibilities and therefore their attributes
and methods.
 Noun Phrase Approach:

 The noun phrase approach was proposed by Rebecca Wirfs-Brock, Brian Wilkerson, and
Lauren Wiener .

 In this method, you read through the requirements or use cases looking for noun phrases.
Nouns in the textual description are considered to be classes and verbs.

 To be methods of the classes All plurals are changed to singular, the nouns are listed, and the
list divided into three categories relevant classes, fuzzy classes and irrelevant classes.

 It is safe to scrap the irrelevant classes, which either have no purpose or will
be unnecessary. Candidate classes then are selected from the other two
categories.


 Keep in mind that identifying classes and developing a UML class diagram just like
other activities is an iterative process.

 Depending on whether such object modeling is for the analysis or design phase of
development, some classes may need to be added or removed from the model and,
remember, flexibility is a virtue.

 You must be able to formulate a statement of purpose for each candidate class; if not,
simply eliminate it.
 i) Identifying Tentative Classes

 The following are guidelines for selecting classes in an application: .

 Look for nouns and noun phrases in the use cases.

 Some classes are implicit or taken from general knowledge.

 All classes must make sense in the application domain; avoid computer
implementation classes-defer them to the design stage.

 Carefully choose and define class names.

 ii) Selecting Classes from the Relevant and Fuzzy Categories

 The following guidelines help in selecting candidate classes from the relevant and
fuzzy categories of classes in the problem domain.

 Redundant classes. Do not keep two classes that express the same information.

 if more than one word is being used to describe the same idea, select the one that is
the most meaningful in the context of the system.

 This is part of building a common vocabulary for the system as a whole .

 Choose your vocabulary carefully; use the word that is being used by the user of
the system.
 Adjectives classes.

 Adjectives can be used in many ways.

 An adjective can suggest a different kind of object, different use of the same
object, or it could be utterly irrelevant.

 Does the object represented by the noun behave differently when the adjective is
applied to it? If the use of the adjective signals that the behavior of the object is
different, then make a new class" .

 For example, Adult Members behave differently than Youth Members, so ,the two
should be classified as different classes
 Attribute classes. Tentative objects that are used only as values should be defined or
restated as attributes and not as a class.

 For example, Client Status and Demographic of Client are not classes but attributes
of the Client class.

 Irrelevant classes. Each class must have a purpose and every class should be clearly
defined and necessary. You must formulate a statement of purpose for each
candidate class. If you cannot come up with a statement of purpose, simply
eliminate the candidate class
The process of eliminating the redundant classes and refining the remaining classes is
not sequential. You can move back and forth among these steps as often as you like.
 Reviewing the Classes Containing Adjectives

 We again review the remaining list, now with an eye on classes with adjectives. The main
question is this:

 Does the object represented by the noun behave differently when the adjective is applied to
it?

 If an adjective suggests a different kind of class or the class represented by the noun behaves
differently when the adjective is applied to it, then we need to make a new class.

 However(it is a different use of the same object or the class is irrelevant, we must eliminate
it) In this example, we have no classes containing adjectives that we can eliminate.
 Reviewing the Possible Attributes :

 The next review focuses on identifying the noun phrases that are attributes, not classes.

 The noun phrases used only as values should be restated as attributes.

 This process also will help us identify the attributes of the classes in the system.

 Amount : a value, not a class.

 Account Balance: An attribute of the Account class.

 Invalid PIN: It is only a value, not a class.

 Password: An attribute, possibly of the BankClient class.

 Transaction History: An attribute, possibly of the Transaction class.

 PIN: An attribute, possibly of the BankClientclass.

 Reviewing the Class Purpose :

 Identifying the classes that playa role in achieving system goals and requirements is a major
activity of object-oriented analysis) Each class must have a purpose.

 Every class should be clearly defined and necessary in the context of achieving the system's
goals.

 If you cannot formulate a statement of purpose for a class, simply eliminate it.

 The classes that add no purpose to the system have been deleted from the list.

 The candidate classes are these:

 ATM Machine class:

 Provides an interface to the ViaNet bank.

 ATMCard class: Provides a client with a key to an account.

 BankClient class: A client is an individual that has a checking account and, possibly, a savings
account.

 Bank class: Bank clients belong to the Bank. It is a repository of accounts and processes the
accounts' transactions.

 Account class: An Account class is a formal (or abstract) class, it defines the common behaviors that
can be inherited by more specific classes such as CheckingAccount and SavingsAccount.

 CheckingAccount class: It models a client's checking account and provides more specialized
withdrawal service. .

 savingsAccount class: It models a client's savings account. Transaction class: Keeps track of
transaction, time, date, type, amount, and 'balance.
 Common Class Pattern Approach :

 The second method for identifying classes is using common class patterns,
which is based on a knowledge base of the common classes.

 They have compiled and listed the following patterns for finding the
candidate class and object :
 Name.Concept class Context:

 A concept is a particular idea or understanding that we have of our world.

 The concept class encompasses principles that are not tangible but used to organize or
keep track of business activities or communications.

 Marin and Odell describe concepts elegantly, ”Privately held ideas or notions are called
conceptions.

 When an understanding is shared by another, it becomes a concept.

 To communicate with others, we must share our individually held conceptions andarrive
at agreed concepts.” Furthermore, Martin and Odell explain that, without concepts,
mental life would be total chaos since every item we encountered would be different.
Example.Performance is an example of concept class object.
 Name.Events class Context:

 Events classes are points in time that must be recorded.

 Things happen, usually to something else at a given date and time or as a step in an
ordered sequence.

 Associated with things remembered are attributes (after all, the things to remember
are objects) such as who, what, when, where, how, or why. Example.Landing,
interrupt, request, and order are possible events.
 Name.Organization class Context: .

 An organization class is a collection of people, resources,facilities, or groups to

which the users belong; their capabilities have a defined mission, whose existence
is largely independent of the individuals.

 Example.An accounting department might be considered a potential class.

 Name.People class (also known as person, roles, and roles played class) Context.
The people class represents the different roles users play in interacting with the
application.

 Example. Employee, client, teacher, and manager are examples of people.

 Name. Places class Context. Places are physical locations that the system
must keep information about.

 Example. Buildings, stores, sites, and offices are examples of places.

 Name Tangible things and devices class Context.

 This class includes physical objects or groups of objects that are tangible
and devices with which the application interacts.

 Example. Cars are an example of tangible things, and pressure sensors are
an example of devices.
Use-case Driven Approach:

 The use cases are employed to model the scenarios in the system and specify what external
actors interact with the scenarios.

 The scenarios are described in text or through a sequence of steps.

 Use-case modeling is considered a problem-driven approach to object-oriented analysis, in

that the designer first considers the problem at hand and not the relationship between objects,
as in a data-driven approach.
 Modeling with use cases is a recommended aid in finding the objects of a system
and is the technique used by the unified approach.

 Once the system has been described in terms of its scenarios, the modeler can
examine the textual description or steps of each scenario to determine what objects
are needed for the scenario to occur.

 However, this is not a magical process in which you start with use cases, develop a
sequence diagram, and voila, classes appear before your eyes.
 The process of creating sequence or collaboration diagrams is a systematic way to think about how a
use case (scenario) can take place; and by doing so, it forces you to think about objects involved in
your application.

 When building a new system, designers model the scenarios of the way the system of business
should work.

 When redesigning an existing system, many modelers choose to first model the scenarios of the
current system, and then model the scenarios of the way the system should work.

 i) Implementation Of Scenarios:

 The UML specification recommends that at least one scenario be prepared for each significantly
different use-case instance.

 Each scenario shows a different sequence of interaction between actors and the system, with all
decisions definite. In essence, this process helps us to understand the behavior of the system's
objects.
 When you have arrived at the lowest use-case level, you may create a child
sequence diagram or accompanying collaboration diagram for the use case.

 With the sequence and collaboration diagrams, you can model the implementation
of the scenario.

 When you have arrived at the lowest use-case level, you may create a child
sequence diagram or accompanying collaboration diagram for the use case.

 With the sequence and collaboration diagrams, you can model the implementation
of the scenario.
 As explained in a sequence diagram, the objects involved are drawn on the diagram as a
vertical dashed line, with the name of the objects at the top.

 Horizontal lines corresponding to the events that occur between objects are drawn between
the vertical object lines.

 The event lines are drawn in sequential order, from the top of the diagram to the bottom.

 They do not necessarily correspond to the steps defined for a usecase scenario.
Actor

Class

Synchronous message

Asynchronous message

Focus of Control

Return message

Termination
lifeline
 Classes, Responsibilities, and Collaborators :(Crc) Approach :

 Classes, responsibilities, and collaborators (CRC), developed by Cunningham, Wilkerson,

and Beck, was first presented as a way of teaching the basic concepts of object-oriented
development .

 Classes, Responsibilities, and Collaborators is a technique used for identifying classes'

responsibilities and therefore their attributes and methods. Furthermore, Classes,
Responsibilities, and Collaborators can help us identify classes.

 Classes, Responsibilities, and Collaborators is more a teaching technique than a method for
identifying classes.
 Classes, Responsibilities, and Collaborators cards are 4" X 6" index cards. All the information
for an object is written on a card, which is cheap, portable, readily available, and familiar.

 Figure shows an idealized card. The class name should appear in the upper left-hand corner,
a bulleted list of responsibilities should appear under it in the left two thirds of the card, and
the list of collaborators should appear in the right third.

 Classes, Responsibilities, and Collaborators cards place the designer's focus on the
motivation for collaboration by representing (potentially) many messages as phrases of
English text.
 Classes, Responsibilities, And Collaborators Process The Classes, Responsibilities, and
Collaborators process consists of three steps

 1. Identify classes' responsibilities (and identify classes).

 2. Assign responsibilities.

 3. Identify collaborators
 Classes are identified and grouped by common attributes, which also provides candidates for
super classes.

 The class names then are written onto Classes, Responsibilities, and Collaborators cards. The
card also notes sub- and super classes to show the class structure.

 The application's requirements then are examined for actions and information associated with
each class to find the responsibilities of each class.

 Next, the responsibilities are distributed; they should be as general as possible and placed as
high as possible in the inheritance hierarchy.

 The idea in locating collaborators is to identify how classes interact. Classes (cards) that have
a close collaboration are grouped together physically.
 Iden tify
Classes
resp onsib ility

Iterate

Iden tify Assign

Collabo ration resp onsib ility
 CRC starts with only one or two obvious cards.
 If the situation calls for a responsibility not already covered by one of the
objects:
◦ Add, or
◦ Create a new object to address that responsibility.
 Guidelines for Naming Classes
 The class should describe a single object, so it should be the singular form of noun.

 Use names that the users are comfortable with.

 The name of a class should reflect its intrinsic nature.

 By the convention, the class name must begin with an upper case letter.

 For compound words, capitalize the first letter of each word - for example,
LoanWindow.
 Associations:
 A reference from one class to another is an association.
 Basically a dependency between two or more classes is an association.
 For example, Jackie works for John.
 Some associations are implicit or taken from general knowledge.
Guidelines For Identifying Associations

 Association often appears as a verb in a problem statement and represents relationships

between classes.
 For example a pilot can fly planes.
 Association often corresponds to verb or prepositional phrases such as part of, next to,
works for, contained in, etc.

Common Association Patterns:

 Common association patterns include:
 Location Association: next To, part of, contained in, ingredient of etc. :
 For example cheddar cheese is an ingredient of the French soup.

 Communication association—talk to, order to.

 For example, a customer places an order with an operator person.

Customer Operator

Order
Eliminate Unnecessary Associations:
 Implementation association. Defer implementation-specific associations to
the design phase.

 Ternary associations. Ternary or n-ary association is an association among

more than two classes

 Directed actions (derived) associations can be defined in terms of other

associations.

 Since they are redundant you should avoid these types of association.
 Grandparent of Ken can be defined in terms of the parent association.

Grand Parent
John of Ken

Parent Parent
of Brian of
John Ken
Superclass-Subclass Relationships:

 Recall that at the top of the class hierarchy is the most general class, and from it
descend all other, more specialized classes.

 Sub-classes are more specialized versions of their super-classes.

Guidelines For Identifying Super-sub Relationships: Top-down:

 Look for noun phrases composed of various adjectives on class name.

 Example, Military Aircraft and Civilian Aircraft.
 Only specialize when the sub classes have significant behavior

Guidelines For Identifying Super-sub Relationships: Bottom-up

 Look for classes with similar attributes or methods.

 Group them by moving the common attributes and methods to super class.
 Do not force classes to fit a preconceived generalization structure.
Guidelines For Identifying Super-sub Relationships: Reusability

 Move attributes and methods as high as possible in the hierarchy.

 At the same time do not create very specialized classes at the top of hierarchy.

 This balancing act can be achieved through several iterations

Guidelines For Identifying Super-sub Relationships: Multiple inheritance:

 Avoid excessive use of multiple inheritance.

 It is also more difficult to understand programs written in multiple

inheritance system.
Multiple inheritance.

 Avoid excessive use of multiple inheritances.

 Multiple inheritance brings with it complications such as how to determine which behavior to
get from which class, particularly when several ancestors define the same method.

 It also is more difficult to understand programs written in a multiple inheritance system.

 One way of achieving the benefits of multiple inheritance is to inherit from the most
appropriate class and add an object of another class as an attribute.
A Part of Relationships-aggregation

 A-part-of relationship, also called aggregation, represents the situation where a class consists
of several component classes.

 A class that is composed of other classes does not behave like its parts; actually, it behaves
very differently. For example, a car consists of many other classes, one of which is a radio,
but a car does not behave like a radio
 Two major properties of a-part-of relationship are transitivity and anti
symmetry,

 • Transitivity. The property where, if A is part of B and B is part of C, then

A is part of C. For example, a carburetor is part of an engine and an engine
is part of a car; therefore, a carburetor is part of a car.

 • Antisymmetry. The property of a-part-of relation where, if A is part of

B,then . B is not part of A. For example, an engine is part of a car, but a car
is not part of an engine.
 A clear distinction between the part and the whole can help us determine where
responsibilities for certain behavior must reside.

 This is done mainly by asking the following questions :

 Does the part class belong to a problem domain?

 Is the part class within the system's responsibilities?

 Does the part class capture more than a single value? (If it captures only a single value, then
simply include it as an attribute with the whole class.)

 Does it provide a useful abstraction in dealing with the problem domain?

 We saw that the UML uses hollow or filled diamonds to represent aggregations. A filled diamond
signifies the strong form of aggregation, which is composition.

 For example, one might represent aggregation such as container and collection as hollow diamonds,
and use a solid diamond to represent composition, which is a strong form of aggregation.

A house is a container

 A football team is a collection of players

 Part-Of Relationship Patterns:

 To identify a-part-of structures, Coad and Yourdon provide the following

guidelines:

 • Assembly. An assembly is constructed from its parts and an assembly part

situation physically exists; for example, a French onion soup is an assembly of
onion, butter, flour, wine, French bread, cheddar cheese, and so on.

 • Container. A physical whole encompasses but is not constructed from

physical parts; for example, a house can be considered as a container for
furniture and appliances

 • Collection-member. A conceptual whole encompasses parts that may be

physical or conceptual; for example, a football team is a collection of players
Thank you