se_ooad

Page 1

CSC, Slide 1Object Oriented Analysis and Design

Object-OrientedAnalysis & Design

A Two-Day Seminar

Michael A. [email protected]://www.cs.umbc.edu/~mikeg


Objectives

Module ObjectiveTo provide a brief, hands-on overview of object-oriented analysis anddesign. Topics covered include analysis, design, complementaryprocedures, and process improvement.

In-Class ExercisesCase studies based on small project specifications will be used byparticipants to develop object-oriented models and identifyimplementation strategies.

Module Completion RequirementParticipants will be required to demonstrate that they can apply basicobject oriented techniques to create and modify object oriented analysisand design models.

Page 2


References

Software Engineering• Software Engineering, 5th Ed., Ian Sommerville, 1995, chapter 14.

Coad/Yourdon OOAD• Object Oriented Analysis, 2nd Edition, Peter Coad and Ed Yourdon,

1991.• Object Oriented Design, Peter Coad and Ed Yourdon, 1991.• Object Oriented Programming, Peter Coad and Jill Nicola, 1993.

Booch Object Oriented Design• Object Oriented Design and Analysis, 2nd Ed., Grady Booch, 1994.

Rumbaugh Object Modeling Technique• Object Modeling and Design, James Rumbaugh et al., 1991.


Outline

Section Topic Slide1. Introduction to OO 52. Object Oriented Analysis 273. Additional Procedures 634. Object Oriented Design 825. Process Improvement 1086. Case Studies 119

About the InstructorMichael Grasso received a doctorate in Computer Science from theUniversity of Maryland Baltimore County in 1997. His researchinterests include human computer interaction and medical informatics.He has been the Principal Investigator on several research grantssponsored by NIH and DoD. He received a B.S. in Microbiology in1983 from the University of Maryland at College Park and an M.S.degree in Computer Science from the American University inWashington, DC in 1986.

Page 3


Section 1: Introduction to OO

Object Oriented Model.

Comparison of Other Approaches.

Object Oriented Abstractions.


Object Oriented Model

An Object Oriented model is based on entities.• Hidden state.• Operations on that state.

An Object Oriented model uses information hiding.• Minimal dependence on global state information.• Increases understanding of the design.

It views software as a set of interacting objects.• Compare to viewing software as a set of functions.

It uses various object-oriented abstractions• Classification, Inheritance, Aggregation, Polymorphism.

OOAD differs from Object Oriented Programming.• OOAD is a design strategy.• It is not dependent on any specific implementation language.

Page 4


Characteristics of OOAD

Shared data areas are eliminated.• Objects communicate by exchanging messages.• Reduces the overall system coupling.

Objects are independent entities.• Changes to implementation of a class should not impact overall

system.• The separation of external and internal behavior should enhance

reuse.

Objects can execute either sequentially or in parallel.• This is a design decision which can be deferred to later in the design

process.

For many systems, there is a clear mapping between real-world entitiesand objects within the system.• This improves the understandability of the design.


Classes as the Foundation for a Design

Match the technical representation of a system more closely to theconceptual view of the real world.

Relatively stable over time and provide a basis for moving towardsreusable analysis results.

Avoid shifting the underlying representation of the system as itprogresses from analysis to design to implementation.

Create building blocks from object and groupings of objects.• Not chunks of data or just functions.

Page 5


Comparison of Analysis Approaches

Functional Decomposition.

Structured Analysis.

Data Modeling.

Object Oriented.


Functional Decomposition Model

Map the problem domain to a set of functions and sub-functions.

Transform concepts into various functions.• This is anindirect conversion that is highlyvolatile and sometimes

arbitrary.

The original and probably the still the most commonly used approach.

Useful to OOA within the context of defining services.

FunctionalDecomposition

main()getSomething()processThis()calculateThat()

Page 6


Structured Analysis Model

Map the problem domain to flows and transformations.

Transform concepts into various flows and transformations.• This is anindirect conversion that has a strong function emphasis

and is therefore highlyvolatile andarbitrary.• Not useful in systems that do not transform data.• Separation between data and function.• Analysis results must be transformed into another format for design.

StructuredAnalysis


Data Modeling

The mapping of the problems domain into the following.• Entities and Attributes.• Relationships.• Inheritance.• Aggregation.

This is a partial solution which is missing specific concepts.• Services.• Messages.• Collaborations.

Data Modeling

Page 7


Object Oriented Analysis

Real-world concepts are modeled asclasseswith correspondingstate,behavior, andcollaborations.

No transformation.• OOA directly maps the problem domaindirectly into a model,

instead of mapping them indirectly into functions or data flows.• The same model is used throughout the software engineering process

during analysis, design and implementation.

Minimizes volatility and maximizes resiliency.• The focus is on classes, not function and data.

Reuse is enhanced.• Classification - Classes are relatively stable over time.• Encapsulation - Classes with well-defined state and behavior.• Inheritance - Specializing classes for specific applications.


Object Oriented Model

With an object oriented approach, there is a direct correspondencebetween the problem domain and the analysis results. The sameconcepts found in the problem domain are also found in the analysisresults, the design results and the software.

Object OrientedAnalysis class Airplane

class Radarclass AirTrafficController

Page 8


An Object Oriented Life-Cycle

Conceptualization• Establish core requirements.

Analysis• Develop a model of the desired external behavior.

Design• Create an architecture for implementation.

Evolution• Grow and change the implementation through successive refinement.

Maintenance• Manage post-delivery evolution.


Object Oriented Abstractions

Most of what we deal with in the real world is far more complex thanwe can cope with in one fell swoop.

Abstraction helps us understand these concepts by emphasizing certaindetails while ignoring others.

These include:

• Classification• Inheritance• Encapsulation• Polymorphism• Aggregation• Association• Collaboration

Page 9


Classification

Classification is used to group entities that share common characteristicsinto a class over which uniform conditions hold.

Bill12 Main St.

Sue155 First St.

Joe688 Sun Ct.

Classify

