Workshop for CS-AP Teachers

Georgia Institute of Technology

Workshop for CS-AP Teachers

Chapter 2

Object-Oriented Analysis


Objectives

• What is the purpose of analysis?• Why should we do object-oriented analysis?• What are the things that must be done in

analysis?• Apply analysis to real-world problems• What are some analysis techniques?


Analysis Purpose• Understand the

application domain – An object-oriented

program is a simulation of the domain

• We can’t create a simulation until we know the domain

• Understand the needs of different users – We can’t create software

people will use • until we know who

wants to use it and what they want to do with it


Analysis is Important

• O-O development does not mean: “program first, design later”– If you do not understand what users need, writing

a program is a waste of time

• What are the Analysis Models for?– Aid understanding of the application by both

developers and users– Determine the feasibility of a proposed system and

the boundaries of the system– Serve as a basis for designing the system


Structured Analysis vs. O-O Analysis

• Traditional Structured Analysis and Design arose from abstraction from the design of computer hardware– Von Neuman computers:

Assember(Load, Store, Jump,Jump to Subroutine)

60’s Flowcharts

70’s Structured Programming & Structured Data(Programs = Algorithms + Data)

80’s Structured Analysis & Design


Problems with Structured Analysis

• Structured analysis tried to fit people’s problems to computer science solutions– Unfortunately, very few organizations or

applications are organized like these solutions!– People are increasingly unwilling to change to

accommodate a solution that does not meet their needs

• The fundamental problem is that it decouples data and processing. – This makes it difficult to handle changes, clouds

understanding, obstructs reuse, and doesn’t scale well.


Example of Structured Analysis

• Tackling these problems separately is seductively simple

• ??? Why is the above structure chart and corresponding structured program difficult to adapt to:– Changes in employee data– New types of employees


Why use Object-Oriented Analysis?

• The universality of objects in the application domain suggests that they should be the basis for analysis

• Focusing on objects helps in understanding the domain– Class names, attributes, and relationships

between classes are specified and not assumed

• Objects change less than procedures– Easier to localize changes


Object-Oriented Analysis

• Focuses on problem space understanding• Creates models are potentially intelligible to

both users and developers• Treats object attributes and behaviors as

indivisible• Reduces coupling in system partitioning• Has an explicit representation of

commonality: inheritance• Encapsulate external interfaces using objects• Leads well to object-oriented design


Object-Oriented Analysis Process

• Identify candidate objects and their classes– What objects are in the domain and their classes?

• Document classes– What is a class responsible for?

• Determine the relationships between classes – Construct a class diagram

• Define the boundaries of the system– What is in your system and what is external?

• Identify the users and their goals– Gather high-level use cases


OO Analysis Process

• These steps can proceed in parallel and are inter-related– Doing one step improves our understanding of and

modifies the results of other steps– Therefore analysis is not a linear process

Find classes in requirements

Gatherhigh-level use cases

Revise classesbased on usecases


Identifying Classes • To identify classes ask

what are the things talked about in the domain?

• What classes might be found in these domains?– Databases?– Graphical User

Interfaces?– ATM (Automatic Teller

Machine)?


Some Possible ATM Classes

Class Data Operations

CardReader validate_card()get_account()

Account balance withdraw()deposit()

CashDispenser bills_in_stock dispense_cash()update_bills_in_stock()

DepositReceiver open_door()receive_deposit()close_door()

ReceiptPrinter paper_in_stock print_header()print_transaction()eject_receipt()


Drawing Editor Exercise• Identify the classes for a simple drawing editor. Also

show the data and operations for the classes. – The editor can draw rectangles, circles, and triangles. It can

show connections between shapes with a a line. The shapes can be erased, moved, and rotated.


Drawing Editor ExerciseClass Data Operations


Work Area for Exercise


Drawing Editor Class Diagram

• What do these classes have in common?• Is any class “a kind of” another class?

Circle

radius center

draw() move()

Rectangle

width height centerdraw() move() rotate()

Triangle

points center

draw() move() rotate()


Factoring Out a Parent Class• Create the Shape class to factor out common

behavior and data

Circleradius

draw() move()

Rectanglewidth height

draw() move()

Trianglepoints

draw() move()

Shapecenter

draw() move() rotate()

abstractabstract

{do nothing}


Defining Methods in the Base Class• By defining some of the operations in Shape as

abstract we can define the erase and move methods.

Circleradius

draw()

Rectanglewidth height

draw() rotate()

Trianglepoints

draw() rotate()

