UNIT III

Analysis

ÆUse case model
ÆApproaches for identifying classes
9 Noun Phrase approach
9 CRC
ÆIdentifying Object relationships-
case study.

Object Oriented Analysis Process:‐ Identifying Use Cases
Introduction
Æ1st step in finding an appropriate solution to a given problem 
statement is to understand the problem and its domain
ÆMain objective of the analysis is to capture a complete, 
unambiguous and inconsistent picture of the requirement of the 
system
ÆAnalysis: ‐ is the process of transforming a problem definition into 
a coherent statement of the system’s requirement. It involves great 
deal of interaction with people
ÆThe analyst has four major tools for extracting information about a 
system
1.Examination of existing system documentation
2.Interviews
3.Questionnaires
4.observation

 If the first try reflects error.Fuzzy descriptions 2. its associated constrains  and methods of overcoming those constraints ÆThe three most common source of requirement  difficulties  1.Incomplete requirements 3.Why Analysis is a difficult activity? ÆAnalysis is a creative activity that involves  understanding the problem.Unnecessary features ÆAnalysis is a difficult activity‐ we must understand  the problem in some application domain and then  define a solution that can be implemented with  software. refine the  application and try again .

Use Case driven OOA: The Unified approach:‐ ÆThe OOA phase of the UA uses actors and usecases  to  describe the system from the users perspective ÆActors‐ are external factor that interact with the  system ÆUsecases‐ are scenarios describe how actors use  the system .

The OOA process consists of following steps •Identifying the actors •Develop the usecase and activity diagram •Develop interaction diagram •Classification •Refine and iterate .

 planning and documentation of  system requirements ÆThe use case model describes the uses of the  system and shows the courses of events that can  be performed . it capture the goal of the user and the  responsibilities of the system to its users ÆUse‐case model can be instrumented in project  development.Use Case Model:‐ ÆUse cases are scenarios for understanding  system requirements ÆUse case – is an interaction  between users and  a system.

 not its  implementers(See the figure) ÆIt express what the business or application will do  and not how(representation of class diagram . association.  inheritance) . also  called object diagram/ object model – gives  relationship between objects.ÆIt can also discover classes and the relationships  among subsystem of the systems ÆIt can be developed by talking to typical users and  discussing the various things they might want to do  with the application being prepared ÆIt provides an external view of a system or  application it is directed primarily towards the users  or the “actors” of the system.

Library Borrow Books Return Books Inter Library loan Circulation Clerk Member Do Research Read Book. News  paper Purchase Supplies Supplier .

Use case under the Microscope:‐ ÆAn important issue that can assist us in  building correct use case is the  differentiation between users goal and  system interaction ÆUse case represent the things that the  user is doing with the system. which can be  different from the users goal .

ÆDefinition :‐ “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” •Use case – is a special flow of events through the systems •Actors ‐ is a  user playing a role with respect to the  system •In a system – means the actors communicate with  systems usecase •A measurable value ‐ a usecase must help the actor to  perform a task that has some identifiable values •Transaction – it is an atomic set of activities that are  performed either fully or not at all .

Library system has 3 actor and 7 use case s:‐ 3 Actors 7 Use cases 1. Read books / news paper  6. Do research   5. Purchase supplier 7.Circulation clerk 3. Get an inter liability loan 4. Return books 3.Supplier 2.Member 1.  Check library card . Borrow books 2.

Uses & Extends Associations:‐ Æ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 there is one  usecase that is similar to another use case but does  bit more ÆThe uses association occurs when describing the  usecase and notice that some of them have sub flows  in common .

Borrow Books Uses extends Check ID card Get an Interlibrary  loan Uses ÆSimilarity between uses and extends associations is  that both can be viewed as a kind of inheritance ÆShare‐ uses association.  little more additional work – extends association ÆUse cases could be viewed as concrete or abstract ÆAn abstract use case is not complete and has no  initiation actors but is used by concrete use case  which does interact with actors .

 how do users use the system? . it is important to think about roles rather  than people or job titles ÆA user may play more than one role ÆYou have to identify the actors and understand how they will use and  interact with the system ÆActors can also be found through the answers to the following  questions: •Who is using the system? •Who affects the system? •Which external hardware or other systems use the system to  perform task? •What problem does this application solve? •And finally.Identifying the actors:‐ ÆIdentifying classes is as important as identifying the classes.  structures. attributes and behavior ÆTerm actor represent the role of the user plays with respect to the  system ÆWhen dealing with actor. associations.

