Chapter 8- Object oriented design

8.1. Introduction

Purpose:

 Analysis: Identify business needs.

 Design: Determine how to build the system.

Major Environmental Factors contributing for Transition to Design Modeling:

1. Integration with existing systems.

2. Data conversion from legacy systems.
3. Leveraging in-house skills.

Initial Stage Design:

 Examine and select a design strategy:

1. Build in-house.
2. Purchase and customize.
3. Outsource (refer to Chapter 5).

Detailed design tasks include:detailed design of->

o Individual classes and methods.

o Storage methods.
o Techniques:(for the detailed design)

 CRC cards.
 Class diagrams.
 Contract and method specifications.
 Database design (refer to Chapter 5).

 Additional design considerations:

o UI design.
o Physical architecture.
o Hardware/software purchasing decisions.
o System processing organization (refer to Chapter 5).

8.2. Verifying and Validating the Analysis Models

Objective:

 Ensure analysis models represent the problem domain.

 Confirm consistency across functional, structural, and behavioral models.

A set of rules to help verify & validate the intersection of the analysis models

Balancing Models:

1
Is a process of ensuring consistency among analysis models.

Functional & Structural Models:

1. Classes on class diagrams/CRC cards must link to at least one use case and
vice versa.
2. Activities/actions in activity diagrams and use-case descriptions must relate
to responsibilities on CRC cards and class operations.
3. Object nodes in activity diagrams must associate with class
instances/attributes in class diagrams or CRC cards.
4. Attributes and relationships on CRC cards must align with event
subjects/objects in use-case descriptions.

Functional & Behavioral Models:

1. Sequence and communication diagrams must associate with use cases on

diagrams/descriptions.
2. Actors in sequence/communication diagrams or CRUDE matrices must align
with actors in use-case diagrams/descriptions.
3. Messages, transitions, and CRUDE entries must relate to activities/actions in
activity diagrams and events in use-case descriptions.
4. Object nodes in activity diagrams for complex objects must correspond to
behavioral state machines representing their life-cycle.

Structural & Behavioral Models:

1. Objects in CRUDE matrices must associate with classes in CRC cards and
class diagrams.
2. Behavioral state machines (BSMs) must represent the life-cycle of class
instances and align with CRC cards.
3. Sequence/communication diagram objects must instantiate classes in CRC
cards/class diagrams.
4. Messages, transitions, and CRUDE entries must connect to CRC card
responsibilities and class operations.
5. States in BSMs must associate with attribute values of objects.

Key Takeaway:

 Balancing functional, structural, and behavioral models ensures a strong foundation

for system design.

8.3. Evolving the Analysis Models into Design Models

Focus Areas:during->

 Analysis: Functional problem domain modeling (ignores nonfunctional requirements).

 Design: Address functional and nonfunctional requirements, refining analysis models
with system environment/solution domain details.

Strategies to Evolve Models(to design):

2
Factoring:

o Separate modules into stand-alone components (e.g., new classes or

methods).
o Example: Generalize shared attributes/methods into a new class or
aggregate relationships ("a-kind-of" or "has-parts").

Partitions & Collaborations:

o Modeled using package diagrams.

o Partitioning(OO equivalent of subsystem) Principles:

 High activity (messages sent) among objects suggests grouping into

the same partition.
 Collaboration identification via communication diagrams.
 Use CRUDE analysis to merge related collaborations.
 Group objects with more contracts within the same
partition.(contract: specification that formalizes interactions b/n
client & server objects)

Layers:

o Represent elements of software architecture and their respective classes: (so

far we focused on the problem domain layer)
o Each layer limits the types of classes that can exist on it (e.g., only user
interface classes may exist on the human–computer interaction layer).

1. Foundation Layer:

 Contain classes necessary for an OO app to exist

 It represents: Fundamental data types, structures, and utility
classes (e.g., integers, lists, dates).

2. Problem Domain Layer:

 Refine with focus on cohesion, encapsulation, inheritance,

etc.

3. Data Management Layer:

 Ensure object persistence and system portability (e.g.,

storage format choices: files, databases).

4. HCI Layer:

 Keep UI implementation independent of domain classes for

