CSCI-383 Lecture 5-6-7: Object-Oriented Design

Lecture 5-6-7: Object-Oriented Design

CSCI-383Object-Oriented Programming & Design

Ji Ruan2009/09/23-25-28

StFX University, Canada

Overview

• Introduction• Responsibility-Driven Design• Case Study with Design Components• UML Diagrams• Steps of Software Design

Why Start with Design?

• It is the easiest way to develop an appreciation of the problems of programming in the large (realistic modern software development).

• Without understanding programming in the large, one cannot understand the importance of OOP.

Programming in the Small and in the Large

Programming in the Small: • One programmer understands everything

from top to bottom. • Major problem is the development of

algorithms.

Programming in the Large:• A system is developed by large team (e.g. graphic artists,

design experts, programmers, testers)• The major problem is the management of details and

communication among diverse portion of the project.

Basis for Design

• Consider for the moment what aspects of a problem are known first: o Data Structures o Functions o A Formal Specification o 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.

Responsibility-Driven Design (RDD)

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.

Directed Evolution

• Let us take specifications as they occur in nature o Imprecise oAmbiguous oUnclear

• and rather than attempt to change human nature, let us direct the evolution of the specification in concert with the design of the software system.

An Example, the IIKH

• Imagine you are the chief software architect in a major computing firm.

• The president of the firm rushes into your office with a specification for the next PC-based product. It is drawn on the back of a dinner napkin.

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

Your Job

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.o First capture the behavior of the entire application. o Refine this into behavioral descriptions of subsystems. o 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 we will use to uncover the desired behavior is to walk through application scenarios. o Pretend we had already a working application. Walk

through the various uses of the system. o Establish the ``look and feel'' of the system. o Make sure we have uncovered all the intended uses. o Develop descriptive documentation. o Create the high level software design.

• Other authors use the term ``use-cases'' for this process of developing scenarios.

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. o A component must have a small well defined set of

responsibilities o A component should interact with other components to the

minimal extent possible

CRC Cards: Recording Responsibility• CRC (Component, Responsibility, Collaborator)• Components are most easily described using CRC cards. • A CRC card records the name, responsibilities, and

collaborators of an component. • Advantage: Inexpensive, Erasable, Physical

Different ComponentsLet us return to the development of the IIKH.• The Greeter Components• The Recipe Database Component• The Recipe Component• The Planner Component• The Date Component• The Meal Component

Component 1: The Greeter

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.

Component 1: The Greeter

CRC card for the Greeter:

Component 2: The Recipe Database

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. o Scroll bars and windows? o A virtual "book'' with thumb-holes and flipping pages? o Keywords and phrases?

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

Component 3: The 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. • 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).

Component 4: The Planner

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.

Component 5: The Date

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.

Component 6: The Meal

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 senario. That information can be recorded by an interaction diagram.

Unified Modeling Language (UML)

• UML is a standard language for:o Specifying, visualizing, constructing, and

documenting the artifacts of software systems o Also works for business modeling and other non-

software systems• A collection of best engineering practices that have

proven successful in the modeling of large and complex systems.

• The slides on UML are compiled based on [1] UML Resource page, OMG.; [2] UML, Wikipedia; [3] UML tutorial by Kennesaw State University.

Goals of UML

• Provide users with a ready-to-use, expressive visual modeling language.

• Provide extensibility and specialization mechanisms to extend the core concepts.

• Be independent of particular programming languages and development processes.

• Provide a formal basis for understanding the modeling language.

• Encourage the growth of the OO tools market. • Support higher-level development concepts such as

collaborations, frameworks, patterns and components. • Integrate best practices.

Why use UML?

• To automate the production of software• To improve quality and reduce cost and time-to-market.

o These techniques include component technology, visual programming, patterns and frameworks.

• To manage the complexity of systems. o physical distribution, o concurrency, o replication, o security, o load balancing o and fault tolerance. o World Wide Web has exacerbated these architectural

problems

Standardization

• Officially defined by the Object Management Group (OMG)

• UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages

History Of UML• Late 1994

o Grady Booch, the Booch methodo Jim Rumbaugh, OMT (Object Modeling Technique) method

• Fall of 1995o Ivar Jacobson (with his Objectory company), the OOSE (Object-

Oriented Software Engineering) method• Reasons for Merging

1. Evolving toward each other independently• Bring some stability to the OO marketplace• Yield improvements in all three earlier methods

