CS 596: Client Server Programming
Design

1. Overview of Design
   1. Exploratory Phase
2. Exploratory Phase
   1. Modules
      1. Finding Modules
      2. Record Your Candidate Modules
      3. Finding Abstract Classes
   2. Responsibilities
      1. Identifying Responsibilities
      2. Assigning Responsibilities
      3. Recording Responsibilities
   3. Collaboration
      1. Finding Collaborations
      2. Recording Collaborations

• Who is on the team?

What are the goals of the system?

What must the system accomplish?

What module are required to model the system and accomplish the goals?

• What are their tasks, responsibilities?

What does each module have to know in order to accomplish each goal it is involved with?

What steps toward accomplishing each goal is it responsible for?

• Who works with whom?

With whom will each module collaborate in order to accomplish each of its responsibilities?

What is the nature of the module s' collaboration

One module requests a service of another module

The module making the request

The module receiving the request

• Model physical objects

Disks

Printers Airplanes

• Model conceptual entities that form a cohesive abstraction

Window

File Bank Account

• If more than one word applies to a concept select the one that is most meaningful

• Be wary of the use of adjectives

Adjective-noun phrases may or may not indicate different modules

Is selection tool different than creation tool?

Is start point different from end point from point?

• Be wary of passive voice

A sentence is passive if the subject of the verb receives the action

Passive:

The music was enjoyed by us

Active:

We enjoyed the music

• Model categories of modules

Categories may indicate inheritence

Keep them as individual modules at this point

• Model known interfaces to outside world

User interfaces

Interfaces to other programs

Write a description of how people will use the system. This description is a source of interface modules.

• Model the values of attributes, not the attributes themselves

Height of a rectangle

Height is an attribute of rectangle

Value of height is a number

Rectangle can record its height

Structure

	"Kind of" and "part of" relationships

Other systems

	External systems with which the application interacts

Devices

	Devices with which the application interacts

Events remembered

	Historical event that must be recorded

Roles played

	Different roles users play in interacting with application

Locations

	Physical locations, offices and sites important to the application

Organizational units

People
	Humans who carry out some function
	Farmers

Places
	Areas set aside for people or things
	Fields on farm

Things
	Physical objects or groups of objects
	Plants	leaves	roots

Organizations
	Formally organized collections of people, resources, facilities
	Union	farm crew

Concepts
	Principles or ideas not tangible

Events
	Things that happen

Tangible things
	Cars		telemetry data	

Roles
	Mother 		teacher

Events
	Landing		interrupt

Interactions
	Loan		meeting

Principle responsibility is to maintain data

Examples: stack, collections, sets

Generate data or accept data and process it further

Do not hold data for long

Examples: Random number generator, File IO module

Example: GUI modules

Maintain little or no state information

Assist in execution of complex tasks

list the attributes shared by classes in the group and derive the name from those attributes

Divide groups into smaller, more clearly defined groups

• Data Structures

• Operations

Verbs indicate possible actions

Information indicates modules responsibilities

What role does the module fill in the system?

Statement of purpose for module implies responsibilities

Imagine how the system will be used

What situations might occur?

Scenarios of using system

A sequence of events between the system and an outside agent, such as a user, a sensor, or another program

Outside agent is trying to perform some task

Interactions without any unusual inputs or error conditions

Consider omitted input sequences, maximum and minimum values, and repeated values

Consider user error such as invalid data and failure to respond

What the system knows

Actions that can be performed

Impact on other parts of the system and users

Dumb version

A data structure holding name, age, salary, etc.

Smart version

An module that:

Matches security clearance with current project

Salary is in proper range

Health benefits change when person gets married

Create a new module to hold the information

Collapse the modules into a single module

Place information in the more natural module

Implies inheritance

If module X is-analogous-to module Y then look for superclass

If module A is-part-of module B then there is no inheritance

Some negotiation between A and B for responsibilities may be needed

Example:

Assume A contains a list that B uses

Who sorts the list? A or B?

A set of unassigned responsibilities may indicate a need for another module

Group related unassigned responsibilities into a new module

Sometimes a responsibility may seem to fit into two or more module

Perform a walk-through the system with each choice

Ask others

Explore ramifications of each choice

If the requirements change then which choice seems better?

Is module capable of fulfilling this responsibility?

If not, what does it need?

From what other module can it acquire what it needs?

What does this module do or know?

What other modules need the result or information?

If a module has no interactions, discard it

Interactions in the scenarios indicate collaboration

X is composed of Y's

Composite modules

Drawing is composed of drawing elements

Some distribution of responsibilities required

Container modules

Arrays, lists, sets, hash tables, etc.

Some have no interaction with elements