Instantiate

Personnameaddress

Objects/Entities Class


Inheritance

A mechanism for expressing similarity among classes. It portraysgeneralization (What is the same?) and specialization (What isdifferent?), making common attributes and services explicit within aclass hierarchy.

Bill.12 Main St.111-22-3333

$35,000Classify

Specialize

Personnameaddress

Sue155 First St.

$1,000

Employeessnsalary

CustomercreditLimit

(Generalize)

Page 10


Encapsulation

Encapsulation is the mechanism that binds together code and the data itmanipulates and keeps both safe from outside interference and misuse.In the following, only the services move() and scale() modify theattributes of Circle. The service draw() performs some computationbased on the values of the attributes.

Circle

drawmovescale

locationradius


Polymorphism

Polymorphism is the quality that allows one name to be used for two ormore related but technically different purposes. In the following, eachgraphical object has the same services, although they are implementeddifferently.

Circle

drawmovescale

Polygon

drawmovescale

Line

drawmovescale

Page 11


Aggregation

Aggregation is used to treat a collection of objects as a single object.For example, among other things, a car consists of tires and an engine.Note that the opposite of aggregation is decomposition.

Car

Tire Engine


Association

An association can be viewed as a weak form of aggregation or as adata-oriented relationship between two entities. For example, thefollowing relationship models the concept that if there is a car, it mustbe associated with an owner.

Owner Car

Page 12


Collaboration

Collaboration between classes is achieved though message passing.

This documents dependencies between classes by answering thequestions.

• What help do I need?• Who needs my help?

At some point, classA sends one or messages to classB.

Collaborations can be extended to show the flow of messages or control.

A B


Collaboration Extensions

Flow of messages• What messages can I send?• What messages can I receive?• Here classA sends thegetID message to classB.

Flow of control• In what order will messages be sent?• These can be further grouped by scenario.• For example, scenarioA, steps1 and2.

A BgetId

A B CA.1 A.2

Page 13


Example: OOA Model

pHContainer

run

pHvalue

initread

pHDisplay

show

initdisplay.1:show

display.2:read


Section 1 Exercise

Use some other modeling technique to describe the pH example on theprevious slide. You can use PDL, data flow diagrams, flow charts, etc.

Prepare a list of objects that you would expect each of the followingsystems to handle.• A program to compute and store bowling scores for a bowling

league.• A telephone answering machine.• A catalog store order entry system.

Design a class with encapsulated state and behavior for the following.• A linked list.• A sorted linked list.• A telephone.• A bank customer.

Page 14


Section 2: Object Oriented Analysis

Every OOA methodology contains some permutation of these activitiesto identify the following.

• Classes.• State.• Behavior.• Collaborations.

These are activities,not sequential steps.

However, the activities are introduced in a specific order based onvolatility.

• Services are last, since they are the most volatile.• Attributes are next most volatile.• Classes and structure are the most stable.


Object Oriented Analysis Activities

Classes- Identify the classes which are part of the system.• Consider persons, places, and things in the problem statement.• Attempt to personify these concepts.

• Who am I?• Refine classes using inheritance, aggregation and association.

• What is the same? What is different?• What am I a part of? What am I associated with?

State- Identify the attributes that of each class.• What do I need to know?

Behavior- Identify the operations or services needed for each class.• To manipulate state and provide needed behavior.• What can I do?

Collaborations - Identify collaborations between classes.• What help do I need? Who needs my help?

Page 15


Possible OO Diagrams/Views

These may be on separate diagrams or part of the same diagram.

Class Diagram.• A graph which shows the static structure of the model.• Includes classes, class structure (attributes and operations), and class

relationships (inheritance, aggregation, associations).

Object Diagram,• A graph of class instances.• Includes objects, object states, and object collaborations.• May be static and show a snapshot of system state at a point in time.• May be dynamic and show how system state changes over a period

of time.

Other diagrams are covered elsewhere.• DFD, ERD, STD, etc.


Activity 1: Classes

Class• A description of a group of objects with a uniform set of properties.

Classes may be further defined as any of the following.• Abstract.

• A class with no instances, but whose descendants may haveinstances.

• Concrete.• A class that can be instantiated.• A class is assumed to be concrete, unless otherwise stated.

Object• An object is an instatiated class or an abstraction of something within

the problem domain.

Page 16


Notation

John Doe12 Main Street123-456-7890

Class Object

name

services

attributes

Abstract Class

name (Abstract)

services

attributes


Naming Classes

Naming alternatives.• Singular noun.

• e.g. Clerk.• Adjective and noun.

• e.g. NewAccountsEmployee.

Vocabulary.• Choose name using the standard vocabulary for the subject matter.• For example, in a library system choose the name Borrow over the

name CheckOutEvent.

Use readable names.• Capitalize the first letter of each word.• Do not add prefix or suffix codes.

Page 17


Finding Classes

Nouns• Persons, places, and things in the problem domain.

Previous OOA Results.• The previous OOA results of similar systems.

Structures.• Inheritance and aggregation.• This is an activity in itself and will be discussed later.

Other Systems.• Other systems or external entities the system will interact with.

Devices.• Devices the system will need to interact with.• Defer implementation-specific computer components until design.


Finding Classes

Things or Events Remembered.• Historical events that must be observed and recorded by the system.• Normally and event would just be modeled as a service.

• event = service• Here we are modeling the fact that an event happened at a particular

time.• event + date = event remembered class

Sites.• Physical locations the system needs knowledge of.

Organizational Units.• Organizational units the humans in the system belong to, such as

within a company or country.

Page 18


Finding Classes

Roles Played.• The roles played by human beings in the system.• Distinct groups of people with specific attributes and services.• Notes on human interaction.

• Since humans can be thought of as interacting with the entiremodel.

• Therefore, place these classes in the OOD Human InteractionComponent.

• However, if one desires, this interaction can be placed in the OOAmodel, although this is not Coad and Yourdon's preference.

Operational Procedures.• Operational procedures the system has to hold to over time, such as