portability.
 Typical classes: buttons, windows, text fields, etc.

5. Physical Architecture Layer:

 Classes for system execution on hardware and networks

(e.g., interaction with computer ports).

3
  addresses how the SW will execute on specific computers
and networks.

8.4. Packages and Package Diagrams

Definition and Purpose

 Package: A general construct used to group elements in UML models, serving the
same purpose as folders on a computer.
 Applications:
o Grouping use cases (to simplify use-case diagrams).
o Organizing classes and communication diagrams.

Package Diagram Overview

 Composition: Only shows packages, symbolized as tabbed folders.

 Relationships:
o Can include(participate in) aggregation and association relationships (e.g.,
grouping classes).
o Captures dependency relationships(symbolized as dashed line from
dependent package to ..) (modification in one package may require changes
in another).

Dependency Relationships

 Changes in one layer (e.g., Problem Domain Layer) can impact others like:
o Human–Computer Interaction (HCI) Layer.
o Physical Architecture Layer.
o Data Management Layer.
 At Class Level:

o Protocol changes in one class affect other dependent classes.

o Helps maintain object-oriented systems by capturing dependencies.

Modeling Collaborations, Partitions, and Layers

 Collaborations, partitions, and layers can all be modeled as packages.

 Example: In an Appointment System:

o Problem Domain Classes (e.g., Patient, Appointment) are isolated from:

 Actual Object persistence classes (e.g., Patient Table, Appointment

Table).
 Immediate Data Management classes (e.g., Patient-DAM,
Appointment-DAM).

o This isolation improves maintenance and reusability.

Guidelines for Creating Package Diagrams

Steps:

4
 1. Set Context:

o Example: Focus on the Problem Domain Layer in the Appointment System.

2. Cluster Classes:

o Group classes based on relationships (e.g., generalization, message sending).

o Use analysis models (class diagrams, communication diagrams, CRUDE
matrix).
o Keep classes in generalization hierarchies together.

3. Create Packages:

o Combine clustered classes into partitions and represent them as packages.

4. Identify Dependencies:

o Review relationships across package boundaries to identify potential

dependencies.

5. Layout and Draw Diagram:

o Focus on understandability, showing only dependencies among packages.

Verifying and Validating Package Diagrams

1. Check Package Logic:

o Ensure identified packages make sense in the problem domain (e.g.,

Appointment System packages like Participant, Patient, Appointment,
Account, Treatment). see page 25.

2. Validate Dependency Relationships:

o Confirm relationships are based on:

 Message-sending relationships (communication diagrams).

 CRUDE matrix entries.
 Class diagram associations.

8.6. Class and Method Design

Overview

5
Class and method design is where the actual implementation of the system
occurs.

 Importance: Poor class design leads to inefficient systems and objects incapable of
proper communication.
 Levels of Abstraction:
o Variable, method, class/object, package, library, and application/system
levels.
o Changes at one level (e.g., class) can cascade to other levels (e.g., package,
system, or library).

If domain classes are well-designed, it simplifies the design of other layers

(e.g., HCI, Data Management).

8.6.1. Design Criteria

Good design minimizes the system’s total cost over its lifetime by balancing
trade-offs. Key criteria:

1. Coupling
2. Cohesion

I. Coupling

Definition: The degree of interdependence between modules (classes, objects,

and methods).

 High Coupling: Increases the likelihood that changes in one module require changes
in others.
 Types:

Interaction Coupling:

Deals with message passing among methods and

objects.

Governed by the Law of Demeter (guideline to minimize

this type of coupling.):

 An object should send messages only to:

1. Itself (e.g., Object1 sends Message1 to itself).

2. Attributes: Objects contained within its own
attributes or super classes.
3. Parameters: Objects passed as parameters to a
method.
4. Created Objects: Objects instantiated within the
method.
5. Global Variables: Objects stored in global variables.

6
 Interaction coupling increases with:

 Passing attributes between methods.

 Methods relying on values returned by other methods.

Best Practice: Minimize interaction coupling except

where necessary (e.g., non-problem-domain classes
dependent on problem-domain classes).