Can play a role of Performs Borrow  John Members Books Raja Employee Order Books Lili Volunteer Check ID USER ACTOR USE CASE DIFFERENCE   BETWEEN   USER   AND   ACTOR .

Guidelines for identifying the use cases:‐
ÆAfter defining the set of actors, next step is to 
describe the way they interact with the system
ÆThis should be carried out sequentially, but as 
iterated approach may be necessary
ÆSteps in finding the use cases
1.For each actor, find the task and function that 
the actor should be able to perform or that the 
system needs the actor to perform
2.Name the use cases
3.Describe the use cases briefly by applying terms 
with which the user is familiar

ÆOnce you have identified the use cases , it may not be 
apparent(clear) that all of these use cases need to be 
described separately; some may be modeled as the 
alternate of others
ÆIt is important to separate actors from users
ÆEach actor represents 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
ÆEach use case has only one main actors, to achieve this
•Isolate users from actors
•Isolate actors from other actors(separate the 
responsibilities of each actor)
•Isolate use cases that have different initiating actor 
slightly different behavior.

How detail must a use case be? When to stop 
Decomposing and when to continue?
ÆUse case, as already stated, describes the courses 
of event that will be carried out by the system
ÆDuring analysis of a business system, we can 
develop one use case diagram as the system use case 
and draw packages on the usecase to represent the 
various business domain of the system
ÆSingle project , no: of use case depends upon the 
problem
ÆTo get a good solution in analysis phase the 
decomposition of usecase can be performed until it 
cannot be decomposed

Dividing use cases into packages:‐ ÆEach use case represent a particular scenario in the  system ÆA design is broken down into packages ÆEach packages going to do some set of operations Borrow Book Do Research Purchase Uses Borrow Books Check ID card Get an Interlibrary  loan Uses Return Books Member Borrow Books  denied .

Naming a Use Case:‐ ÆUse case names should provide a general  description of the use case function ÆName should express what happens when an  instance of the usecase is performed ÆThe description of the use case should be  descriptive and consistent .

Object Analysis Classification .

Object Analysis: Classification:‐ Introduction:‐ ÆOOA is a process by which we can identify  classes that play a role in achieving system  goals and requirements ÆIdentification of classes is the hardest part  of OOA and Design .

 employer …. methods and  applicability of its instance ÆIt is fairly nature to partition the world into objects that  have properties(attributes) and methods(behavior) ÆA class is a specification of structure .Classification Theory:‐ ÆClassification. employee. woman. Eg human being classification of  car ÆClasses are important mechanism for classifying objects ÆChief role of a class is to define the attributes. behavior and the  description of an object ÆClassification on concerned more with identifying the class  of an object than the individual object within a system ÆEg Betty – owner. is regarded as a basic  attribute of human nature. . the process of checking to see if an object  belongs to a category or a class.

 sequence/collaboration modeling  approach 4. Responsibilities and collaborators(CRC)  approach . Noun phrase approach 2. Classes. Common class patterns approach 3. Use – case driven.Approaches for identifying the classes:‐ ÆThere are four approaches for identifying classes 1.

Fuzzy classes(class that are not sure about) 3. we read through the requirement  of use cases looking for noun phrases ÆNouns in the textual description are constructed to  be classes and verbs to be methods of the classes ÆAll plurals are changed to singular. Brain  and Lauren ÆIn this method.Irrelevant classes R.C F.Noun Phrase Approach:‐ ÆProposed by Rebecca.C IR.1.Relevant classes 2. the nouns are  listed and the list divided into three categories 1.C .