Shapecenter

draw() move() rotate() erase()

abstract{erase self set center draw self}

{do nothing}{set bg color

draw self}


Display List

• A display list maintains an ordered list of Shapes

:aDisplayList

:aCircle :aRectangle :aRectangle :aTriangle

DisplayList

shapeList

draw()hit?()


Drawing the Display List

• When the display list gets the message draw– It delegates the work by simply sending each of

the shape objects in the list the message draw starting with the shape on the bottom

:aDisplayList

:aCircle :aRectangle :aRectangle :aTriangle

draw()

(1) draw()(2) draw()(3) draw()(4) draw()


Identify the Objects / Classes

• What is an Object?– An entity that knows something (attributes) and

can do something (operations). An object is an instance of a class.

• For example: Account, Queue, Flight, Transaction


Identify Classes

• Finding the Classes– Examine the System Requirements – Interview Users - when in doubt go back to the

user!– Examine other documents in the domain

(databases, forms, external systems, …)

• What are the things doing the action or being acted upon?

item


The “Noun” Algorithm

• Examine the requirements and underline the nouns and verbs– The nouns are candidate classes or attributes– The verbs are candidate methods

• An object that receives a message needs to have a matching method– Shapes can be rotated means sending a rotate

message to shape.

rotateshape.rotate()


CRC Cards

• Class – Responsibility – Collaborator– developed by Ward Cunningham and Kent Beck at

Tektronix in the late 1980’s as a way to teach object-oriented analysis and design

• Manual Object-Oriented Analysis Technique– 3x5 index cards (originally 4 x 6 cards)

Classname

Responsibilities Collaborators


Use and Advantages

• Used to– Record classes as they are identified– Record the purpose (responsibility) of each class– Record and experiment with relationships

(collaborators) between classes

• Advantages– cheap, portable, readily available, and familiar– focus on analysis, not on a diagram– good in a group discussion


CRC Cards Format– Classname– Responsibilities: a textual description of the

purpose of the class– Collaborators: list the names of the classes that

this class must work with to accomplish the responsibilities

Classname

Responsibilities Collaborators


Suggestions for Use

• Use early in the analysis for brainstorming all the possible objects.– Focusing on responsibilities helps clarify the

essential nature of a class– It is easy to throw a card away

• Position the cards when trying to figure out the class relationships – subclasses– close collaboration


CRC Cards Example

• Do an analysis of a hotel room reservation system. – The system must allow clerks to assign rooms to customers.

It must also allow clerks to assign maids to clean the rooms.

Clerk

Maid

Customer

Room


CRC Cards ExampleClerk

Checks customer in and out

Manages maids

Customer

Maid

MaidCleans room Room

Clerk

CustomerStays in hotel Room

Clerk

RoomPlace for customer to stay

Customer

Maid


CRC Card ExampleClerk

Checks customer in and out

Assigns room

Handles payment

Manages maids

Assigns room

Customer

Maid

MaidCleans room

Assigned room

Cleans room

Room

Clerk

CustomerStays in hotel

Check in

Check out

Pay for room

Use phone

Room

Clerk

RoomPlace for customer to stay

Customer

Maid


Solitaire Exercise• Do an analysis of Solitaire

– First play the game– Print off the “How to

Play” help– Underline the nouns and

verbs– Create CRC Cards for

the nouns• What is each class

responsible for?

• What other classes does each class need to work with?


Unified Modeling Language - UML• After Smalltalk was released in 1980 several

big companies started work in it– IBM, Apple, DEC, Tektronix

• People needed a way to talk about objects– Created diagrams to represent classes, the

relationship between classes, object and class attributes and methods, and interactions between objects

• By the late 80’s early 90’s there were many similar but different types of diagrams

• Now there is one standard graphical language: UML


What is the UML?• Unified Modeling Language

– Graphical language for visualizing, specifying, constructing, and documenting object-oriented systems

– Meta-model with rigorous specification

• Created by Rational – Grady Booch, Ivar Jacobson, Jim Rumbaugh

• the three amigos

– Originally merged their three different approaches– Revisions are done by an OMG task force

• UML Specification – http://www.omg.org/technology/documents/

formal/uml.htm


UML Diagrams

• Class Diagram– Shows classes and the relationships between

them• Can be used to create package diagrams

• Use Case Diagram– Shows the desired functionality of the system

• Behavior Diagrams– Statechart Diagram

• Good for modeling objects that change state

– Activity Diagram• Models workflow or business processes


