CSSE 501 Object-Oriented Development

Today…

Chapter 3: Object-Oriented Design

Questions

The rules of any programming language are its _____ A. Syntax B. Interpretation C. Logic D. Customs

A translator that notes whether you have used a language correctly might be a ______ A. Thesaurus B. Compiler C. Coder D. Decoder

Which type of statement does not occur in computer program ____ A. Sequence B. Loop C. Denial D. Selection

Programming in the Small and Programming in the Large

Chapter 3: Object-Oriented Design

Software development Ultimate goal: deliver software products

that are oriented towards Customer satisfaction Customer delight Customer ecstasy

Popular software development methodologies System Development Life Cycle (SDLC)

Model Prototyping Model Rapid Application Development Model Component Assembly Model

System Development Life Cycle (SDLC) Model

Waterfall model1. System/Information

Engineering and Modeling

2. Software Requirement Analysis

3. System Analysis and Design

4. Code Generation/

Implementation 5. Testing 6. Maintenance

Establish system view(Hardware, people, or Other resources)

Understand the nature of the software, define the problem that needs to be solved

Define the software's overall structure and its nuances

Translate design into programming languages

Different testing methodsto ensure the correctnessof the software

Dealing with changes, flaws etc.

Prototyping Model A cyclic version of the linear model Once the requirement analysis is done and the design for a

prototype is made, the development process gets started to create a prototype

Once the prototype is created, it is given to the customer for evaluation

Many iterations between customers’ feedback and developers’ refinement until the final software package is delivered

In this methodology, the software is evolved as a result of periodic shuttling of information between the customer and developer

Popular development model in the contemporary IT industry - as it is very difficult to comprehend all the requirements of a customer in one shot

New versions of a software product evolve as a result of prototyping

Prototyping Model( many versions)

or

Rapid Application Development (RAD) Model A "high speed" adaptation of the linear sequential model Achieved by using a component-based construction

approach The RAD approach encompasses the following phases:

Business modeling The information flow among business functions is modeled in a

way that answers the following questions: What information drives the business process? what information is generated? Who generates it? where does the information go? who processes it?

Data modeling The information flow defined as part of the business modeling

phase is refined into a set of data objects that are needed to support the business

The characteristic (called attributes) of each object is identified and the relationships between these objects are defined

Rapid Application Development (RAD) Model (Cont.)

Process modeling The data objects defined in the data-modeling phase are

transformed to achieve the information flow necessary to implement a business function

Processing the descriptions are created for adding, modifying, deleting, or retrieving a data object

Application generation The RAD model assumes the use of the RAD tools like VB, VC++,

Delphi etc... rather than creating software using conventional third generation programming languages

The RAD model works to reuse existing program components (when possible) or create reusable components (when necessary)

In all cases, automated tools are used to facilitate construction of the software

Testing and turnover Since the RAD process emphasizes reuse, many of the program

components have already been tested. This minimizes the testing and development time

Component Assembly Model Object technologies provide the technical framework for a

component-based process model for software engineering The object oriented paradigm emphasizes the creation of

classes that encapsulate both data and the algorithm that are used to manipulate the data

If properly designed and implemented, object oriented classes are reusable across different applications and computer based system architectures

Component Assembly Model leads to software reusability. The integration/assembly of the already existing software components accelerate the development process

Nowadays many component libraries are available on the Internet. If the right components are chosen, the integration aspect is made much simpler

What/Why is Software Design Software design sits at the crossroads of all the computer disciplines:

hardware and software engineering, programming, human factors research, ergonomics. It is the study of the intersection of human, machine, and the various interfaces—physical, sensory, psychological—that connect them --- by Association for Software Design (ASD) members

Design is conscious Design keeps human concerns in the center Design is a dialog with materials Design is creative Design is communication Design is a social activity Design has social consequences

Basis for Design Consider for the moment what aspects of a

problem (i.e., to develop a system) are known first: Data Structures Functions A Formal Specification Behavior

A design technique based on behavior can be applied from the very beginning of a problem, whereas techniques based on more structural properties necessarily require more preliminary analysis

Design Notations/Modeling Languages Many artifacts generated during the

process of software development Requirement specifications Design documents Source code User manual

Design notations capture design documents Informal (natural languages) Unified Modeling Languages (UML, semi-formal) Formal (formal methods, architecture description

languages)

Object-Oriented Design Techniques/Methods