work-flow steps that are not inherent in the problem domainconstraints.


Challenging Potential Classes

Cohesion.• Does the class have a single purpose?• In 25 words or less, write a description for each class that describes

its purpose, behavior, and collaborations with other classes.

Needed Remembrance.• Is there anything the system must remember about the objects in the

class (attributes)?

Needed Behavior.• Does an object need to provide some behavior (services)?

Multiple Attributes.• If the class has only one attribute, the class itself maybe should be an

attribute of another class.

Page 19


Challenging Potential Classes

Always-Applicable Attributes and Services.• Is there a set of attributes that apply to each object in the class?• Is there a set of services that applies to each object in a class?

Domain-Based Requirements.• Is the class based on those requirements the system must have,

regardless of the computer technology used to implement it?

Not Merely Derived Results.• Is the class based on information that can be derived from other parts

of the system?• For example, maintaining a person's age in a system that already

remembers the person's date of birth.• Gathering derived results is a design decision that should be avoided

during analysis.


Inheritance

Inheritance is also called the generalization-specialization, gen-spec, orIsA hierarchy.

Note that inheritance is a relationship between classes, not objects.

Generalized classes are placed higher in the hierarchy while specializedones are found below.

For example, a Vehicle is a generalized class while TruckVehicle andCarVehicle are more specialized ones.

In other words, a TruckVehicle is-a-kind-of Vehicle.

Page 20


Inheritance Notation

Inheritance hierarchy.• The generalized class at the top and the specialized classes below.• The specialized class names should reflect the class they were

specialized from.• For example, ClerkPerson was specialized from Person.

Person

Employee Customer


Inheritance Strategy

Consider each class as a generalization and apply the following criteriaagainst specializing it.

• Is it in the problem domain?• Would the new class have relevance?

• Is it within the system's responsibility?• Does the system need to recognize the difference between a

specialized and generalized version of the class?

• Will there be inheritance?

• Will the specialized class meet the criteria for classes?

In a similar fashion, consider each class as a specialization and apply thesame criteria against generalizing it.

Page 21


Inheritance Should Reflect Specialization

The inheritance should make sense.• Don't introduce inheritance just for the sake of extracting out a

common attribute .• What would be a more appropriate way to show this?• Think of another example that could be modeled as either inheritance

or aggregation.

Location

Airport Aircraft Shipment Item


Inheritance Hierarchy

Most inheritance structures take the form of a tree or hierarchy.

Vehicle

CarVehicle TruckVehicle TrailerVehicle

Page 22


Inheritance Lattice

Some inheritance structures take the form of a lattice instead of ahierarchy.

Person

Clerk Customer CustomerClerk


Inheritance Lattice Continued

Person

Clerk Customer

CustomerClerk

Page 23


Aggregation

Aggregation is also called whole-part or HasA.

For example, an Aircraft contains an Engine or in other words, anAircraft has an Engine.

Note that this relationship can be quantified in one of two ways,depending on how the relationship is viewed.

• As a relationship between objects.• As a relationship between classes.• The approach you use will depend on the methodology you choose.• Note that inheritance was viewed as a relationship between classes.


Aggregation Quantified Between Classes

Aggregation as a relationship between classes.• This is used by Booch, Rumbaugh, and in E-R models.• A ratio is used to quantify the relationship between classes.• There is a one-to-many relationship between the Airplane and Engine

classes (with many bounded by 4).• There is a one-to-many relationship between the Airplane and

CargoItem classes.

1

0,4

1

m

Aircraft Aircraft

Engine CargoItem

Page 24


Aggregation Quantified Between Objects

Aggregation as a relationship between objects.• This is used by Coad and Yourdon.• The number of connections between objects in the are quantified.• An Aircraft object is connected to 0 to 4 Engine objects and many

CargoItem objects.• Both Engine and CargoItem objects objects are connected to 1

Aircraft object.

0,4

1

m

1

Aircraft

Engine CargoItem

Aircraft


Aggregation as Attributes

Both aggregation and associations can also be modeled using attributes.

This is covered in more detail under OOD.

AircraftEngine[4]

AircraftCargoItem[m]

Page 25


Aggregation Strategy

When looking for potential aggregation structures, consider thefollowing.

• Assembly-Parts.• An Aircraft is an assembly with Engine(s) as parts.

• Container-Contents.• An Aircraft is a container with CargoItem(s) as its contents.

• Collection-Members.• An Company is a collection with Employee(s) as its members.

• Associations or Object Connections.• An alternative to the aggregation structure is the association,

which is sometimes called a weak has-a.


Associations

Responsibilities.• An association is used to identify that one object needs another in

order to fulfill its responsibilities.

Associations.• Associations reflect associations between objects.

Dependencies.• You can also view associations as instantiation dependencies. For

example, if an object of classA is instantiated, then an object of classB must be instantiated.

Weak has-a.• It is sometimes called a weak has-a, and can be used in place of

aggregation when such a structure does make sense conceptually.

Page 26


Association Strategy

For each object or class.• Identify associations and dependencies within the problem domain

and the system's responsibilities.• If necessary, the associations can be labeled.• Quantify associations, similar to aggregation.

A one-to-many association between the Customer and Invoice classes.

A Customer object is associated with many Invoice objects.

1

mCustomer Invoice

Purchase

m

1Customer Invoice

Purchase


Many-to-Many Associations

Check for many-to-many associations.• This may reflect the need for an event remembered class as an

intermediary.• Unless otherwise specified all quantification is between objects.

Owner Vehiclemm

Owner Registrationm1

Vehicle1m

Page 27


Multiple Associations

Check for multiple associations between objects.• This may reflect the need for an event remembered class.

Owner Vehicle

Owner Vehicle

Register

Title

LegalEvent

DateEventType


Example: Small Library Database System

Identify what classes would be appropriate for the following. Include abrief description of each class as well.