Inheritance Coupling:

 The degree of dependency within an inheritance hierarchy.

 Generally desirable but can lead to challenges like inheritance
conflicts, redefinition issues, and dynamic binding.
 Best Practice:

 Use inheritance for generalization/specialization (a-kind-of

relationship).
 Avoid inheritance for other purposes.

II. Cohesion

Definition: The degree to which a module (class, method) focuses on a single

responsibility.

Method Cohesion:

o A method should perform only one task.

o Benefits: Improves understanding, implementation, and maintenance.
o (7)Types of Method Cohesion:
 Range from functional cohesion (good) to coincidental cohesion
(bad).
o Best Practice: Maximize method cohesion.

Class Cohesion:

A class should represent only one thing (e.g., an Employee,

Department, or Order).

Attributes and Methods:

 Must be necessary for defining instances of the class.

 Avoid including unrelated attributes or unused methods

Features of a Cohesive Class:

1. Contains multiple visible methods (i.e., not a single-method class).

2. Each visible method is functionally cohesive.
3. All methods reference only attributes/methods within the class or its
super class.

7
 4. Lacks control coupling between visible methods.(An individual class
can have a mixture of the following three types of class cohesion.)

Types of class cohesion: ideal, mixed-role, mixed-domain, mixed-instance

8.6 Class and Method Design

8.6.2 Object Design Activities

The design activities for classes & methods are really an extension of the
analysis and evolution activities presented previously (chapters 6 & 7)

Now: expand descriptions of partitions, layers, & classes.

Object design refines the analysis model by expanding and optimizing class
descriptions, incorporating reuse opportunities, and preparing for
implementation. The main activities used to design classes and methods
include:

Adding Specifications

1. Review Models: Assess functional, structural, and behavioral models to

ensure classes are necessary and sufficient.
2. Attributes and Methods: Add missing elements, remove unused ones, and
finalize their visibility.
3. Method Signatures: Define each method's name, parameters, and return
types, ensuring alignment with the method's contract.
4. Constraints: Specify preconditions, post-conditions, and invariants for object
behaviors.
5. Applicable across all layers: problem domain, data management, HCI, and
physical architecture.

Identifying Opportunities for Reuse

During analysis: we discussed reuse in terms of patterns

During design: we have more opportunities to look at reuse: design patterns,

frameworks, libraries, and components.

1. Design Patterns: Use predefined solutions like Iterator and Whole-Part

patterns to simplify complex designs.
2. Frameworks: Employ reusable, implemented classes that allow
customization through inheritance.
3. Class Libraries: Leverage pre-built classes for statistical processing, file
management, or UI development.
4. Components: Incorporate encapsulated, plug-and-play software pieces with
defined APIs.
5. Each reuse method has trade-offs related to vendor dependency and
maintenance.

8
 Restructuring the Design

1. Factoring: Simplify by extracting parts of methods or classes into new

entities.
2. Normalization: Identify missing classes and implement relationships as
attributes.
3. Inheritance Validation: Ensure generalization-specialization relationships
align with intended semantics.

Optimizing the Design

1. Access Paths: Streamline frequently traversed object paths with direct

connections.
2. Attribute Optimization: Relocate attributes to improve efficiency when their
usage is limited to specific classes.
3. Fan-Out Review: Optimize methods with high direct/indirect message calls.
4. Execution Order: Rearrange method statements to enhance efficiency, such
as refining search algorithms.
5. Caching: Use derived attributes or delayed re-computation to reduce
redundant calculations.

Mapping Problem-Domain Classes to Implementation Languages

1. Inheritance Adaptation: Handle constraints of single-inheritance or object-

based languages by converting inheritance relationships into associations or
flattening hierarchies.
2. Non-OO Language Adjustments: Factor out polymorphism, dynamic binding,
and encapsulation when necessary.

Key Takeaways

 Trade-offs: Striking a balance between design understandability and system

efficiency is critical.
 Reuse: Design patterns, frameworks, libraries, and components can improve
productivity and reliability but come with maintenance and dependency risks.
 Adaptability: Design must account for the specific features and limitations of the
implementation language.

8.6. Class and Method Design

