Swathy J

Assistant Professor
Department of CSE

Subject:OOMD
Subject Code:21CS731

McGraw-Hill www.cambridge.edu.in
©The McGraw-Hill Companies, Inc., 2000
MODULE 4

Use case Realization :The Design Discipline within up iterations: Object Oriented
Design-The Bridge between Requirements and Implementation; Design Classes and
Design within Class Diagrams; Interaction Diagrams-Realizing Use Case and defining
methods; Designing with Communication Diagrams; Updating the Design Class
Diagram; Package Diagrams-Structuring the Major Components;
Implementation Issues for Three-Layer Design.
Textbook-2: Chapter 8: page 292 to 346
Object Oriented Design-The Bridge between Requirements and
Implementation

• Object Oriented Design- It is the process by which a set of detailed object

oriented design model is built ,which the programmers will later use to write
code and test the new system.
• System design is essentially a bridge between a user’s requirements and
programming for the new system.
• In the adaptive approaches the development is to develop only a model that
have meaning and are necessary.
Object Oriented Design-The Bridge between Requirements and
Implementation

Object Oriented event driven program flow

Object Oriented Design-The Bridge between Requirements and
Implementation

• The program includes an input window object that displays a form in which
to enter student identification and other information.
• After the student ID is entered, the input window object sends a message to
the student class to tell it to create a new student object in the program and
also go to the database and get the student information and put it in the
student object.
• Once that is done, the new student object also sends that information back to
the Input window object to display it on the screen.
• The registration clerk then enters the personal information updates and
another sequence of message is sent to update the student object in the
program and the student information in the database.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

DESIGN CLASS SYMBOLS:

• UML does not explicitly differentiate between design class notation and
domain model notation. Domain modeling represents user environment
entities and their relationships, whereas design class diagrams focus
specifically on software classes with defined roles.
Standard Stereotypes:
• A stereotype is a UML notation used to categorize elements with special
characteristics, marked within guillemets (e.g., «control»). Stereotypes,
such as the «includes» relationship in use case diagrams, highlight specific
types of connections or roles in a design process.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

Standard Stereotypes in UML Design Models:(10 marks)

•
Standard Stereotypes found
in design models
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

• Two types of notation used for design classes.

• Class rectangle on the left show full notations

• the stereotypes are placed above the name in the name compartment.
• The circle symbols on the right are shorthand notation for these stereotype
called icons
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

• Four types of design classes in UML: entity classes, control classes, boundary
classes, and data access classes.
• Entity Class: Represents a domain class from the problem domain. It is
passive and handles business data, typically stored in a file or database,
persisting even after the system shuts down.
• Control Class: Manages the flow of operations between boundary and
entity classes. It coordinates activities and logic within the system.
• Boundary Class: Handles interactions between the system and external
actors, often representing the user interface.
• Data Access Class: Provides a means to retrieve or save data to storage
systems like databases or files, ensuring structured access.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

DESIGN CLASS NOTATION:

DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

DESIGN CLASS NOTATION:

• A design class symbol consists of three compartments:

• The top compartment includes the stereotype name and class name, along with
the parent class (if applicable).
• The middle compartment lists attributes.
• The bottom compartment lists methods.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

Attribute Format: Attributes are defined with the following details:

• Visibility: A "+" indicates public access, and a "-" indicates private access.
• Attribute Name
• Type Expression: Specifies the data type (e.g., string, integer, date etc).
• Initial Value: starting value.
• Properties: Defined within curly braces, e.g., {key}.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

SOME FUNDAMENTAL DESIGN PRINCIPLES:(10 marks)

1. Encapsulation and Information Hiding:
• Software Design Principles: Encapsulation and information hiding are
key to creating robust systems where changes to one part do not impact
others.
• Each object in an object-oriented system encapsulates its data and
behaviors, ensuring that its internal workings remain private and
protected from outside access.
• Encapsulation provides a modular design by treating each object as a
self-contained unit. This approach simplifies understanding and
maintaining systems.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

SOME FUNDAMENTAL DESIGN PRINCIPLES:

Encapsulation and Information Hiding:
• Encapsulation Benefits: Encapsulation provides a modular design by
treating each object as a self-contained unit. This approach simplifies
understanding and maintaining systems.
• Component Standardization: Common components like buttons and menus
can be reused across desktop and web applications to maintain uniformity.
• Information Hiding: Objects hide their private attributes from the outside
world, allowing controlled access through public methods.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

SOME FUNDAMENTAL DESIGN PRINCIPLES:

2. Navigation visibility:
• The ability of one object to view and interact with another object.
• For example, a Customer object can view an Order object it has placed.
• Unidirectional Navigation: The navigation visibility can be one-way,
where one object (e.g., Customer) has visibility of another (e.g., Order),
but not vice versa.
• Variable for Navigation: A variable, like myOrder, in the Customer class
is used to refer to an Order object, showcasing the navigation relationship
between the two objects.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