The Small Library Database System will be used by the BiologyDepartment of a local college to track the borrowing of books and otherforms of media, such as video tapes, and software. A secretary willoperate the system and will responsible for checking out books tostudents and faculty members.

Page 28


Activity 2: State

Object states.• An attribute is data for which each object in a class has a value.

Attribute manipulation.• Attributes are only manipulated by the services of that object.

Volatility.• Attributes are more likely to change than classes.

Atomic concepts.• Each attribute should capture an atomic concept - either a single

value (such as a social security number) or a tightly related groupingof values (such as a mailing address).


Attribute Strategy

When identifying attributes, answer the following questions from theperspective of a single object.

• What do I need to know?

• What states can I be in?

• How am I described in general or in the problem domain?

Put each attribute in the class which it best describes. Most often this isstraight forward. In some instances, an attribute may be shared by morethan one class. In this case, attempt to identify which class the attributeis really describing.

Make sure each attribute contributes to the single purpose of its class.

Page 29


Attribute Special Cases

Check for attributes that are not always applicable.• As mentioned earlier, if you find this situation, you probably need to

adjust the inheritance structure.

Check for class with just one attribute.• Although this sometimes occurs, a class with only one attribute is

possibly a single attribute that belongs to another class.

Check for attributes with repeating values.• The attribute with repeating values most likely needs to be promoted

to a class.

Defer to design the following.• Compromises between data redundancy and performance.• Data normalization issues such as unique identifiers.


Activity 3: Behavior

Behaviors of a class are also call functions, operations, or services.

Identify the object states.• Every change in the attribute values of an object reflects a change in

the object's state that, in turn, reflect a change in object behavior.

Identify the required behaviors.• What is the object suppose to do?• Make sure each service contributes to the single purpose of its class.

All objects have the following implicit behaviors that are not explicitlyshown in the OOA model.• create: create a new object.• connect: connect/disconnect an object from another.• access: get/set the attribute values of an object.• release: disconnect and delete an object.

Page 30


Activity 4: Collaborations

Message connections model the processing dependency of an object,indicating a need for services in order to fulfill its responsibilities.

The message connection maps one object to another, in which asendersends a message to areceiver. The receiver performs some processingand returns the results to the sender.

Alternatively a message connection is sent to a class to create a newobject.

Message connections exist solely for the benefit of the services.

To identify needed message connections, ask the following of eachobject.• What other objects does it need services from?• What other objects need one of its services?


Message Connection Notation

The notation for a message connection is a light or dashed arrow.

The message connection may be labeled to document it or numbered toshow order of execution, if necessary.

A B

Page 31


Collaboration Example

In the following, a print queue sends a message to a printer telling it toprint a particular print job. The message connections are part of acritical thread of execution, showing their relative order of execution.

m

1

PrintJob

PrintQueuestate

initializeprintNextJobbuildJobaddJobremoveJob

Printer

printinitialize

(A.1)

(A.2)

11


Exercise: Small Library Database System

Use the classes identified earlier to complete the OOA model for thefollowing.


Page 32


Section 3: Additional Procedures

Subjects.

Secondary Models.

Complimentary Analysis Approaches.

Documentation.


Subjects

Subjects used give an overview of a larger OOA model. They can beformalized subsystems with their own behavior or informal grouping toincrease understanding.

Subjects are created by following steps.

• Collapse the structure by promoting the uppermost class in eachstructure to a subject item. Make all remaining classes not instructures subject items.

• Refine the subjects by combining items in related sub-domains.

• Further refine the subjects by combining objects to minimizeinteractions between subjects.

Page 33


Subject Notation

Use one of three notations in the subject layer.• Draw a large rectangle around each subject in the OOA diagram,

without simplifying the structure.• Use a class-like notation to show subjects and the names of the

classes in each subject.• Show only subject names.

All three can be used at the same time to show different subjects invarious levels of detail.

Subject 1

Class 1Class 2Class 3

Subject 1

Subject 2

C 1

C 2 C 3

Subject 1


Secondary Diagrams

Object Oriented Analysis is a methodology that is based on classes.However, this does not mean other models cannot be used.

The difference is that these other models are secondary and that classesare the foundation of the design.

Booch, Rumbaugh, Coad, and Yourdon all use secondary models intheir respective methodologies. Although, each emphasize these modelsin different ways.

Some common secondary diagrams include the following.• State transition diagrams.• Data flow diagrams.• Service charts.• Flow charts.

Page 34


State Transition Diagram

Temporal relationships can be modeled with state transition diagrams.• Note that an alternative for simple systems is to add this information

in the object diagram by labeling messages.

Such diagrams model the following.• Events- a signal that something has happened.• States- the context in which events are interpreted.• Transitions - a response to an event that causes one state to

transition to another.• Actions - operations fired in response to an event.

A state transition diagram can be developed for each of the following.• For each class.

• States correspond to attribute values for that class.• Actions may be services of that class or some other class.

• For key subsystems.• For the entire system.


State Transition Diagram Notation

States correspond to class attribute values.

Events and actions correspond to class services.

Attribute Values

State Transition

Events/Actions

Page 35


State Transition Diagram Example

For the PrintQueue class.

state = off

state = standby

state = busy

initialize

buildJob removeJob


Data Flow Diagram

Data flow diagrams are used to specify the details of the behavior of asystem.• Note that an alternative for simple systems is to add this information

in the object diagram by labeling messages.

Such diagrams model the following.• Processes- a component that transforms data values.• Data Flows- values the flow between processes, stores, and actors.• Data Stores- passive components that hold data.• Actors - external or independent components that produce and

consume data.

A data flow diagram can be developed for each of the following.• For the services of a class or related classes.• For key subsystems.• For the entire system.

Page 36


Processes correspond to class services.

Data flows correspond to service inputs and outputs.

Actors and data stores correspond to classes.

Data Flow Diagram Notation

ProcessData Flow

Actor Data Store


Data Flow Diagram Example

Data Flow for printNextJob service.

buildJob

requestUserPrintJob

print

removeJob

job

status

status

job

Page 37