ÆIt is safe to swap the irrelevant classes . avoid computer implementation classes •carefully choose and define class names ÆFinding class is not easy. which either have  no purpose or will be unnecessary 9Identifying tentative classes Æ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. it is an incremental and  iterative process .

 Adjective can suggest a different kinds of  object. 9Selecting classes from the relevant and fuzzy categories Æ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 •Adjective classes:‐ Adjectives can be used in many  ways.  different use of the same object or it could  be utterly irrelevant •Attribute Classes:‐ tentative objects that are used  only as values should be defined or restated as  attributes and not as a class •Irrelevant Classes:‐ each class must have a purpose  or every class should be clearly defined and  necessary .

 the  process of identifying relevant classes and eliminating  irrelevant classes is an incremental process ÆClassification is the essence of good OOA & D ÆThe process of eliminating the redundant classes and  refining the remaining classes is not sequential Æ It can be moved back and forth among these steps (figure)  as often as we like Review Redundant class Review irrelevant classes Review adjectives Review attributes .Æ Like any other activity of software development.

 Performance is an example of concept class  object . Common Class Patterns Approach:‐ ÆSecond method for identifying classes is using Common Class  Patterns. Ross…. ÆFollowing are the list of patterns for finding the candidate  classes and objects 1.Name: Concept class:‐ •ContextÆ A concept is a particular idea  or understanding  that we have for our world ÆThe concept class encompasses principles that are  not tangible but used to organize or keep  track of business activities or communication Æ Privately held ideas or notions are called  conceptions Eg.2. which is based on a knowledge base of the common  classes that have been proposed by various researchers. such as  Metter.

 request and order are  possible events 3. resources. how etc Eg. what . Name: Organization Class:‐ ContextÆ An organization class is a collection of  people. usually to something else at a  given data AND TIME ÆAssociated attributes – who. why. Landing. when.2. An accounting department might be  considered a potential class . Name : Event Class:‐ ContextÆ Events c lasses are points in time must be  recorded ÆThings happen. facilities or groups to  which the user belongs. Eg.  where. interrupt.

Name: Places Class:‐ ContextÆ places are physical location that the system  must keep information about Eg. Those representing people who do not  use the system Eg. roles and  roles played class) ContextÆ people class represents the different roles  users play in interacting with the application Æpeople carry out some function Æperson can be divided into two types 1. teacher 5. Those representing users of the system 2. Building. stores. client. Name: People class:‐ (also known as person.4. Employee. sites. offices .

6. Cars – eg for tangible things Pressure – eg for an device .Name: Tangible things and devices  class:‐ ContextÆ this class includes physical objects or  groups of object that are tangible  and devices with which the  application interacts Eg.

3. it is an recommended aid in finding  the object of the system . Use Case Driven Approach: Identifying Classes and  their behavior through sequence / collaboration  modeling:‐ ÆUse cases are employed to model the scenarios in  the system and specify what external actors interact  with the scenario ÆScenario – are explained in text or sequence of  steps ÆUse case modeling is considered as problem driven  approach to OOA.

9Implementation of scenarios:‐ Æ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. we can model  the implementation of the scenario Æuse case diagram – steps are just textual description defines  high‐level view of a system Æsequence diagram – enables the interaction between objects  in the system . we may create a  child sequence diagram or accompanying collaboration diagram for the  use case Æwith the sequence and collaboration diagrams. will all decision definite ÆThis process helps to understand the behavior of the systems  object Æwhen arrived at the lowest use case level.

4. beck Æwas is presented as a way of teaching the basic concepts of  OOD ÆCRC—is a technique used for identifying classes.  responsibilities and therefore their attributes and methods ÆIt is more a teaching technique than a method for  identifying classes ÆIt is based on the idea that an object either can accomplish  a certain responsibility itself or it may require the assistant of  other objects ÆIf it requires the assistance of other objects. Classes. Responsibilities and collaborators  (CRC):‐ Ædeveloped by Cunningham. it must  collaborate with those object to fulfill its responsibility .

ÆClass name – appear in the upper left hand corner ÆBulleted list of responsibilities should appear under it in the left two  thirds of the card ÆAnd list of c collaborators in the right side ÆCRC stresses the importance of creating objects . portable.ÆBy identifying an objects responsibilities and collaborators we can  identify its attributes and methods ÆCRC card are 4″ X 6″ index cards ÆAll information are written in the card which is cheap. …………..  readily available and familiar ÆFollowing figure shows the card Class Name Collaborators Responsibilities …………..

9CRC Process:‐ ÆIt consists of 3 steps as shown in the figure Identify Classes  &  Responsibilities Iterate Identify  Assign  Collaboration Responsibility 1. which also provides candidates for super  classes . Assign responsibility 3. Identify collaborators ÆClasses are identified and grouped by common  attributes. Identifying classes and responsibility 2.

 the  card also notes sub and super classes to show  the class structure ÆApplications requirements then are examined  for actions and information associated with each  class to find the responsibilities of each class ÆNext. Classes that have a close  collaboration are grouped together physically . they  should be as general as possible and placed as  high as possible in inheritance hierarchy Æthe idea in locating collaborators is to identify  how classes interact.ÆClass names are written onto CRC Cards. the responsibilities are distributed.

 select name with which client will  be comfortable c) Name of the class should reflect its intrinsic  nature(belonging to the basic nature of  something) d)Use readable names. capitalize class name .Naming Classes:‐ ÆNaming a class is an important activity ÆSome guidelines for naming the classes are:‐ a)Class name should be singular b)Choose name from standard vocabulary for the  subject matter.