SOME FUNDAMENTAL DESIGN PRINCIPLES:

2. Navigation visibility:
•
Navigation visibility between
customer and order- Coupling
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

SOME FUNDAMENTAL DESIGN PRINCIPLES:

2. Navigation visibility:
• Design Diagram Representation: Design diagrams use arrows to represent
navigation visibility. For instance, an arrow from Customer to Order
indicates that Customer can navigate to Order but not the other way around.
• Coupling Concept: Coupling, derived from navigation visibility, measures
how closely related two classes are. Lower coupling is desirable for
flexibility and easier maintenance.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

SOME FUNDAMENTAL DESIGN PRINCIPLES:

3. Cohesion and separation of responsibilities:
• Cohesion: Cohesion measures the consistency and unity of purpose within a
single class. High cohesion ensures that a class focuses on one specific purpose,
making it easier to manage and maintain.
Effects of Low Cohesion:
• Maintenance Challenges: Classes with low cohesion are harder to maintain
because they perform multiple unrelated functions, increasing complexity.
• Sensitivity to Changes: Such classes are prone to ripple effects, where changes in
one part of the class can unintentionally affect others.
• Reduced Reusability: Low cohesion makes it difficult to reuse components
effectively.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

SOME FUNDAMENTAL DESIGN PRINCIPLES:

• High Cohesion Benefits: Classes with high cohesion are more reusable,
simpler to understand, and maintain. For example, a button class handling
only clicks is more reusable than one managing both clicks and user logins.
• Examples of Cohesion Levels:
• Very Low Cohesion: A class that handles unrelated responsibilities, such as
managing both database access and external internet services.
• Medium Cohesion: A class with related responsibilities, such as managing
customer information and accounts.
• High Cohesion: Separate classes for specific tasks, such as one handling customer
names and addresses and another managing customer orders.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

SOME FUNDAMENTAL DESIGN PRINCIPLES:

Cohesion and separation of responsibilities:
• Separation of Responsibilities: To achieve cohesion, responsibilities should
be divided into separate classes or methods that focus on distinct tasks,
reducing overlap and enhancing clarity.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

OBJECT RESPONSIBILITIES: (5 Marks)

• object responsibilities are two types:
• 1. Knowing
2. Doing
1. Knowing:
• knowing about its own data and knowing about other classes with which
it must collaborate to carry out use cases.
• For example, during the initiation of an object, data for some attributes
may be passed in as part of the constructor being invoked. However, other
data passed in may be required. An object should know about that is, have
navigation ability to other objects that can provide the required
information.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

OBJECT RESPONSIBILITIES:
2. Doing:
• Doing includes all the activities an object does to assist in the execution
of a use case.
• Another doing responsibility will be to instantiate. or create. new objects
that may be required for completion of a use case.
• Some classes are responsible coordinating the collaboration.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

USE CASE CONTROLLER:

• Use case controllers are classes designed to handle input messages in a
system, simplifying the processing and decision-making of these inputs. They
act as intermediaries between the external world (e.g., user interface) and the
internal system (e.g., domain objects).
• By centralizing the handling of input messages, use case controllers reduce
coupling between the user interface and problem domain objects, leading to
better modularity and maintainability.
• Use case controllers can be created for individual use cases or groups of
related use cases. A balance is needed to avoid overloading a single controller
or creating excessive controllers, which may affect cohesion or coupling.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

FIRST-CUT SEQUENCE DIAGRAM (5 marks)

DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

• AvailabilityHandler: To catch incoming messages and distribute them to the

correct internal domain objects and to return the required information to the
external environment.
• AvailabilityHandler class also is highly cohesive with two primary
responsibilities.
• Catelog: is to be in charge of collecting all product and inventory information
in the product hierarchy.
• Catelog class is highly cohesive.
• ProductItem: and Inventoryitem would require navigation visibility and
hence increase coupling.
•
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

FIRST-CUT SEQUENCE DIAGRAM (5 marks)

First cut Diagram for Look

up item availability
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

Designing with communication diagram:

• Communication Diagram and sequence diagrams are both interaction
diagrams, and they capture the same information.
• Many designers prefer to use sequence diagrams to develop the design
because use case descriptions and dialog design follow a sequence of
steps.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

Symbols of the communicatio

diagram.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS

Package Diagrams:Structuring the major components.

• Package diagram in UML is simply a high- level diagram that allows
designers to associate classes of related groups.
• The package notation is tabbed rectangle.
• The package name is usually shown on the tab,although for very high
level view,if no details are shown inside the package, the name can also
placed inside the package rectangle.
DESIGN CLASSES AND DESIGN CLASS DIAGRAMS