Complimentary Analysis Approaches

A number of additional activities can be used which are complimentaryto object-oriented analysis and design methodologies.

Domain Analysis.• Identify classes which are common to all applications in this domain.

Scenario Planning or Use-Case Analysis.• Identify operations patterns by users initiating some sequence of

interrelated events.

CRC Cards.• Class-Responsibility-Collaboration cards.

Informal English.• Identify key concepts from textual description of the problem.


Domain Analysis

Domain analysis seeks to identify the classes and objects that arecommon to all applications of a given domain.• For example: all accounting systems have certain classes in common.

Domain analysis works well, because there are very few truly uniquekinds of software systems.• Try to compare the system you are developing to a generalized class

of systems.

When starting to design a system.• Survey the architecture of existing systems in that domain.• Define key abstractions and mechanisms.• Evaluate which can be used in the new system.• A domain expert may be required to assist in this effort.

Page 38


Use-Case Analysis

Use-case analysis was first formalized by Jacobson [I. Jacobson, et al.1992. Object-Oriented Software Engineering., Addison-Wesley].

A use case is a scenario that begins with some user of the systeminitiating some transaction or sequence of interrelated events.

Scenario planning of this type is employed by many other OOmethodologies, including Coad/Yourdon, Jacobson, and Wirfs-Brock.• A basic scenario planning approach is introduced under human

interaction in the section on design.• Basic goal is to group the primary function points of the system by

related behavior or hierarchy.

This technique is similar to storyboarding.• A common in the television and movie industry.• In it's simplest form, it consists of post-its, magic markers, and a

white board.


Use-Case Analysis Activities

For each interesting set of function points, storyboard a scenario toidentify the following.• Actors that participate.

• Actors are classes or categories of users, with a specific role.• Their responsibilities.• How they collaborate with each other.

Modify the scenarios as necessary.• Expand the initial scenarios to identify secondary scenarios.• Create a generalized scenario from several related scenarios.

Update the list of classes, responsibilities, and behaviors that result forthis effort.

Page 39


CRC Cards

CRC cards were first proposed by Beck and Cunningham [K. Beck, W.Cunningham. October 1989. A Laboratory for Teaching Object-Oriented Thinking, SIGPLAN Notices, 24(10)].

CRC stands for Class - Responsibility - Collaboration.

They are simple 3x5 index cards with the class name along the top andtwo columns below for responsibilities and collaborations.

They provide a simple tool for team development tasks, such asstoryboarding.• They can be used during storyboarding sessions to keep track of the

classes for each scenario.• They can be easily grouped and organized.


Informal English

An alternative is to write an English language description of theproblem, or part of the problem.• [R. Abbot. November 1983. Program Design by Informal English

Descriptions. Communications of the ACM, 26(11)]

Take the natural language description and underline the nouns and verbsto identify candidate classes and operations, respectively.

This is by no means a rigorous approach.• Natural language is to imprecise and ambiguous.• Any noun can be verbed, and any verb can be nouned.

However, since natural language is often used for system descriptionsand requirements documents, it may provide some useful insight.

Page 40


Service Documentation

Document the services within each class.

Identify the following for each service: parameters, external input,external output, additional constraints, and notes.

Services can be further documented using PDL, an object state diagram,a service chart, a flow chart, data flow, state-transition diagram, etc.

Critical threads of execution spanning one or more classes can also bedocumented by numbering the corresponding message connections andadding additional annotations or diagrams.

Don't hesitate using functionally-oriented notations to documentservices. In this limited context they can be very useful. You just don'twant to use this approach to drive the OOA model.


OOA Documentation

Along with the OOAD model, additional documentation includes theclass specification template.

Class specification template• Class

• Name and description• Object state diagram

• Attributes• Name, type, and description

• Services• Name and prototype• PDL, flowchart, dataflow diagram or service chart

• External inputs and outputs• Additional constraints

• Pre- and post-conditions, invariants, axioms• Other documentation, as needed

Page 41



Add appropriate documentation and secondary diagrams to thefollowing.



Section 4: Object Oriented Design

Introduction to Design

Problem Domain Component

Human Interaction Component

Page 42


Object Oriented Design

As stated earlier, analysis is the practice of studying a problem domain,leading to a specification of externally observable behavior.

Building on this, design is the practice of taking a specification ofexternally observable behavior and adding details needed for actualcomputer system implementation.

Analysis is the what or the problem phase. Design is the how or thesolution phase.

OOD consists mainly of expanding the requirements model to accountfor the complexities introduced in selecting a particular implementation.• Human interaction.• Data management.• Other implementation areas.


No Transition into Design

The same methodology is used during design as was during analysis.This provides a common notation with no transition as you progressfrom analysis to design to programming.

With some methodologies, the design phase is significantly differentthan analysis. For example, Data Flow and Entity RelationshipDiagrams during analysis and Structure Charts during design.

Instead the same approach is used in both analysis and design, exceptthat design focuses on different aspects of the problem.

By using the same notation, you won't be able to point to the shape of adata flow bubble and say, "I'm doing analysis" or "I'm doing design."Many times the opposite is going on anyway.

Page 43


Analysis versus Design

Object Oriented Analysis

Identify

• Classes• Who am I?• What is the same/different?• What do I contain?• Who am I associated with?

• Attributes• What do I need to know?

• Behaviors• What can I do?

• Collaborations• What help do I need?• Who needs my help?

Object Oriented Design

Decide how to implement

• Classes• State• Behavior• Collaborations

Add Implementation-SpecificComponents

• Human interaction• Data management• Other implementation areas


OOD Design Strategy

Problem Domain Component.• The OOA results are placed here directly. Certain modifications are

made base on implementation-specific criteria.

Human Interaction Component.• The actual displays and inputs needed for human interaction. The

classes will vary somewhat depending upon the type of userinterface. Example classes would include specializations of Menu,Screen, and Display.

Data Management Component.• Deals with the access and management of persistent data, using a flat

file, relational, or object-oriented database.

