Object-Oriented Design Lecture 6: Finding Analysis Classes Sharif - - PowerPoint PPT Presentation

Department of Computer Engineering

1 Sharif University of Technology

Object-Oriented Design

Lecture 6: Finding Analysis Classes

Analysis Workflow: Analyze a Use Case

• The analysis workflow consists of the following activities:
• Architectural analysis
• Analyze a use case
• Outputs:
• analysis classes
• use case realizations
• Analyze a class
• Analyze a package

Sharif University of Technology 2

Analysis Classes: Typical Structure

• Analysis classes represent a crisp, well-defined abstraction in the

problem domain.

• Analysis classes include:
• a set of high-level candidate attributes
• a set of high-level operations

Sharif University of Technology 3

Good Analysis Classes

• What makes a good analysis class?
• Its name reflects its intent.
• It is a crisp abstraction that models one specific element of the problem

domain.

• It maps to a clearly identifiable feature of the problem domain.
• It has a small, well-defined set of responsibilities:
• a responsibility is a contract or obligation that a class has to its clients;
• a responsibility is a semantically cohesive set of operations;
• there should only be about three to five responsibilities per class.
• It has high cohesion - all features of the class should help to realize its

intent.

• It has low coupling - a class should only collaborate with a small number
• f other classes to realize its intent.

Sharif University of Technology 4

Bad Analysis Classes

• What makes a bad analysis class?
• A functoid - a class with only one operation.
• A stand-alone class - each class should be associated with a small number
• f other classes with which it collaborates to deliver the desired benefit.
• An omnipotent class - a class that does everything (classes with "system"
• r "controller" in their name may need closer scrutiny).
• A class with a deep inheritance tree - in the real world inheritance trees

tend to be shallow.

• A class with low cohesion.
• A class with high coupling.
• Many very small classes in a model – merging should be considered.
• Few but large classes in a model – decomposition should be considered.

Sharif University of Technology 5

Class Identification Techniques

• Noun/Verb Analysis (Grammatical Parsing)
• CRC Analysis
• Use-Case-Based Analysis
• Real-World Analysis

Sharif University of Technology 6

7

Order of activities in modeling

1.

Formulate a few scenarios with help from the end user and/or application domain expert.

2.

Extract the use cases from the scenarios, with the help of application domain expert.

3.

Analyse the flow of events, for example with Abbot's textual

analysis.

4.

Generate the class diagrams, which includes the following steps, as before:

• 1. Class identification (textual analysis, domain experts).
• 2. Identification of attributes and operations (sometimes before the classes

are found!)

• 3. Identification of associations between classes
• 4. Identification of multiplicities
• 5. Identification of roles
• 6. Identification of constraints

Noun/verb analysis (Grammatical Parsing)

• 1. Collect as much relevant information about the problem domain

as possible; suitable sources of information are:

• The requirements model
• The use case model
• The project glossary
• Any other document (architecture, vision documents, etc.)

2.Analyze the documentation:

• Look for nouns or noun phrases - these are candidate classes or

attributes.

• Look for verbs or verb phrases - these are candidate responsibilities or
• perations.
• 3. Make a tentative allocation of the attributes and responsibilities to

the classes. Sharif University of Technology

8

Sharif University of Technology 9

Example: Flow of events

 The customer enters a store with the intention of buying a toy

for his child with the age of n.

 Help must be available within less than one minute.  The store owner gives advice to the customer. The advice

depends on the age range of the child and the attributes of the toy.

 The customer selects a dangerous toy which is kind of

unsuitable for the child.

 The store owner recommends a more yellow doll.

10

Mapping parts of speech to object model components [Abbott, 1983]

Part of speech Model component Example Proper noun

• bject

Jim Smith Improper noun class Toy, doll Doing verb method Buy, recommend being verb inheritance is-a (kind-of) having verb aggregation has an modal verb constraint must be adjective attribute 3 years old transitive verb method enter intransitive verb method (event) depends on

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11

Generation of a class diagram from flow of events

 The customer enters the store

to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 Euro. He tries a videogame, which uses a data glove and a head- mounted display. He likes it. An assistant helps him. The suitability of the game depends

• n the age of the child. His

daughter is only 3 years old. The assistant recommends another type of toy, namely a boardgame. The customer buy the game and leaves the store type of toy customer depends store enters

Customer ? enter() toy daughter suitable *

less than 50 Euro

store enter() daughter age toy buy() videogame boardgame

toy age videogame daughter boardgame Flow of events:

toy price buy() like()

buy

Another Example

• The customer enters the store to buy a

toy.

• It has to be a toy that his daughter

likes and it must cost less than 50 Euro.

• He tries a videogame, which uses a

data glove and a head-mounted display. He likes it. An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type

• f toy, namely the boardgame

“Monopoly".