Identifying object  relationship. attributes and  methods .

 these interactions and relationships are the  application Ærelationship among object is based on the assumption each  makes about the other object t Æ3 types of relationships among objects are 1. object take on an active role in a  system Æobject do not exist in isolation but interact with each other  indeed. Association(designing classes) 2. attributes and  methods:‐ Introduction:‐ Æin OO environment. Super sub structure (direction of inheritance) 3.Identifying object relationship. Aggregation and a part of structure (defining  mechanism that property manage object within object) .

 the two class  have an association relationship ÆBasic association representation Association Name Class A Class B Role Of A Role Of B . Associations:‐ ÆIt represent a physical or conceptual connection between  two or more objects ÆEg if an object has the responsibility for telling another  object that a credit card no: is valid or invalid.1.

From other classes can it acquire what it need? . then the object must  delegate the task to another object that possesses such  knowledge ÆTo identify the association answer the following  questions 1. Is the class capable of fulfilling the required task  by itself? 2.•Identifying Associations:‐ ÆIt begins by analyzing the interaction between  classes ÆAny dependency relationship between two or more  classes is an association ÆIf an object is responsible for a specific  task(behavior) and lacks all necessary knowledge  needed to perform the task. If not. what does it need? 3.

  works for or contained in  2. Some associations are implicit or taken  from general knowledge .•Guidelines for identifying association:‐ ÆIdentifying association begins by analyzing the  interactions between classes ÆAny dependency relationship between two or more  classes is an association ÆFollowing are the general guidelines for identifying the  tentative associations: 1. next to. such as part of. A reference from one class to another is an  association. A dependency between two or more classes may be  an association. Association often corresponds to a  verb or prepositional phrase.

 Customer places an order to person Customer Person Order . part of. Location association:‐ next to. Location association 2.•Common Association pattern:‐ ÆThe common association pattern are based on some of the  common association defined by researchers and practioners ÆThese include:‐ 1. order to Eg.Communication association:‐ talk to. Break – a part of – a car 2. Communication association 1. contained in Eg.

 Grand  parent of – can be defined in terms of the parent of  association Grand parent of X Y . Eg.•Eliminating unnecessary associations:‐ 9Implementation association:‐ Are concerned with the implementation or design of the class  within certain program or development environment and not  relationships among business objects 9Ternary association:‐ Ternary or n‐ary association is an association among more  than two classes 9Directed (or derived) association:‐ It can be defined in terms of other associations.

Super – Sub class relationship:‐ ÆOther aspect of classification is identification of  super‐sub relationship among classes Æ In this the top class is most general one and from it  descend all other. more specialized class ÆSuper‐sub class relation represents the inheritance  relationship between related classes It is also called as generalized hierarchy. aloe object to  built from other objects ÆParent’s class‐ also called as base/super/ancestor .

 A phone operator employee can be represented as a cook  as well as a clerk or manager because they all have similar  behavior . Multiple inheritance 1. Top‐ down 2.•Guidelines for identifying super‐sub relationship. Bottom ‐up 3. Reusability 4. a  Generalization:‐ ¾Following are guidelines for identifying super‐sub  relationship in the application 1.Top – down:‐ look for noun phrases composed of  various adjectives in a class name Eg.