Object-Oriented Development (OOD)/Booch Hierarchical Object-Oriented Design

(HOOD) The Object Modeling Technique (OMT) Responsibility-Driven Design (RDD)/Class-

Responsibility-Collaboration (CRC) Object-Oriented Analysis (OOA) …

Object-Oriented Development (OOD)/Booch Define the problem Develop an informal strategy for the

software realization of the real world problem domain

Formalize the strategy Identify the classes and objects at a given level

of abstraction Identify the semantics of these classes and

objects Identify the relationships among these classes

and objects Implement these classes and objects

Object-Oriented Development (OOD)/Booch (Cont.)

Major advantages Rich notation available:

class diagrams (class structure - static view) object diagrams (object structure - static view) state transition diagrams (class structure -

dynamic view) timing diagrams (object structure - dynamic

view) module diagrams (module architecture) process diagrams (process architecture)

Object-Oriented Development (OOD)/Booch (Cont.)

A Booch Class Diagram for a Company

The Object Modeling Technique (OMT) A method which leads to three models of the system

corresponding to three different views of the system The object model

Describes the static structure of the objects in a system and their relationships

Main concepts are: class, attribute, operation, inheritance, association (i.e. relationship), aggregation

The dynamic model Describes the aspects of the system that change over time Used to specify and implement the control aspects of a

system Main concepts are: state, sub/super state, event, action,

activity The functional model

Describes the data value transformations within a system Main concepts are: process, data store, data flow, control

flow, actor (source/sink)

The Object Modeling Technique (OMT)(Cont.) The method is divided into four phases, which are stages of

the development process Analysis

The building of a model of the real world situation, based on a statement of the problem or user requirements

System design The partitioning of the target system into subsystems, based

on a combination of knowledge of the problem domain and the proposed architecture of the target system (solution domain)

Object design Construction of a design, based on the analysis model enriched

with implementation detail, including the computer domain infrastructure classes

Implementation Translation of the design into a particular language or hardware

instantiation, with particular emphasis on traceability and retaining flexibility and extensibility

The Object Modeling Technique (OMT)(Cont.)

An Object Model of a Company

Responsibility Driven Design (RDD) Developed as Rebecca Wirfs-Brock

One of object-oriented design techniques, driven by an emphasis on behavior at all levels of development

A design technique that has the following properties: Can deal with ambiguous and incomplete

specifications Naturally flows from Analysis to Solution Easily integrates with various aspects of software

development

Responsibility Driven Design (RDD)

Describing the actions and activities for which our software is responsible

Describing the responsibilities in terms that both users and developers can understand

Designing software objects that implement those responsibilities

Responsibility Driven Design (RDD)

RDD is not a sequential process

Steps in RDD Software components Formalize interfaces Designing and representations Implementing components Integration of components Maintenance and evolution

Case Study: the IIKH

Briefly, the Intelligent Interactive Kitchen Helper (IIKH) will replace the box of index cards of recipes in the average kitchen

Your Job

Imagine you are the chief software architect

Your job is to develop the software that will implement the IIKH

Abilities of the IIKH

Here are some of the things a user can do with the IIKH: Browse a database of recipes Add a new recipe to the database Edit or annotate an existing recipe Plan a meal consisting of several courses Scale a recipe for some number of users Plan a longer period, say a week Generate a grocery list that includes all the

items in all the menus for a period

Characterization by Behavior Just as an Abstract Data Type is characterized more

by behavior than by representation, the goal in using Responsibility Driven Design will be to first characterize the application by behavior First capture the behavior of the entire application Refine this into behavioral descriptions of subsystems Refine behavior descriptions into code

This emphasis on behavior is a hallmark of Object-Oriented programming

Working Through Scenarios Because of the ambiguity in the specification, the

major tool here used to uncover the desired behavior is to walk through application scenarios Pretend there is already a working application Walk through the various uses of the system

Establish the “look and feel'' of the system Make sure uncover all the intended uses Develop descriptive documentation Create the high level software design

The term “use-cases'' used for this process of developing scenarios by others

Example: Browsing Scenario Alice Smith starts the IIKH IIKH displays welcome message Alice presses the return button to begin Alice is given a choices of a number of options Alice selects to browse recipe Alice enters keywords to search, e.g., salmon, dill weed IIKH return two results Alice selects the first IIKH displays a window, showing everything regarding the

recipe Alice does not want the recipe, returns to the search result

