unit analysis - india’s premier educational institution1).pdf · Æmain objective of the analysis...

60
UNIT III Analysis

Upload: doantuong

Post on 18-Jun-2018

213 views

Category:

Documents


0 download

TRANSCRIPT

UNIT IIIAnalysis

Use case modelApproaches for identifying classes

Noun Phrase approachCRC

Identifying Object relationships-case study.

Object Oriented Analysis Process:‐ Identifying Use CasesIntroduction1st step in finding an appropriate solution to a given problem 

statement is to understand the problem and its domainMain objective of the analysis is to capture a complete, 

unambiguous and inconsistent picture of the requirement of the systemAnalysis: ‐ is the process of transforming a problem definition into 

a coherent statement of the system’s requirement. It involves great deal of interaction with peopleThe analyst has four major tools for extracting information about a 

system1.Examination of existing system documentation2.Interviews3.Questionnaires4.observation

Why Analysis is a difficult activity?Analysis is a creative activity that involves 

understanding the problem, its associated constrains and methods of overcoming those constraintsThe three most common source of requirement 

difficulties 1.Fuzzy descriptions2.Incomplete requirements3.Unnecessary featuresAnalysis is a difficult activity‐ we must understand 

the problem in some application domain and then define a solution that can be implemented with software. If the first try reflects error, 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 perspectiveActors‐ are external factor that interact with the 

systemUsecases‐ 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

Use Case Model:‐Use cases are scenarios for understanding 

system requirementsUse case – is an interaction  between users and 

a system; it capture the goal of the user and the responsibilities of the system to its usersUse‐case model can be instrumented in project 

development, planning and documentation of system requirementsThe use case model describes the uses of the 

system and shows the courses of events that can be performed

It can also discover classes and the relationships among subsystem of the systemsIt can be developed by talking to typical users and 

discussing the various things they might want to do with the application being preparedIt provides an external view of a system or 

application it is directed primarily towards the users or the “actors” of the system, not its implementers(See the figure)It express what the business or application will do 

and not how(representation of class diagram , also called object diagram/ object model – gives relationship between objects, association, inheritance)

Borrow Books

Return Books

Inter Library loan

Do Research

Read Book, News paper

Purchase Supplies

Library

Member

Circulation Clerk

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 interactionUse 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 cases1.Member 1. Borrow books2.Supplier 2. Return books3.Circulation clerk 3. Get an inter liability loan

4. Do research  5. Read books / news paper 6. Purchase supplier7.  Check library card

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 outA way to simplify the description is, to take 

advantage of extends and uses associationsThe extends association is used when there is one 

usecase that is similar to another use case but does bit moreThe uses association occurs when describing the 

usecase and notice that some of them have sub flows in common

Similarity between uses and extends associations is that both can be viewed as a kind of inheritanceShare‐ uses association; little more additional work – extends associationUse cases could be viewed as concrete or abstractAn abstract use case is not complete and has no 

initiation actors but is used by concrete use case which does interact with actors

Borrow Books

Check ID card

Get an Interlibrary loan

extends

Uses

Uses

Identifying the actors:‐Identifying classes is as important as identifying the classes, 

structures, associations, attributes and behaviorTerm actor represent the role of the user plays with respect to the 

systemWhen dealing with actor, it is important to think about roles rather 

than people or job titlesA user may play more than one roleYou have to identify the actors and understand how they will use and 

interact with the systemActors 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, how do users use the system?

John

Raja

Lili Volunteer

Employee

Members

Check ID

Order Books

Borrow Books

Can play a role of

USER ACTOR USE CASE

Performs

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 systemThis should be carried out sequentially, but as 

iterated approach may be necessarySteps in finding the use cases1.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 cases3.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 othersIt is important to separate actors from usersEach 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 wayEach 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 systemDuring 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 systemSingle project , no: of use case depends upon the 

problemTo 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 

systemA design is broken down into packagesEach packages going to do some set of operations

Borrow Book Do Research Purchase

Borrow Books

Check ID card

Get an Interlibrary loan

Uses

Uses

Member Borrow Books denied

Return Books