Page 44


Problem Domain Component

The Problem Domain Component (PDC) is developed using thefollowing strategy.

• Start with the OOA results.

• Modify the OOA results based on changing requirements or anincreased understandingof the problem.

• Add to the OOA results based onimplementation-specificcriteria.• Reuse• Classification• Aggregation and association• Attributes• Services• Data management & lower-level detail


Implementation Specifics - Reuse

Some object-oriented languages come with predefined classes:

• Borland C++ container classes and Object Windows.• Microsoft Visual C++ has the Microsoft Foundation Classes.• Smalltalk has a lot of windowing constructs and container classes

(arrays, sets, stacks, queues, etc.).

Other sources:

• Purchase off-the-shelf classes and development tools.• Internally developed reusable class libraries tailored to your

environment.

Page 45


Implementation Specifics - Classification

Container Classes.• Add container classes to manage and group related classes.

Root Classes.• Add root classes and use inheritance from this class to group

problem-domain-specific classes together.

Generalized Protocol.• Add a generalized class to support a common protocol that a number

of specialized classes require.

Support Inheritance.• Adjust the inheritance structures to remove multiple or single

inheritance if this is not supported by your programming language.

Improve Speed.• Modify PDC classes to improve performance.


Implementation Specifics - Connections

Add attributes to support aggregation and association connections.• You may choose to annotate these attributes with a [d] next to them,

to show they were added during design.

For each object involved in a connection, we ask (usually in order tosend messages):• Does the object need to know about the association?

Example: Owner and Vehicle• Does the Owner need to know which Vehicle(s) he/she owns?• Does the Vehicle need to know who owns it.

Page 46


Implementation Specifics - Attributes

Add data types and default values to attributes.

Break up attributes into atomic values.

For example, during analysis there might have been an attribute calledaddress. During design, this can be decomposed intostreet, city, state,andzip.

Add implicit attributes.• Unique identifier for each class.• Attributes to model aggregation and associations.


Implementation Specifics - Services

Add arguments and return types to each service.• int checkOut(String borrowerName, String bookName)

Clarify documentation for simple services using functionally-orientedtechniques.• PDL (program design language).• Flowcharts.• Dataflow diagrams.

Add implicit services (create, connect, access, release) that arenecessary to enhance your understanding the design.

Break down complex services into separate modules.

Page 47


Human Interaction Component

The HIC captures how a human will command the system and how thesystem will present information to the user. In general, the HIC modelsall external entities (most likely humans) that will act upon the PDC.

Human interaction could have been added to PDC classes based on rolesplayed by people. However, the cleaner approach is to see humaninteraction spanning the entire system by adding a separate humaninteraction component.

Although prototyping should be done throughout the analysis anddesign phases, it is most important when designing the HIC.

Their may be standards in place for look-and-feel that the HIC will needto adhere to. Also, the HIC will need to be specialized for the type ofdisplay (GUI, character-based) and available libraries.


HIC Strategy

Classify humans and describe their task scenarios.• Identify the types of humans who will use the system.• Describe their needs and what they need the system to do for them.• This approach is similar to Use-Case Scenarios.

Design the command hierarchy for human interaction.• Menu screens or bars.• A series of icons.• A command line.

Design the HIC Classes.• Create the classes necessary to support human interaction.• Types include menu, input, and display classes.

Prototyping the human interface• Allow user community to experience, play with, and refine the

proposed human interface.

Page 48


A Simple TTY HIC

The easiest approach to human interaction would be to have a menuclass along with a class for each input and display task. All interactionis based on a TTY approach.

Notice that the namesCustMenu andNewCustScreenimply that theclasses were specialized fromMenu andScreen.

CustMenu

display()getSelection()dispatch()

itemsselection

NewCustScreen

getCustInfo()saveCustInfo()

itemsselection

Customer

store()retrieve()

customerIdnamecreditLevel

make newcustomer object

execute newcustomerselection


Windows-Based HIC Classes

HIC classes under an Windows-based system might look like this. Thisorganization should be adjusted to support user interface technology andavailable libraries - Motif Widgets, Microsoft Windows SDK, BorlandObject Windows, Microsoft Foundation Classes, etc.

0,m

1

Window

DisplayBox

0,m

1

Field

0,m

1

Menu

Page 49


Windows-Based HIC Class Specializations

Specialize the HIC window for each human interaction task, such asadding a new customer or deleting an existing customer.

Window

NewCustWindow DeleteCustWindow


Data Management Component

The DMC provides the infrastructure for the storage and retrieval ofobjects from a data management system. In general, we will use thistask to identify management approaches for persistent and non-persistent data.

The Data Management Component is developed using the followingstrategy.

• Select a data management approach.• Normalize the data.• Design the data layout.• Design the corresponding services.• Design an approach for the management on non-persistent data.

Page 50


Select a Data Management Approach

Flat File Management.• Examples: Fixed length, tokenized, or comma delimited.• The operating system provides file handling and sorting.• Your objects need to have the ability to manage resources at the file

level, position the file to the right record, and transform data fromobjects to flat file.

Relational DBMS.• Examples: Oracle, Sybase, Ingress, or DB2.• The system provides a table metaphor with rows and columns.• Your objects need to know which tables and rows to access and how

to transform data from objects to table format.

Object-Oriented DBMS.• Examples: Ontologic or Versant.• The database provides necessary services to store/retrieve objects.


Normalize the Data

Normalization Strategy.• Objects should have a unique identifier or primary key.

• This may be based on one or more attributes.• The primary key will replace the implicit id attribute from OOA.• Any foreign keys will replace the implicit cid attributes from

OOA.

• Attribute values must be atomic and have with no repeating values.

• Each non-key attribute should be identifiable by and depend only onthe key.

With an OODBMS, there may be no need to normalize the data.

Normalization reflects a trade-off between performance and dataconsistency.

Page 51


Design the DMC

Design the Data Layout.• Identify files or tables along with their keys, fields, performance