Flow of events: Is this a good use Case?

The use case should terminate with the customer leaving the store

Not quite!

Grammatical construct UML Component Concrete Person, Thing Object noun class verb Operation Classifying verb Inheritance Possessive Verb Aggregation modal Verb Constraint Adjective Attribute Intransitive verb Operation (Event)

Textual Analysis using Abbot‘s technique

Example “Monopoly" “toy" “enters" “is a" ,“either..or", “kind of…" "Has a ", “consists of" “must be", “less than…" "3 years old" “depends on…."

CRC Analysis – CRC Cards

• CRC – Class, Responsibilities, and Collaborators
• Important things in the problem domain are written on CRC Cards. Each Card

has three compartments:

• class - contains the name of the class
• responsibilities - contains a list of the responsibilities of that class (the functions it

performs and even the information it is responsible to keep and provide)

• collaborators - contains a list of other classes with which this class collaborates in
• rder to fulfill the responsibilities

Sharif University of Technology 14

CRC Analysis Procedure – Phase 1

• The participants are analysts, stakeholders, and domain experts.
• Phase 1: Brainstorm - gather the information:

1.Explain that this is a true brainstorm.

• 1. All ideas are accepted as good ideas.

2.Ideas are recorded but not debated. 2.Ask the team members to name the "things" that operate in their business domain -

for example, customer, product.

• 1. Write each thing on a sticky note; it is a candidate class, or attribute of a class.

2.Stick the note on a wall or whiteboard. 3.Ask the team to state responsibilities that those things might have; record these in

the responsibilities compartment of the note.

4.Working with the team, identify classes that might work together; record

collaborators in the collaborators compartment of the note.

15

CRC Analysis Procedure – Phase 2

• The participants are analysts and domain experts.
• Phase 2: Decide which sticky notes should become classes and which

should become attributes:

• Analysis classes must represent a crisp abstraction in the problem domain.

Certain sticky notes will represent key business concepts and clearly need to become classes.

• If a note logically seems to be a part of another note, this is a good

indication that it represents an attribute.

• If a note doesn't seem to be particularly important or has very little

interesting behavior, see if it can be made an attribute of another class.

• If in doubt about a note, just make it a class.

Sharif University of Technology 16

Use-Case-Based Analysis

• Complements other techniques
• Starts from an initial list of classes
• List of classes is perfected and refined based on use cases:
• Behavioral models are built showing use case realizations
• Classes are identified based on the objects needed for use case realizations: the

list of classes should provide instances which implement the behavior needed for the use cases;

• New classes will be added if needed
• Changes will be made to existing classes if required for use case realization

Sharif University of Technology 17

Use-Case-Based Analysis – Using RUP stereotypes

• RUP stereotypes can be used to focus analysis activity on three types of class

Sharif University of Technology 18

Naming of Object Types in UML

• UML provides several mechanisms to extend the language
• UML provides the stereotype mechanism to present new modeling

elements

<<Entity>> Year <<Entitity>> Month <<Entity>> Day <<Control>> ChangeDate <<Boundary>> Button

<<Boundary>> LCDDisplay

Entity Objects Control Objects Boundary Objects

World or system?

Recommended Naming Convention for Object Types

• To distinguish the different object types on a syntactical basis, we

recommend suffixes:

• Objects ending with the “_Boundary” suffix are boundary objects
• Objects ending with the “_Control” suffix are control objects
• Entity objects do not have any suffix appended to their name.

Year Month Day

ChangeDate_ Control

Button_Boundary LCDDisplay_Boundary

Recommended Diagrammatic Convention for Object Types

Real-World Analysis

• Explore the real world for classes:
• Candidates: physical objects, paperwork, interfaces to the outside world,

and conceptual entities;

• Physical objects: Things such as aircraft, people, and hotels may all

indicate classes.

• Paperwork: Things like invoices, orders, and bankbooks may all indicate

possible classes; beware of paperwork supporting the redundant business processes that the new system might be trying to replace.

• Known interfaces to the outside world: Things such as screens, keyboards,

peripherals, and other systems can be a source of candidate classes, especially for embedded systems.

• Conceptual entities: Things that are crucial to the operation of the

business but are not manifest as concrete things; such as enrollment, educational program, and alarm condition.

Sharif University of Technology 22

Analysis Model

• Create a first-cut analysis model:
• compare noun/verb analysis results with CRC results and the results of an

examination of other sources of classes.

• resolve synonyms and homonyms.
• differences between the results of the different techniques indicate areas
• f uncertainty.
• consolidate results into a first-cut analysis model.

Sharif University of Technology 23

Reference

• Arlow, J., Neustadt, I., UML 2 and the Unified Process: Practical Object-

Oriented Analysis and Design, 2nd Ed. Addison-Wesley, 2005.

Sharif University of Technology 24