8.6.3. Constraints and Contracts

Definition of Contracts

 A contract formalizes interactions between client and server objects.

 A client (consumer) object sends a message to a server (supplier) object, which
executes a method in response.
 Contracts are modeled on the legal notion of a contract where both parties have
obligations and rights.

9
Components of a Contract

 Constraints: Conditions that must be met.

 Guarantees: Behaviors ensured by the server object if constraints are satisfied.

Specification of Constraints

 Can be expressed in:

o Natural Language (e.g., English).

o Semiformal Language (e.g., Structured English).
o Formal Language (e.g., UML’s Object Constraint Language - OCL).

 Recommendation: Use UML’s OCL for precise, unambiguous specifications.

Object Constraint Language (OCL)

 A declarative language designed to specify constraints.

 All OCL expressions evaluate to either true or false.
 If the expression evaluates to true, the constraint is satisfied.

Sample OCL Constructs

1. Comparison Constraint:

o Example: A customer must have a balance owed of less than 100 Birr to
place a credit order.

 balanceOwed <= 100.00

2. Relationship Traversal:

o Example: The amount on a purchase order equals the sum of the values of
individual order lines.

 amount = OrderLine.sum(getPrice())

3. Logical Operators:

o Example: A discount applies if the customer is a senior citizen or a "prime"

customer.

 age > 65 or customerType = "prime"

4. Unique Constraints:

o Example: Printed name on an order concatenates the customer’s first and

last names.

 printedName = firstName.concat(lastName)

OCL Operations for Collections

10
  sum(): Guarantees a total value of elements.
 size: Returns the number of items in the collection.
 count(object): Counts occurrences of a specific object.
 includes(object): Tests whether an object exists in the collection.
 isEmpty(): Checks if the collection is empty.
 select(expression): Identifies a subset of the collection.

Types of Constraints

1. Preconditions:

o Constraints that must be true before a method executes.

o Example: Valid parameters must be passed; otherwise, raise an exception.

2. Post-conditions:

o Constraints that must be true after a method executes.

o Example: Attributes must not take invalid values; otherwise, raise an
exception.

3. Invariants:

o Constraints that must always hold true for all instances of a class.
o Example: Attribute multiplicity, valid attribute values, and association
relationships.

Documenting Constraints

 Attach invariants to CRC cards or class diagrams.

 Use extended CRC cards or separate text documents to avoid overcrowding class
diagrams.

Elements of a Contract

 Method Name and Class Name

 Contract ID: Unique identifier for the contract.
 Clients: Classes/methods sending messages to this method.
 Associated Use Cases: List of relevant use cases.
 Description of Responsibilities: Informal description of the method’s purpose.
 Arguments and Return Type: Data types of parameters and return values.
 Preconditions and Post-conditions: Constraints written in OCL.

Example: addOrder Method (Customer Class)

 Precondition: The new order cannot already exist in the customer’s list of orders.
 Post-condition: The updated list equals the previous list plus the new order.
 Design Decision:

o Use a sorted singly linked list to manage the customer’s orders.

o Orders are created before being associated with a customer.

8.6.4. Method Specification

Purpose

11
  Provide detailed instructions for programmers to implement methods.
 Specifications include:

o General Information
o Events
o Message Passing
o Algorithm Specification

General Information

 Includes method name, class name, ID, contract ID, programmer, due date, and
programming language.

Events

 Lists events that trigger the method.

o Example: Mouse clicks or keystrokes.

Message Passing

 Describes arguments passed to/from the method and their data types.

Algorithm Specification

 Written in Structured English (SE) or using UML Activity Diagrams.

 Structured English:

o Uses clear, concise sentences to describe steps.

o Example: If balance > 100, display error.

 Activity Diagrams:

o Useful for complex algorithms but may indicate design issues.

o Example: Decompose methods or add missing classes.

Additional Information

 Includes calculations, business rules, subroutine calls, and changes to other design
documents.

Example: insertOrder Method

 Implements the logic for adding an order to the list in sorted order.
 Relies on preconditions and post-conditions specified in the addOrder method.
 Designed to manage dependencies effectively between customer and order classes.

12