needs, and storage requirements.• There should be a file or table for each class being stored.• Object attributes become fields or columns.

Design the Corresponding Services.• Add services to each class that needs to know how to store() and

retrieve() itself.• Services are implemented using the access language (e.g., embedded

SQL).• Some of this behavior may be generalized into an abstract database

class.


Example: Data Management

Data Management Approach.• An SQL-based relational database, such as Oracle or Sybase.

Normalize Data.• Add a customerId attribute as the primary key.

Design the Data Layout• SQL data definition statements.

Design the Corresponding Services.• Add store() and retrieve() services written in embedded SQL.

create table customer (customerId int,name char(40),creditLevel float,primary key (customerId),unique (name));

Customer

store()retrieve()

customerIdnamecreditLevel

Page 52


Non-Persistent Data Management

Extend Approach to Non-Persistent Data.

A data management approach may also be adopted for data that will notbe stored in a data management system.

For example, a linked list class may be included to manage a set ofcustomer objects in memory.

LinkedList

Customer

n

0,1


Summary of OOD Tasks

Problem Domain Component• Start with the OOA results.• Modify based on an increased understanding.• Modify based on implementation-specifics.

Human Interaction Component• Classifying human interaction• Designing the command hierarchy• Creating human interaction classes

Data Management Component• Selecting a data management approach• Normalizing the data• Adding DMC classes and services• Develop any necessary database files

Page 53


Programming Object Oriented Concepts

OOAD C C (files) C++ Java

Class struct separate file class class

Object variable none variable variable

Inheritance none none derived class subclass

Aggregation nested struct none nested class reference

Association pointer none pointer reference

Attribute data member static data data member data member

Service externalfunction

externalfunction

memberfunction

memberfunction

Message function call function call function call function call


Stack Example in C and C++

C Example

// stack.h - external interface

void push(char);char pop();const int stack_size = 100;

////////////////////////////////////////// stack.c - internal representation

#include "stack.h"

static char v[stack_size]static char* p = v;