Naming a Use Case:‐Use case names should provide a general 

description of the use case functionName should express what happens when an 

instance of the usecase is performedThe description of the use case should be 

descriptive and consistent

Object AnalysisClassification

Object Analysis: Classification:‐Introduction:‐OOA is a process by which we can identify 

classes that play a role in achieving system goals and requirementsIdentification of classes is the hardest part 

of OOA and Design

Classification 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. Eg human being classification of carClasses are important mechanism for classifying objectsChief role of a class is to define the attributes, methods and 

applicability of its instanceIt is fairly nature to partition the world into objects that 

have properties(attributes) and methods(behavior)A class is a specification of structure , behavior and the 

description of an objectClassification on concerned more with identifying the class 

of an object than the individual object within a systemEg Betty – owner, woman, employee, employer ….

Approaches for identifying the classes:‐There are four approaches for identifying classes1. Noun phrase approach2. Common class patterns approach3. Use – case driven, sequence/collaboration modeling approach

4. Classes, Responsibilities and collaborators(CRC) approach

1.Noun Phrase Approach:‐Proposed by Rebecca, Brain  and LaurenIn this method, we read through the requirement 

of use cases looking for noun phrasesNouns in the textual description are constructed to 

be classes and verbs to be methods of the classesAll plurals are changed to singular, the nouns are 

listed and the list divided into three categories1.Relevant classes2.Fuzzy classes(class that are not sure about)3.Irrelevant classes

IR.CF.CR.C

It is safe to swap the irrelevant classes , which either have no purpose or will be unnecessary

Identifying tentative classesFollowing 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•carefully choose and define class names

Finding class is not easy, it is an incremental and iterative process

Selecting classes from the relevant and fuzzy categoriesFollowing 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. Adjective can suggest a different kinds of object,  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

Like any other activity of software development, the process of identifying relevant classes and eliminating irrelevant classes is an incremental processClassification is the essence of good OOA & DThe process of eliminating the redundant classes and 

refining the remaining classes is not sequentialIt can be moved back and forth among these steps (figure) 

as often as we like

Review Redundant class

Review adjectivesReview irrelevant classes

Review attributes

2. Common Class Patterns Approach:‐Second method for identifying classes is using Common Class 

Patterns, which is based on a knowledge base of the common classes that have been proposed by various researchers, such as Metter. Ross….Following are the list of patterns for finding the candidate 

classes and objects1.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 conceptionsEg. Performance is an example of concept class object

2. Name : Event Class:‐Context Events c lasses are points in time must be 

recordedThings happen, usually to something else at a 

given data AND TIMEAssociated attributes – who, what , when, 

where, why, how etcEg. Landing, interrupt, request and order are possible events

3. Name: Organization Class:‐Context An organization class is a collection of 

people, resources, facilities or groups to which the user belongs.Eg. An accounting department might be considered a potential class

4. Name: People class:‐ (also known as person, roles and roles played class)

Context people class represents the different roles users play in interacting with the applicationpeople carry out some functionperson can be divided into two types

1. Those representing users of the system2. Those representing people who do not use the system

Eg. Employee, client, teacher5.Name: Places Class:‐

Context places are physical location that the system must keep information about

Eg. Building, stores, sites, offices

6.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. Cars – eg for tangible thingsPressure – eg for an device

3. 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 scenarioScenario – are explained in text or sequence of 

stepsUse case modeling is considered as problem driven 

approach to OOA, it is an recommended aid in finding the object of the system

Implementation of scenarios:‐UML specification recommends that at least one scenario be 

prepared for each significantly different use case instanceEach scenario shows a different sequence of interaction 

between actors and the system, will all decision definiteThis process helps to understand the behavior of the systems 

objectwhen arrived at the lowest use case level, we may create a 

child sequence diagram or accompanying collaboration diagram for the use case

with the sequence and collaboration diagrams, 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

4. Classes, Responsibilities and collaborators (CRC):‐developed by Cunningham, beckwas is presented as a way of teaching the basic concepts of 

OODCRC—is a technique used for identifying classes, 

responsibilities and therefore their attributes and methodsIt is more a teaching technique than a method for 