Reusability:‐ more attributes and methods as  high as possible in the hierarchy. Bottom – up:‐ look for classes with similar  attributes or methods and put them together  in a common abstract class 3.Multiple inheritance:‐ avoid excessive use of  multiple inheritance .2. Do not create  very specialized classes at the top of the  hierarchy 4.

  represents the situation when a class consists of  several component classes ÆA class that is composed of other classes does not  behave like its parts. but behaves differently Æeg.A‐Part‐Of Relationships – Aggregation:‐ ÆA‐part‐of relationship. also called aggregation. Car consists of many other classes. but a car does not behave like a radio Car Engine Radio Carbura tor . one of which  is radio.

 an engine is part of car. if A is part of B  and B is part of C. then B is not part of A. then A is part of C Eg.Ætwo major properties of a‐part of relationship are  transitivity and antisymmetry 1.Antisymmetry:‐ the property of a‐part‐of relation  where if A is part of B. but a car is not  a part of an engine . Carburetor is part of car 2.Transitivity:‐ the property where. Eg.

 eg soup 2.Container 3.Collection‐member:‐ A conceptual whole  encompasses parts that may be physically or  conceptual.Assembly 2. 9A‐Part‐Of relationship Pattern:‐ ÆFollowing guidelines are used to identity a‐ part‐of structure 1. Eg House 3.Collection‐member 1.Container:‐ A physical whole encompasses but  is not constructed from physical parts.Assembly:‐ It is constructed from its parts and  an assembly part situation physically exists. Eg football team .

Class Responsibility:‐ Identifying Attributes and  methods:‐ ÆIdentifying attributes and method is like finding classes. still a  difficult activity and an iterative process ÆOnce again use case and other UML diagrams will be our guide  for identifying attributes.  cost and manufacturer ÆIdentifying attributes of a systems classes starts with  understanding the systems responsibilities ÆFollowing questions help in identifying the responsibilities of  classes and deciding what data elements to keep track of:‐ 1. What information about an object should we keep track of? 2. What services must a class provide? . methods and relationship among the  classes ÆResponsibilities identify problems to be solved ÆAttributes are things an object must remember such as color.

 we can begin to understand  classes. Responsibilities is the key issues ÆUsing previous OOA results for analysis patterns can be   extremely useful in finding out what attributes can be reused  directly and what lessons can be learned for identifying  attributes . therefore. responsibilities and how they must interact to  perform their tasks.\ ÆMain goal here is to understand want the class is  responsible for knowing.  activity and state diagrams.Class Responsibility:‐ Defining attributes by analyzing  usecases and other UML diagrams:‐ ÆAttributes can be derived from scenario testing.  by analyzing the usecases and sequence/collaboration.

 Attributes also may  correspond to adjectives/adverbs •Keep the class simple.9Guidelines for defining attributes:‐ ÆSome of the guidelines for identifying attributes  of classes in use cases: •Attributes usually correspond to nouns  followed by prepositional phrases such as  cost of the soup. state only enough  attributes to define the object state •Attributes are less likely to be fully described  in the problem statement •Omit derived attributes •Do not carry discovery of attributes to excess .

ÆThese methods do everything from printing the object to  initializing its variables ÆEvery class is responsible for storing certain information from the  domain knowledge ÆIt also is logical to assign the responsibility for performing any  operation necessary on that information ÆOperations(method/behavior) in the OO system usually  correspond to quieries about attributes of the objects ÆIn other words.Object Responsibility: Methods and Messages:‐ ÆObjects not only describe abstract data but also must provide  some services ÆMethods and messages are the workhorses of OO system ÆIn an OO environment. methods are responsible for managing the values  of attributes such as query. updating. every piece of data. or object is  surrounded by a rich set of routines called methods. reading and writing .

 the objects involved are  drawn on the drag as vertical dashed lines. these action are operation that the object  must perform and as in the attributes. methods also  can be derived from scenario testing ÆSequence diagram can assist in defining te services  the object must provide.9Defining methods by analyzing UML diagrams  and Use cases ÆIn a sequence diagram. . the events  that occur between object are drawn between the  vertical object lines ÆAn event is considered to be an action that transmits  information.

• What is the common class pattern strategy • Why is identifying classes an incremental process? • What is association? Give an example. fuzzy and irrelevant classes. • How would you identify a super‐subclass structure? • What are some common Associations and common Aggregations? • How would you identify Associations? • What are the guidelines for finding use cases? • What are the guidelines for developing effective documentation? .Review Questions • What is the difference between users and actors? • What is a use ‐case model? Why is use case modeling useful in analysis? • How would you identify the actors? • What are the guidelines for identifying tentative classes in a problem domain? • Describe relevant. • Is association different from an apart of relation Justify your answer.

Bibliography • Object oriented system development by Ali  Brahami • Object oriented methodology by Booch • A text book on UML by Srimathi .