page Alice selects the second recipe Alice wants the recipe Alice selects “quit” from the IIKH program menu The IIKH program quits

Software Components

A software component is simply an abstract design entity with which we can associate responsibilities for different tasks

May eventually be turned into a class, a function, a module, or something else A component must have a small well defined set

of responsibilities A component should interact with other

components to the minimal extent possible

CRC (Component, Responsibility, Collaborator) Cards

Components are most easily described using CRC cards

A CRC card records the name, responsibilities, and collaborators of an component Inexpensive, Erasable, Physical

The first component, The Greeter Let us return to the development of the IIKH. The first

component your team defines is the Greeter

When the application is started, the Greeter puts an informative and friendly welcome window (the greeting) on the screen Offer the user the choice of several different actions

Casually browse the database of recipes Add a new recipe Edit or annotate a recipe Review a plan for several meals Create a plan of meals

Many of the details concerning exactly how this is to be done can be ignored for the moment

The Greeter

The Recipe Database Component

Ignoring the planning of meals for the moment, your team elects to next explore the recipe database component Must maintain the database of recipes Must allow the user to browse the

database Must permit the user to edit or annotate

an existing recipe Must permit the user to add a new recipe

The Who/What Cycle As we walk through scenarios, we go through cycles of

identifying a what, followed by a who What action needs to be performed at this moment Who is the component charged with performing the

action

Every what must have a who, otherwise it simply will not happen

Sometimes the who might not be obvious at first, i.e., who should be in charge of editing a recipe?

Postponing Decisions Many decisions, such as the method of browsing, can

be ignored for the moment, as they are entirely encapsulated within the recipe database component, and do not effect other components Scroll bars and windows? A virtual “book'' with thumb-holes and flipping pages? Keywords and phrases?

Only need to note that somehow the user can manipulate the database to select a specific recipe

Responsibilities of a Recipe We make the recipe itself into an active data

structure. It maintains information, but also performs tasks Maintains the list of ingredients and transformation

algorithm (i.e., ingredients to final product) Must know how to edit these data values Must know how to interactively display itself on the

output device Must know how to print itself

We will add other actions later (ability to scale itself, produce integrate ingredients into a grocery list, and so on)

The Planner Component

Returning to the greeter, we start a different scenario. This leads to the description of the Planner Permits the user to select a sequence of

dates for planning Permits the user to edit an existing plan Associates with Date object

The Date Component

The Date component holds a sequence of meals for an individual date User can edit specific meals User can annotate information about

dates (''Bob's Birthday'', “Christmas Dinner'', and so on)

Can print out grocery list for entire set of meals

The Meal Component

The Meal component holds information about a single meal Allows user to interact with the recipe database

to select individual recipes for meals User sets number of people to be present at

meal, recipes are automatically scaled Can produce grocery list for entire meal, by

combining grocery lists from individual scaled recipes

The Six Components Having walked through the various scenarios, you team

eventually decides everything can be accomplished using only six software components

You can at this point assign the different components to different programmers for development

Interaction Diagrams The picture on the previous slide captures static

relationships, but not the dynamic flow of messages in a scenario

That information can be recorded by an interaction

diagram

Characteristics of Components

Let us return to the idea of a software component

There are many different aspects to this simple idea, we will consider just a few: Behavior and state Instances and classes Coupling and cohesion Interface and implementation

Behavior and State All components can be characterized by two

aspects The behavior of a component is the set of actions a

component can perform. The complete set of behavior for a component is sometimes called the protocol

The state of a component represents all the information (data values) held within a component

Notice that it is common for behavior to

change state. For example, the edit behavior of a recipe may change the preparation instructions, which is part of the state

Instances and Classes

We can now clarify a point we earlier ignored. There are likely many instances of recipe, but they will all behave in the same way. We say the behavior is common to the class Recipe

Coupling and Cohesion The separation of tasks into the domains of different

components should be guided by the concepts of coupling and cohesion

Cohesion is the degree to which the tasks assigned to

a component seem to form a meaningful unit Want to maximize cohesion

Coupling is the degree to which the ability to fulfill a certain responsibility depends upon the actions of another component Want to minimize coupling

Interface and Implementation

We have characterized software components by what they can do

The user of a software component need only know what it does, not how it does it

“Ask not what you can do to a data structure, ask instead what your data structures can do for you''.

Two views of a Software System

This naturally leads to two views of a software system

The term information hiding is used to describe the purposeful hiding of implementation details

Parnas' Principles These ideas were captured by computer

scientist David Parnas in a pair of rules, which are known as Parnas' Principles: The developer of a software component must

provide the intended user with all the information needed to make effective use of the services provided by the component, and should provide no other information

The implementer of a software component must be provided with all the information necessary to carry out the given responsibilities assigned to the component, and should be provided with no other information

Public and Private View

In C++ and Java, Parnas's Principles lead to the ideas of a public and private view Public view - those features (data or

behavior) that other components can see and use