identifying classesIt is based on the idea that an object either can accomplish 

a certain responsibility itself or it may require the assistant of other objectsIf it requires the assistance of other objects, it must 

collaborate with those object to fulfill its responsibility

By identifying an objects responsibilities and collaborators we can identify its attributes and methodsCRC card are 4″ X 6″ index cardsAll information are written in the card which is cheap, portable, 

readily available and familiarFollowing figure shows the card

Class name – appear in the upper left hand cornerBulleted list of responsibilities should appear under it in the left two 

thirds of the cardAnd list of c collaborators in the right sideCRC stresses the importance of creating objects

Class Name

Responsibilities…………..

Collaborators

…………..

CRC Process:‐It consists of 3 steps as shown in the figure

1. Identifying classes and responsibility2. Assign responsibility3. Identify collaboratorsClasses are identified and grouped by common 

attributes, which also provides candidates for super classes

Identify Classes & 

Responsibilities

Assign Responsibility

Identify Collaboration

Iterate

Class names are written onto CRC Cards, the card also notes sub and super classes to show the class structureApplications requirements then are examined 

for actions and information associated with each class to find the responsibilities of each classNext, the responsibilities are distributed, they 

should be as general as possible and placed as high as possible in inheritance hierarchythe idea in locating collaborators is to identify 

how classes interact. Classes that have a close collaboration are grouped together physically

Naming Classes:‐Naming a class is an important activitySome guidelines for naming the classes are:‐a)Class name should be singularb)Choose name from standard vocabulary for the subject matter, 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

Identifying object relationship, attributes and 

methods

Identifying object relationship, attributes and methods:‐Introduction:‐in OO environment, object take on an active role in a 

systemobject do not exist in isolation but interact with each other 

indeed, these interactions and relationships are the applicationrelationship among object is based on the assumption each 

makes about the other object t3 types of relationships among objects are1. Association(designing classes)2. Super sub structure (direction of inheritance)3. Aggregation and a part of structure (defining mechanism that property manage object within object)

1. Associations:‐It represent a physical or conceptual connection between 

two or more objectsEg if an object has the responsibility for telling another 

object that a credit card no: is valid or invalid, the two class have an association relationshipBasic association representation

Class A Class BAssociation Name

Role Of A Role Of B

•Identifying Associations:‐It begins by analyzing the interaction between 

classesAny dependency relationship between two or more 

classes is an associationIf an object is responsible for a specific 

task(behavior) and lacks all necessary knowledge needed to perform the task, then the object must delegate the task to another object that possesses such knowledgeTo identify the association answer the following 

questions1. Is the class capable of fulfilling the required task by itself?

2. If not, what does it need?3. From other classes can it acquire what it need?

•Guidelines for identifying association:‐Identifying association begins by analyzing the 

interactions between classesAny dependency relationship between two or more 

classes is an associationFollowing are the general guidelines for identifying the 

tentative associations:1. A dependency between two or more classes may be an association. Association often corresponds to a verb or prepositional phrase, such as part of, next to, works for or contained in 

2. A reference from one class to another is an association. Some associations are implicit or taken from general knowledge

•Common Association pattern:‐The common association pattern are based on some of the 

common association defined by researchers and practionersThese include:‐1. Location association2. Communication association

1. Location association:‐ next to, part of, contained inEg. Break – a part of – a car

2.Communication association:‐ talk to, order toEg. Customer places an order to person

Customer Person

Order

•Eliminating unnecessary associations:‐Implementation association:‐

Are concerned with the implementation or design of the class within certain program or development environment and not relationships among business objects

Ternary association:‐Ternary or n‐ary association is an association among more than two classes

Directed (or derived) association:‐It can be defined in terms of other associations. Eg. Grand parent of – can be defined in terms of the parent of association

X YGrand parent of

Super – Sub class relationship:‐Other aspect of classification is identification of 

super‐sub relationship among classesIn this the top class is most general one and from it 

descend all other, more specialized classSuper‐sub class relation represents the inheritance 

relationship between related classesIt is also called as generalized hierarchy, aloe object to built from other objectsParent’s class‐ also called as base/super/ancestor

