 Object-oriented design is the process of

planning a system of interacting objects for

the purpose of solving a software problems.
 Some Characteristics are as follows:
› Objects are abstractions of the real-world or
system entities and manage themselves.
› System functionality is expressed in terms of
object services.
› Communication between objects is through
message passing.
› The objects may be distributed and may
execute sequentially or in parallel.
 To design classes and their attributes,
methods, associations, structure.
› The static UML class diagram is redefined and
completed by adding details.
› Attributes are refined.
› Protocols and methods are designed by utilizing
a UML activity diagram to represent the
methods algorithm.
› If required, redefine associations between
classes, and refine class hierarchy and design
with inheritance.
› Iterate and refine again.
 Design the access layer.
› Create mirror classes i.e., for every business class
identified and created, create one access class.
 Simplify classes and their relationships.
› The main objective here is to eliminate
redundant classes and structures.
› Redundant Classes: Programmers should
remember to not put two classes that perform
similar translate requests and translate results
activities. They should simply select one and
eliminate the other.
› Method Classes: Revisit the classes that consist of
only one or two methods, to see if they can be
eliminated or combined with the existing classes.
 Iterate and refine again.
 Design the view layer classes.
› Design the macro level user interface, while
identifying the view layer objects.
› Design the micro level user interface.
› Test usability and user satisfaction.
› Iterate and refine.
 At the end of the process, iterate the whole
design. Re-apply the design axioms, and if
required repeat the preceding steps again.
 cohesion refers to the degree to which the
elements inside a module belong together.
 a class with high cohesion would be one
where all methods and class level are used
together to accomplish a specific task.
 modules with high cohesion tend to be
preferable in software design
 There are two types of Cohesions:
› Low Cohesion
› High Cohesion
 coupling indicates to how closely two modules
interact or how interdependent they are.
 how much one module knows about the inner
workings or inner elements of another one, i.e.
how much knowledge it has of the other
module.
 the system has low coupling, it is a sign of well
structured computed sys & a great design.
 There are two types of Coupling:
› Tight Coupling
› Loose Coupling
 Tight Coupling:
› Tight coupling occurs when one entity
depends implicitly on another
› Example: Object instances are tightly
coupled to their classes because they share
both public and protected information. A
change in the class definition affects every
instance of the class.
› Shared variables or control information
exchange lead to tight coupling
 Loose Coupling
› Loose coupling means component changes are
unlikely to affect other components
› Loose coupling can be achieved by state
decentralization (as in objects) and component
communication via parameters or message passing
› Loose coupling occurs when one entity references
another indirectly through a public interface
› Example: Client/server relationship using HTTP
› Loose coupling usually increases reusability and
decreases maintenance costs
 Association
› Very weak coupling (which is good), but
coveys little information (so not very useful)
 Using
› Client/server model
› Provides very loose coupling
› Good-to-excellent reusability
 Generalization
› Strong, but often useful form of coupling
 Data Coupling
› Data is passed from one module to another using
arguments
 Stamp Coupling
› More data than necessary is passed via arguments e.g.
pass the whole record instead of just the field being
changed
 Control Coupling
› A flag is passed from one module to another affecting the
functionality of the second module
› modules are not independent and so reuse is limited
› violates principle of ‘information hiding’
› calling module must ‘know’ how the called module works
 + Public
 ‐ Private
 # Protected
 ~ Package
 A Stereotype is a mechanism use to
categorize classes
 Primary class stereotypes in UML
 Provide the interface to a user or
another system.
 Handles communication between
system surroundings and the inside of the
system
› User interface classes
› System interface classes
› Device interface classes
 Fundamental building block which
perform internal tasks
 Represent real world entity
 They correspond to database table

 Objects that mediate between

boundaries and entities.
 Typically one control class per use case
 Association
 Aggregation/Composition
 Generalization
 Dependency
 Link between classes
 Type of relationship
 The number of objects from one class
that relate with a single object in an
associated class
1 Exactly one
0..* Zero or more
1..* One or more
0..1 Zero or one
5..8 Specific Range (5,6,7 or 8)
 Multiplicity
 Aggregation And Composition
 Referential integrity refers to the accuracy and
consistency of data within a relationship.
 In relationships, data is linked between two or
more tables. This is achieved by having the foreign
key reference a primary key value
 whenever a foreign key value is used it must
reference a valid, existing primary key in the parent
table.
 So referential integrity will prevent users from:
› Adding records to a related table if there is no associated
record in the primary table.
› Changing values in a primary table that result in orphaned
records in a related table.
› Deleting records from a primary table if there are
matching related records.
if we delete record number 15 in a primary table, we need to be sure
that there’s no foreign key in any related table with the value of 15. We
should only be able to delete a primary key if there are no associated
records. Otherwise, we would end up with an orphaned record.