void push(char c) { // code for push }

char pop() { // code for pop }

C++ Example

class Stack{char *v; int sz;

public:Stack(int size);~Stack();void push(char c);char pop();

};

main(){Stack s1(10);Stack s2(25);...

}

Page 54



Convert the OOA model into an OOD model by adding appropriatedesign components.



Section 5: Process Improvement

Software Crisis.

Process Maturity.

Implementing OO.

OO Vendors, Methodologies, and Tools.

Refer to IEEE Computer Special Issue on Managing Object-OrientedSoftware Development, 29(9), September, 1996, for more information.

Page 55


A Software Crisis

A 1979 GAO report (FGMSD-80-4, 11/79) evaluated 7 million dollarsworth of software development projects and discovered that as apercentage of cost:• 47% were never used• 29% were never delivered• 19% required extensive reworking or were abandoned• 3% required additional modifications• 2% met its requirements

Tom DeMarco pointed out in 1982 that 25 percent of large systemdevelopment projects never finish. (Controlling Software Projects,Prentice Hall, 1982)

Capers Jones documented in 1991 the gloomy statistic that the averageMIS development project is one year late and 100 percent over budget.(American Programmer, 6/91)


Problem vs. Solution

Analysis is the process of extracting theneedsof a system -what thesystem should do, not how the system will be implemented.

It is theproblem-oriented (not the solution-oriented) phase in thesoftware engineering process.

Although we have a natural affinity toward results-oriented tasks (e.g.,design), we need to focus more on the problem to avoid treating merelythe symptoms and to provide an unbiased view of the situation. (GeorgeWedberg, But First, Understand the Problem, ASM Journal of SystemsManagement, page 22-28, 6/90)

The risk of mortality ... increases when treatment is begun before aspecific diagnosis has been reached. (The Merck Manual, 13th Edition,page 765, 1977)

Page 56


Analysis Challenges

Problem Domain Understanding• To design an accounting system, an analyst needs to become an

expert in accounting systems, and will probably need to understandthese systems better than the average user will.

Person-To-Person Communication• It is very difficult for people from different perspectives to share

ideas with each other. For example, an analyst and a user, or amanager and a worker.

Continual Change• Requirements will change. Your designs need to account for change

and should attempt to minimize their effect.

Reuse• Reuse of code as well as design and analysis results.


Factors Influencing Software Development

Walston and Felix compared several development efforts to identifythose factors having the greatest impact on that process as a function ofthe number of lines of code written per month.

1. Low User Interface Complexity.• 500 lines vs. 124 lines.

2. User Plays a Limited Role in Requirements Definition.• 491 lines vs. 205 lines.

3. Experienced Programming Team.• 410 lines vs. 132 lines.

Other factor such as design and programming methodologies had apositive effect, but not as great. IBM Systems Journal, 1977, 16(1).

Page 57


Process Maturity and OOAD

The Capability Maturity Model (CMM) for Software is a frameworkthat describes the key elements of an effective software process.

The Capability Maturity Model (CMM) was developed after realizingthat the fundamental problem of software development is the inabilityto managethe software process.

Once basic project management controls are in place, an OO approachcan be adopted as part of an organization’s standard software process(OSSP).


Project Management

Your first OO application will take longer.• Expect at least 25% longer.

There is a learning curve associated with adopting OO.

More of the total effort will be spent in analysis and design.• Expect about 60% of the total effort.

Class design is an iterativeprocess.• Spiral approach.• Radical waterfall approach.• Evolutionary approach.

Page 58


Moving to OO Software Development

Establish basic project management controls.• Requirements management.• Project planning.• Software quality assurance.• Software configuration management.

Invest in technology.• Commitment from management.• Training.• Purchase tools; purchase or build reusable components.• Adjust development practices (and thinking).

An OO project team should have the following characteristics.• Not rigid and willing to take risks.• Able to work under uncertainty.• Committed to new technology.• Peer and chief-programmer team structure.


More on Moving to OO

Selecting the First Project.• A new system with clean interfaces and little legacy code.• Large enough to be meaningful, but small enough to handle.• Support from senior management.

Why OO Projects Fail.• Expect OO technology to solve preexisting problems within a

group’s development process or culture.• Not sure how to manage transition to new technology.• Project management defering to programming team on management

issues, because of new technology.

Page 59


OO Advantages and Disadvantages

Advantages.• Enhanced modularity.• Unified approach.• Reuse and extendibility through ...

• Inheritance.• Polymorphism.• Encapsulation.

• Incremental life cycle useful when requirements are not wellunderstood.

Disadvantages.• Immaturity of techniques and tools.• Lack of standard notation.• Commitments required for maximizing reuse.• Inheritance complicates testing.• Incremental life cycle poses management challenges.


OO Vendors, Methodologies, and Tools

Object International, Inc. http://www.oi.com/• Methodology.

• Coad and Yourdon.• Tools.

• Together C++.• Playground.

Rational Software Corporation. http://www.rational.com/• Methodology.

• Booch.• Rumbaugh.• UML.

• Tools.• Rational Rose.• Rational CRC.

Page 60


Section 6: Case Studies

The following case studies will be used throughout this class forparticipants develop real designs and adapt them for use with objectoriented languages such as C++ or Java, and with non object orientedlanguages such as C.

• Widget Retail Sales System.• Two-Dimensional Graphics Library.• OOA Model.


Widget Retail Sales System

A certain company maintains an inventory of widgets, which it sells tothe general public. Widgets are identified by size, color and the numbercurrently in inventory. The system should also maintain information onthe name, address, phone number and credit limit of customers and thename, address, phone number, social security number, salary, and jobtitle of employees.

For each sale, the system should keep track of the widgets purchased. Asale may include a number of line items. For example, a customer maypurchase 5 big blue widgets and 3 little red widgets. The system shouldcompute a subtotal for each line item, tax, and a final total. In additionwe want to know the customer and employee involved in the sale.The system also keeps tack of purchase orders from widget suppliers. Alist of suppliers is maintained that includes name, address, phonenumber, and that supplier's wholesale price for the various widgets itcarries.

Page 61


Two-Dimensional Graphics Library

Develop an OOA model for a two-dimensional graphics library that canbe incorporated in applications which require graphics. The systemshould support points, rectangles, circles. The system should supportcolor as well as drawing, rotation, moving, and scaling those objects forwhich these services are appropriate.

Hint: Use an abstract class to define a generalized graphical object.

Hint: A location is a position. A point is a graphical object.

Hint: Don’t use a line graphical object as an intermediate class.

Continue with OOD by adding the necessary classes to the OOA resultsto create an implimentation-specific problem domain component. Showhow the graphics system could support at least two output devices: aplotter and a monitor.


OOA Model

Use the basic class/state/behavior/collaboration OOA notation todescribe the OOA notation itself. This might be necessary, for example,if you were to develop a case tool that supported this approach.

Hints:

• Start out by listing every concept in the notation, such as attributesand whole-part structures.

• Build structures from these concepts. For example, a classhasattributes.

• Add support for secondary models and documentation, such assubjects and data flow diagrams.

Page 62


1

11

1

ReturnScreenmediaTitlerunenterMediaTitle

connect

BorrowScreenborrowerNamemediaTitlerunenterBorrowerNameenterMediaTitle

connect

LibraryMenu

rundisplayMenugetUserSelectionexecuteUserSelection

BorrowidcheckOutDatecheckInDateborrowerIdmediaIdcheckOutMediacheckInMediastoreretrieve

retrieve, checkIn, store

Softwareformatcomputer

create, checkOut, store

execute selection

Borrow::retrieve(borrowerName, mediaTitle)Borrow::retrieve(id)

retrieve borrow from database based on id or name and title

Mediaidtitlesubjectstoreretrieve

type is faculty or student

execute selection

checkInMedia()set checkInDate to system date

Bookauthorpublisher

VideoTapeformatrating

checkOutMedia(borrowerName, mediaTitle)send getBorrowerId message to borrowersend getMediaId message to mediaset checkOutDate to system date

BorroweridnameofficeofficePhonetypestoreretrieve

LibraryContainer

run

. . .Not shown are whole-part

connections fromLibraryContainer to all

other classes.

Small Library Database System

mm


Widget Retail Sales

m

1

1 m

1

1m

1

10,m

(A.2)Customer

phonecreditLevel

EmployeeuserNameauthorization

WidgetOfferofferPrice

SalesTransactionItemquantityactualCost

calculateCostupdateWidget

(A.4)

(A.1)

Person (Abs)legalNameaddress

WidgetDescriptionnamesizecolorcostamountInStockamountOnOrderreorderLevel

adjustInventoryreordermakePO

SalesTransactiondatetotalsubTotaltax

calculateTotalcalculateTaxcalculateSubTotal

SuppliercompanyNameaddress

(A.3)

m

m

Page 63


0,m

1

1

1

1

0,1

paint

GraphicDevice (Abs)xLenyLen

init [abs]restore [abs]drawPoint [abs]drawRectangle [abs]drawCircle [abs]

CharGraphicDevice

initrestoredrawPointdrawRectangledrawCircle

Circleradius

drawscale

RectanglelengthheigthdegreesRotated

drawrotatescale

draw

Locationxy

ShapeContainer

paint

Shape (Abs)

color

draw [abs]move

Point

draw

Graphics Library


Servicenamedesc

prototype

OOA Model

Classnamedesc

class_type

Attributenamedesc

data_type

1

m

1

m

Connectionnamedesc

connect_type

m1

1 m

parent

child

connect_type = inheritance, aggregation, association,message

class_type = concrete, abstractdata_type = integer, string, etc.diagram_type = dfd, erd, std, etc.

Diagramnamedesc

diagram_typem m

Subjectnamedesc

m

m

m

m

se_ooad

Documents

dimensional graphics library

object oriented analysis

object oriented languages

object oriented programming

social security number

externally observable behavior

object oriented model

software engineering process