•Guidelines for identifying super‐sub relationship, a Generalization:‐

Following are guidelines for identifying super‐sub relationship in the application

1. Top‐ down2. Bottom ‐up3. Reusability4. Multiple inheritance

1.Top – down:‐ look for noun phrases composed of various adjectives in a class name

Eg. A phone operator employee can be represented as a cook as well as a clerk or manager because they all have similar behavior

2. Bottom – up:‐ look for classes with similar attributes or methods and put them together in a common abstract class

3.Reusability:‐more attributes and methods as high as possible in the hierarchy. Do not create very specialized classes at the top of the hierarchy4.Multiple inheritance:‐ avoid excessive use of multiple inheritance

A‐Part‐Of Relationships – Aggregation:‐A‐part‐of relationship, also called aggregation, 

represents the situation when a class consists of several component classesA class that is composed of other classes does not 

behave like its parts; but behaves differentlyeg. Car consists of many other classes, one of which 

is radio, but a car does not behave like a radio

Car

Carburator

Engine Radio

two major properties of a‐part of relationship are transitivity and antisymmetry

1.Transitivity:‐ the property where, if A is part of B and B is part of C, then A is part of C

Eg. Carburetor is part of car2.Antisymmetry:‐ the property of a‐part‐of relation where if A is part of B, then B is not part of A.

Eg. an engine is part of car, but a car is not a part of an engine

A‐Part‐Of relationship Pattern:‐Following guidelines are used to identity a‐

part‐of structure1.Assembly2.Container3.Collection‐member

1.Assembly:‐ It is constructed from its parts and an assembly part situation physically exists; eg soup

2.Container:‐ A physical whole encompasses but is not constructed from physical parts. Eg House

3.Collection‐member:‐ A conceptual whole encompasses parts that may be physically or conceptual. Eg football team

Class Responsibility:‐ Identifying Attributes and methods:‐Identifying attributes and method is like finding classes, still a 

difficult activity and an iterative processOnce again use case and other UML diagrams will be our guide 

for identifying attributes, methods and relationship among the classesResponsibilities identify problems to be solvedAttributes are things an object must remember such as color, 

cost and manufacturerIdentifying attributes of a systems classes starts with 

understanding the systems responsibilitiesFollowing 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?

Class Responsibility:‐ Defining attributes by analyzing usecases and other UML diagrams:‐Attributes can be derived from scenario testing; therefore, 

by analyzing the usecases and sequence/collaboration, activity and state diagrams, we can begin to understand classes, responsibilities and how they must interact to perform their tasks.\Main goal here is to understand want the class is 

responsible for knowing. Responsibilities is the key issuesUsing 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

Guidelines 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. Attributes also may correspond to adjectives/adverbs•Keep the class simple; 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

Object Responsibility: Methods and Messages:‐Objects not only describe abstract data but also must provide 

some servicesMethods and messages are the workhorses of OO systemIn an OO environment, every piece of data, or object is 

surrounded by a rich set of routines called methods.These methods do everything from printing the object to 

initializing its variablesEvery class is responsible for storing certain information from the 

domain knowledgeIt also is logical to assign the responsibility for performing any 

operation necessary on that informationOperations(method/behavior) in the OO system usually 

correspond to quieries about attributes of the objectsIn other words, methods are responsible for managing the values 

of attributes such as query, updating, reading and writing

Defining methods by analyzing UML diagrams and Use cases

In a sequence diagram, the objects involved are drawn on the drag as vertical dashed lines, the events that occur between object are drawn between the vertical object linesAn event is considered to be an action that transmits 

information, these action are operation that the object must perform and as in the attributes, methods also can be derived from scenario testingSequence diagram can assist in defining te services 

the object must provide.

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, fuzzy and irrelevant classes.• What is the common class pattern strategy• Why is identifying classes an incremental process?• What is association? Give an example.• Is association different from an apart of relation Justify your answer.• 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?

Bibliography

• Object oriented system development by Ali Brahami

• Object oriented methodology by Booch

• A text book on UML by Srimathi