Class Design, Implementation modeling

Overview of Class Design – steps

1. Bridging the gap

2. Realizing Use Cases
3. Designing Algorithms
4. Recursing Downward
5. Refactoring
6. Design Optimization
7. Reification of Behavior
8. Adjustment of Inheritance
9. Organizing a Class Design

1. Bridging the gap – sometimes there are disconnection or gap between the desired features and the
available resources and the best possible way is to bridge that disconnection. In that case intermediate
elements can be invented to bridge that gap.

2. Realizing Use Cases – in the design phase an operations and objects that has the behavior to realize
use cases with operations must be invented.

Step1: List the responsibilities of a use case or operation.

Step2: Each operation will have various responsibilities.

Step3: Define an operation for each responsibility cluster.

Step4: Assign the new lower-level operations to classes.

3. Designing Algorithms - Formulate an algorithm for each operation. The analysis specification tells
what the operation does for its clients. The algorithm show how it is done.

i. Choose algorithms that minimize the cost of implementing operations.

 When efficiency is not an issue, you should use simple algorithms.

 Typically, 20% of the operations consume 80% of execution time.

 Considerations for choosing alternative algorithms

o Computational complexity

o Ease of implementation and understandability

o Flexibility

o Simple but inefficient

o Complex efficient
 ii. Select data structures appropriate to the algorithms

a. Algorithms require data structures on which to work.

b. They organize information in a form convenient for algorithms.

c. Many of these data structures are instances of container classes.

d. Such as arrays, lists, queues, stacks, set…etc.

iii. Define new internal classes and operations as necessary.

a. To invent new, low-level operations during the decomposition of high-level

operations.

b. The expansion of algorithms may lead you to create new classes of objects to
hold intermediate results.

ATM Example:

i. Process transaction uses case involves a customer receipt.

ii. ii. A Receipt class is added.

iv. Assign operations to appropriate classes.

a. How do you decide what class owns an operation?

i. Receiver of action

ii. To associate the operation with the target of operation, rather than
the initiator.

b. Query vs. update

i. The object that is changed is the target of the operation

c. Focal class

i. Class centrally located in a star is the operation’s target

d. Analogy to real world

4. Recursing Downward - To organize operations as layers.

Two ways of downward recursion:

 By functionality

Take the required high-level functionality and break it into lesser

operations.

 By mechanism

Build the system out of layers of needed support mechanisms

 Any large system mixes functionality layers and mechanism layers

5. Refactoring - Changes to the internal structure of software to improve its design without altering its
external functionality.

6. Design Optimization - To design a system is to first get the logic correct and then optimize it. Often a
small part of the code is responsible for most of the time or space costs.

 Optimized system is more obscure and less likely to be reusable.

 You must strike an appropriate balance between efficiency and clarity.

 Tasks to optimization:

i. Provide efficient access paths.

ii. Rearrange the computation for greater efficiency.
iii. Save intermediate results to avoid re computation.

7. Reification of Behavior - Behavior written in code is rigid; you can execute but cannot manipulate it at
run time. If you need to store, pass, or modify the behavior at run time, you should reify it

8. Adjustment of Inheritance - To increase inheritance perform the following steps

– Rearrange classes and operations to increase inheritance

– Abstract common behavior out of groups of clusters

– Use delegation to share behavior when inheritance is semantically invalid

9. Organizing a Class Design - We can improve the organization of a class design with the following steps:

– Information hiding

– Coherence of Entities

– Fine-tuning packages
DESIGN PATTERNS

Patterns:

 Patterns help you build on the collective experience of skilled software engineers.

The architect Christopher Alexander defines the term pattern as

 Each pattern is a three-part rule, which expresses a relation between a certain context, a problem,
and a solution

Properties of patterns for Software Architecture

 A pattern addresses a recurring design problem that arises in specific design situations, and presents a
solution to it.

 Patterns document existing, well-proven design experience.

 Patterns identify & and specify abstractions that are above the level of single classes and instances, or
of components.

 Patterns provide a common vocabulary and understanding for design principles

 Patterns are a means of documenting software architectures.

 Patterns support the construction of software with defined properties.

 Patterns help you build complex and heterogeneous software architectures

 Patterns help you to manage software complexity

What Makes a Pattern?

Three-part schema that underlies every pattern:

Context: a situation giving rise to a problem.

Problem: the recurring problem arising in that context.

Solution: a proven resolution of the problem.

Pattern Categories we group patterns into three categories:

 Architectural patterns - Architectural patterns are used to describe viable software architectures that
are built according to some overall structuring principle.

 Design patterns - Design patterns are used to describe subsystems of a software architecture as well
as the relationships between them (which usually consists of several smaller architectural units)

 Idioms - Idioms deals with the implementation of particular design issues.

DESIGN PATTERNS

Design Patterns Management

Systems must often handle collections of objects of similar kinds, of service, or even complex
components.

E.g.1 Incoming events from users or other systems, which must be interpreted and scheduled
approximately.

e.g.2 When interactive systems must present application-specific data in a variety of different way, such
views must be handled approximately, both individually and collectively.

 In well-structured s/w systems, separate manager components are used to handle such
homogeneous collections of objects.

For these two design patterns are described

 The Command processor pattern

 The View Handler pattern

Command Processor

 The command processor design pattern separates the request for a service from its execution.
A command processor component manages requests as separate objects, schedules their execution, and
provides additional services such as the storing of request objects for later undo.

Context:

Applications that need flexible and extensible user interfaces or Applications that provides
services related to the execution of user functions, such as scheduling or undo.

Problem:

 Application needs a large set of features.

 Need a solution that is well-structured for mapping its interface to its internal functionality

 Need to implement pop-up menus, keyboard shortcuts, or external control of application via a
scripting language

 We need to balance the following forces:

 Different users like to work with an application in different ways.

 Enhancement of the application should not break existing code.

 Additional services such as undo should be implemented consistently for all requests.
Solution:

 Use the command processor pattern

 Encapsulate requests into objects

 Whenever user calls a specific function of the application, the request is turned into a
command object.

 The central component of our pattern description, the command processor component takes
care of all command objects.

 It schedules the execution of commands, may store them for later undo and may provide
other additional services such as logging the sequences of commands for testing purposes.

Example : Multiple undo operations in Photoshop

Structure:

 Command processor pattern consists of following components:

o the abstract command component o A command component

o the controller component

o the command processor component

o the supplier component

Components

 Abstract command Component:

• Defines a uniform interface of all command’s objects

• At least has a procedure to execute a command

• May have other procedures for additional services as undo, logging, …