UML Diagrams - Continued

• Behavior Diagrams: (continued)– Interaction Diagrams:

• Sequence Diagram– Shows messages between objects in a sequential way

• Collaboration Diagram– Shows messages between objects in a compact way

• Implementation Diagrams:– Component Diagram

• Shows the organization of software components

– Deployment Diagram• Shows how packages of classes are deployed on

machines


Why Create Diagrams?

• Blueprints for constructing large software systems– Would you want to live in a large building that was

built without a blueprint?

• Advantages to Diagrams– Show System Architecture

• Verify soundness and completeness

– Improve Communication• Between developers• Between developers and users

– Simplify Complexity• Reduce ambiguity


Drawbacks to Diagrams

• Tedious to create– Easier if you use a tool

• Tedious to modify– Depends on tool

• Tend to get out of date – Reverse engineering tools can help with this

• Slow development– Too much time diagramming, not enough

developing


UML Tools

• Popular Tools– Rational Rose – www.rational.com

• Market leader but expensive

– Together Control Center - www.togethersoft.com• Moderate cost

– Visio 2002 - www.microsoft.com/office/visio• Moderate cost

– Magic Draw - www.magicdraw.com• Low cost

• Links to sites that list UML Tools is at– http://www.omg.org/technology/uml/

index.htm#Links-Methodologies


Some UML Tools Capabilities

• Create and modify diagrams• Generate code from diagrams• Reverse engineer diagrams from code• Generate a database definition

– Create DDL for relational databases

• Generate HTML documentation• Save diagrams in XMI (XML Metadata

Interchange)– For exchange with other tools


Class Diagram• Shows classes and the

relationships between them – Static structure

• Not time dependent

• Most important and commonly used diagram in UML


Class Representation

• Rectangles are used to represent classes • There are different sections for the class

name, attributes and operations

Class Name

Attribute1Attribute2

Operation1()Operation2()

Dog

sizeshape

wagTail()bark()


Visibility• Who can access the item• Types of Visibility

– Public (+)• All can use

– Private (-)• Only objects of the class