Private view - those features (data or behavior) that are used only within the component

Next Step - Formalize the Interface The next step is to formalize the channels of

communication between the components The general structure of each component is identified Components with only one behavior may be made

into functions Components with many behaviors are probably more

easily implemented as classes Names are given to each of the responsibilities -

these will eventually be mapped on to procedure names

Information is assigned to each component and accounted for

Scenarios are replayed in order to ensure all data is available

Names with Activities

The selection of names is an important task Names should be evocative in the context of the

problem Names should be short Names should be pronounceable (read them out

load) Names should be consistent within the project Avoid digits within a name

Documentation

Besides CRC cards, it is important that the development of other documentation be performed almost from the beginning

The two most important documents are the user manual and the design documentation of the software system

User Manual

The user manual describes the application as seen by the user Does not depend upon the implementation, so

can be developed before the implementation

Can naturally flow from the process of walking through scenarios

Can be carried back to the clients to make sure the users and the implementers have the same ideas

Quality You should always remember that the primary

measure of quality is the degree to which your customers (clients) are satisfied with your product

Since often customers do not know exactly what it is they want, it is important to work with the client early in the design phase to make sure the system your are developing is the desired product

One very important way to do this is to create the user manual even before the software is written

System Design Documentation Record the decisions made during the

process of system design Record the arguments for and against any major

decision, and the factors influencing the final choice

Record CRC cards for the major components Maintain a log or diary of the process schedule Important to produce this while the ideas are

fresh, not in hindsight when many details will have been forgotten

Note the code only records the outcome of decisions, not factors that lead up to decisions being made

Preparing for Change Your design team should also keep in mind that

change is inevitable

Users requirements change with experience, hardware changes, government regulations change Try to predict the most likely sources of change, and

isolate the effect Common changes include interfaces, file formats,

communication protocols Isolate interfaces to hardware that is likely to change Reduce dependency of one software component on

another Keep accurate record of the reasoning behind every

major decision in the design documentation

Next Step - Select Representations for Subsystems

Next the internal representation of the software subsystem corresponding to each component is selected

Knowledge of the classic data structures of

Computer Science is important here

Often once data structures have been selected, the code is almost self-evident

Next Step - Implement and Test Subsystems Classic techniques, such as stepwise

refinement, are used to implement each of the subsystems

Subsystems are validated in isolation Informal proofs of correctness for the subsystem

are developed Identify necessary conditions for correct

functioning. Try to minimize conditions, and test input values whenever possible

Software testing is used as a confidence building measure

Step - Integration and Testing Components are slowly integrated into

completed system

Stubs can be used to perform testing all during integration

Errors discovered during integration to

cause reinvestigation of validation techniques performed at the subsystem level

Maintenance and Evolution Software does not remain fixed after the first working

version is released Errors or bugs can be discovered. Must be corrected Requirements may change. Say as a result of

government regulations, or standardization among similar products

Hardware may change Users expectations may change. Greater

functionality, more features. Often as a result of competition from similar products

Better documentation may be required. A good design recognizes the inevitability of change,

and plans an accommodation for these activities from the very beginning

Common Design Flaws The following categories present some of the more common design

flaws: Direct modification

Components that make direct modification of data values in other components are a direct violation of encapsulation

Such coupling makes for inflexible designs Too Much Responsibility

Components with too much responsibility are difficult to understand and to use Responsibility should be broken into smaller meaningful packages and distributed

No Responsibility Components with no responsibility serve no purpose Often arise when designers equate physical existence with logical design existence “Money is no object''

Components with unused responsibility Usually the result of designing software components without thinking about how

they will be used Misleading Names

Names should be short and unambiguously indicate what the responsibilities of the component involve

Exercise: Use RDD to Develop an ATM system

Describe the behavior (as complete as possible)

Walking through 2 scenarios Software components (CRC cards) Interaction between these

components