• 1996, the international consortium UML partners was formed• Jan 1997, UML partners proposed UML 1.0 spec draft to the OMG

Diagrams Overview

• Structure diagramso Emphasize what things must be in the system being

modeled• Behavior diagrams

o Emphasize what must happen in the system being modeled

• Interaction diagrams o Subset of behavior diagramso Emphasize the flow of control and data among the

things in the system being modeled

Diagrams Overview






Behavior diagrams

• Use case diagram: Displays the relationship among actors and use cases

• Activity diagram: describe the workflow behavior of a system

• State diagram: Displays all of the possible states of an object as events occur

Use case diagram

• Definition: A use case is a set of scenarios that describing an interaction between a user and a system

• Two main componentso Actors: represents a user or another system that will

interact with your systemo Use cases

Use case diagram• Start by listing a sequence of steps

a user might take in order to complete an action

• E.g. a user placing an order with a sales company might follow these steps o Browse catalog and select items. o Call sales representative. o Supply shipping information. o Supply payment information. o Receive conformation number from

salesperson. o These steps would generate this simple

use case diagram

Activity diagram

When• To model a workflow• To analyze a use case• To describing a complicated sequential

algorithm• To model applications with parallel

processes

How• Top to bottom• A fork is used when multiple activities are

occurring at the same time• A branch describes what activities will take

place based on a set of conditions.

Activity diagram Example

Example: processing an order• the order is received• two parallel sets of

activities• One side fills and sends

the order• One handles the billing • close the order

State Diagram

When• To demonstrate the behavior of

an object through many use cases of the system

• NOT all classes will require a state diagram

• NOT useful for describing the collaboration of all objects in a use case

State Diagram

How• Rounded boxes as states• Arrows for transition• Solid circle as the initial

state• Conditions based on the

activities can determine what the next state the object transitions to

State Diagram

An Example: Order object

UML Diagrams Overview






Interaction diagram

When• To model the behavior of several objects in a

use case

Two kinds• Sequence diagrams: generally show the

sequence of events that occur• Collaboration diagrams: demonstrate how

objects are statically connected

Interaction diagram

Sequence diagrams• How : left to right and

descending• Example: placing an

order [InStock] [OutOfStock] are conditions

Interaction diagram

Collaboration diagrams• How: Objects listed as

icons and arrows; Sequence numbers

• Example: placing an order

Activity vs. State vs. Interaction

• Activity Diagramo Workflow (activity) of a system

• State Diagramo All possible states of an objecto Through many use cases (as long as the object is involved

in the use case)• Interaction Diagram

o Interaction of several objectso Within a use case

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: o 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.

o 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 ClassesThere 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.

Since earlier our goal was to identify behavior, we ignored this distinction and concentrated on prototypical objects.

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.

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: 1. 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 implementor 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

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 Selection

Government bureaucrats have long shown us that obscure names can make even the simplest operation sound intimidating.

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 implementors 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.

Step - Implement and Test Subsystems

• Classic techniques, such as stepwise refinement, are used to implement each of the subsystems.

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

developed. o Identify necessary conditions for correct functioning. Try

to minimize conditions, and test input values whenever possible.

o 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.

Maintainence and Evolution

• Software does not remain fixed after the first working version is released. o Errors or bugs can be discovered. Must be corrected. o Requirements may change. Say as a result of government regulations, or

standardization among similar products. o Hardware may change. o Users expectations may change. Greater functionality, more features. Often

as a result of competition from similar products. o 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• 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.

• Ex 3.1: Describe the responsibilities of a hospital that includes at least six types of members. For each member type, describe the responsibilities and the collaborators using CRC cards.

• Ex 3.2: Create a scenario for the hospital you described in Ex 3.1 using an interaction diagram.

• Deadline: Wed, October 7th, 2009.

Assignment 3:

About these slides

These slides are created by Dr. Ji Ruan on top of the lecture notes by Prof. Wendy MacCaull and Dr. Hao Wang from their previous years' teaching on this course at StFX University.

The core materials are based on book: An introduction to Object-Oriented Programming, 3rd edition, by Timothy Budd.

The slides are licensed under Creative Commons Attribution-Share Alike 3.0

You are free to Share and Remix this work, under the following conditions: • Attribution• Share Alike

Date post:	24-May-2015
Category:	Technology
Upload:	ji-ruan
View:	719 times
Download:	0 times

CSCI-383 Lecture 5-6-7: Object-Oriented Design

Technology