– Protected (#)• Objects of the class and objects of subclasses

• Attributes should be private– So the object has control of its’ data– Or protected if subclasses need quick access

• Methods are public or private– Public if intended as a service. Private if for internal use


Static Class Relationships• Association

– has-a – A connector has shapes

• Generalization– is-a-kind-of – More precise than is-a– A circle is a kind of shape

• Aggregation– is-a-part-of– A display list is an aggregation

(collection) of shapes

• Composition– Is-an-integral-part-of– the whole lives or dies with the

parts


Dynamic Class Relationship• Dependency

– Uses– A car uses a parking

space– It doesn’t have a have-a

relationship with it

• Dynamic relationships are relationships that change over time


Association Multiplicities• Associations have multiplicities (one for each end)

– X can have how many objects of y associated with it?– Y can have how many objects of x associated with it?

• Kinds of Multiplicities– m..n

• Inclusive range from m to n

– n• There must be exactly n

– * or 0..*• 0 to many

– 1,3,5• May be 1 or 3 or 5


Roles• Each association end is

a role– role A– role B

• Roles can be explicitly named– Especially useful when

there is more than one association between the classes

– Or for use in generated code


Class Diagram Perspectives

• There are three perspectives that a class diagram can represent– Conceptual - Analysis Stage

• Language independent, represents the domain• Specifies the classes, some attributes, some

operations, and the relationships between classes

– Specification - Design Stage• Represents a high level design of the solution • Classes in the diagram are more fleshed out

– Implementation – Programming Stage• Represents the actual solution• Shows attributes, operations, types (if needed), and

parameters to operations


Solitaire Class Diagram


When is Something not an Object?• Objects have three important characteristics

– State: data about the object, like its color or size– Behavior: operations that can be performed on the

object– Identity: distinct boundaries that identify what is

part of the object

• Some nouns are attributes– Simple scalar items like strings and numbers

• Some nouns describe the user interface– Don’t focus on interface in analysis

• Some nouns are external– Use the system but are not needed in it


Examining Objects

• Which of the following are likely to be useful objects and why?– Telephone call, name, hospital, and transaction

• Something that seems to be an action (verb) can be an object when viewed from a different perspective– A transaction can be an object

• A transaction has data– Date occurred

– Amount involved

– Where transaction occurred

• A transaction can have operations– Verify transaction


Class Names

• Class names should come from the domain– Don’t make up your own names if there is a name

used in the domain

• Class names should be singular– Card not Cards

• The first letter of each word in a name should be capital– CardPile

• Class names should be pronounceable – Be careful with abbreviations


Identify Intrinsic Behaviors

• What does each class do as part of its essential nature?

• What should this an object of this class be able to tell you about itself?– An attribute of an entity is something you should

be able to ask about• You should be able to ask a person their name

• What kinds of actions does the object take?– Operations are things that the object should be

able to do• A deck should be able to shuffle


Document Classes

• What does each class represent?– Brief description

• What is this class responsible for?

– Enough to resolve ambiguities• How does it differ from other classes

– Helps focus on the class as a model– Classes may range from very concrete to very

abstract• Classes found during analysis are often concrete• Classes added during design may be more abstract


Registration Exercise

• Create CRC cards for the following:• We would like an on-line registration system

for students. Students should be able to browse the course catalog and register for course periods.

• Administrators should be able to create a new course, delete a course, assign a classroom to a course period, schedule course periods, and assign a teacher to a course.


System Boundaries

• After you have a list of candidate objects you need to see if the objects are part of the system that you are building. – In analysis you shouldn’t focus on the user

interface.– External agents don’t necessarily need to be

represented

• What are the system boundaries of the registration application?


Determine Class Relationships

• Determine the associations– Does a course period have a classroom

associated with it?

• Determine the multiplicity on associations– Does a course period always meet in the same

room, or can it meet in different rooms?

CoursePeriod Classroom

CoursePeriod Classroom1


Class Relationships

• Determine the generalizations / specializations– Look for Commonality (is a type of)

• In what ways are classes similar? • Circles, and Rectangles, and Triangles are all Shapes.

– Look for Differences • In what ways are two classes different? • Is a meeting different than a course period? How?

• Determine the aggregation or composition relationships. – There is a part-whole relationship between

building and room.

Shape

Circle Triangle

Building Room


Static Object Modeling

• Rules for Static Object Modeling– Ends of Associations should be named, and not

represent short lived operations• An Administrator does not need a relationship with a

CoursePeriod to assign it to a room

– A class should only appear once in the diagram• A Calendar does not represent a particular Calendar, it

represents any calendar

– When in doubt choose association in preference to aggregation or inheritance

• We can always change our mind in design!

– Adding attributes clarifies relationships


Examine Documents• Paper documents can help you find classes and

attributes• The elements of the document are attributes• Assign the attributes to classes• Below is a prescription label

– What are the attribute names for this data?– What class does each attribute belong to?

Refill (770) 323-5555 X Drug Store Main Ave, Decatur

15029839 Dr. KaidJones, Susan 1/09/2000Instill 1 to 2 drops in each eye 3 times daily for 5 to 7 days.Tobramycin Sulfate Expires: 01/08/01Refill: 0 times


Pharmacy Class Diagram


Class Diagrams Aren’t Enough• They show the static

structure– Classes and relationships

between the classes• But, they give no clue of what

happens

• We need to know who wants to use the system and what they want it to do– User requirements

Customer

Sales Person

Manager


Dynamic Object Modeling

• It is impossible to understand a domain completely without understanding how a system operates– Our class diagram gives no clue as to how a

solitaire program “works”

• The best way to understand how a system operates is with use-cases– For each external agent, construct use cases

which show the interaction between the agent and the system


Creating a Use Case Diagram

• Identify all the types of users for the system– Who is using the system?– Who needs to get information from the system?– Who needs to enter information into the system?– What events that are external to the system does

the system need to know about?

• For each type of user– Create use cases that represent things that type of

user wants to do with the system

• You can have several types of users on the same use case diagram


Use Case Diagram

Actor

Use Case


High-level Use Case Format

• Don’t worry about how just describe what.• There is no standard format

– You should include• The name of the use case• The actors involved and who initiates• The priority• A short description of what happens

– You may want to include• Frequency (how often the use case happens)• Risks• Any preconditions• Any post-conditions


Example High-Level Use Case

Use case: Withdraw from an ATM

Actors: Customer (initiates)

Freq: Common

Priority: Essential

Description:

A customer arrives at an ATM. The customer tells the ATM that he/she wants to withdraw X amount. The ATM gives the customer the cash and a confirmation of the transaction and the customer leaves.


Summary

• The purpose of analysis is to understand the domain and the needs of different users

• Object-oriented analysis encapsulates data and behavior in objects

• In analysis we should– Determine the classes in the domain and the

relationships between them– Create textual high-level use cases to understand

what needs to be done