Lecture 8

System Design
Introduction
• Analysis determines the business needs
• Design activities focus on how to build the system
• Major activity is to evolve the models into a design
• Goal is to create a blueprint for the design that makes sense to
implement
• Determine how and where data will be stored
• Determine how the user will interface with the system (user
interface, inputs and outputs)
• Decide on the physical architecture
• Analysis and design phases are highly interrelated and
may require much “going back and forth”
• Example: prototyping may uncover additional information
The Design Process
• Verify and validate the analysis models
• Not looked at in this course
• Evolve the analysis models into design models
• Factoring
• Partitions and Collaborations
• Layers
• Create packages and utilize package diagrams
Evolving the Analysis Models into Design
Models
• Analysis models focused on functional requirements
• Design models must include non-functional requirements
as well
• System performance
• System environment issues
• Distributed vs. centralized processing
• User interface
• Database

• We must review the analysis models and make changes

to the system to enhance the efficiency and effectiveness
of the system.
• We use factoring, partitions & collaborations, and layers
Factoring
• Is the process of separating out a module into a stand-
alone module.
• The new module can be a new class or a new method.
• E.g. when reviewing a set of classes, it may be discovered that
they have a similar set of attributes and methods.
• Thus, it might make sense to factor out the similarities into a separate
class.
• New classes can be formed through a:
• Generalization (a-kind-of) relationship, or a
• Aggregation (has-parts) relationship
• Abstraction—create a higher level class (e.g., create an Employee
class from a set of job positions)
• Refinement—create a detailed class (e.g., create a secretary or
bookkeeper from the Employee class)
Partitions and Collaborations
• Partition: is the process of creating a sub-systems that
consist of closely collaborating classes
• E.g. an accounting information system could be functionally
decomposed into an accounts-payable system, an accounts-
receivable system, a payroll system, etc…
• Partitions are based on the patterns of activity (e.g., collaborations
found in a communication diagram)
• Greater coupling among classes may identify partitions (e.g., more
messages passes between objects suggests that they belong in the
same partition)
• Identifying partitions and collaborations determines which
classes should be grouped together
Layers
• We have focused only on one layer in the software architecture: the
problem domain layer.
• There should be a layer for each of the different elements of the
system environment.
• E.g., data management, user interface, physical architecture.
• Use layers to represent and separate elements of the software
architecture
• Easier to understand a complex system

• Layers can be portrayed using packages and package diagrams.

Layers
• Proposed layers:
• Foundation – contains classes that are necessary for any object-
oriented application to exist.
• (e.g., container classes – integers, real numbers, characters, strings)

• Problem domain – what we have focused on up until now

• Data management – the types of classes that appear in this layer deal
with how objects can be stored and retrieved.
• User interface – main purpose of this layer is to keep the user-interface
implementation separate from the problem domain classes.
• (e.g., data input forms)

• Physical architecture – this layer includes classes that deal with

communication between the software and the computer’s operating
system and the network.
Packages and Package Diagrams
• A package serves the same purpose as a folder on your
computer.
• Packages group together similar components (e.g., use-
cases, class diagrams)
• Package diagrams show only the packages and their
relationships
• Aggregation & association relationships are possible in a package
diagram.
• Packages may be dependent upon one another
• If one package is modified, others that depend on it may also require
modification
Package
• A general construct that groups units together
• Used to reduce complexity of models
• A package diagram shows packages only
Sample Package Diagram
Guidelines for Building Package
Diagrams
• Collaborations, partitions, and
layers are modeled as packages
in UML.

• Collaborations are normally

factored into a set of partitions,
which are placed on a layer.

• All these groupings are

represented using packages in
UML.

• E.g. Partial package diagram of

the Appointment system.
Package Diagram of the PD Layer of the Appointment Problem
Package Diagram of the PD Layer of the Appointment Problem
Building Package Diagrams
• Set the context
• Cluster classes together based on shared relationships
• Create packages from the clusters
• Identify dependency relationships among packages
• Lay out and draw the diagram including only the
packages and their dependencies
• Verify and validate the package diagram
Characteristics of O-O System Design
• Classes
• Instantiated classes are objects
• Classes are defined with attributes, states & methods
• Classes communicate through messages (method call)

• Encapsulation & information hiding

• Encapsulation is the mechanism that combines data and methods
into a single object
• This will allow information to be hidden and reveal only the information
required to use an object be available outside the object.
• i.e. visibility of the methods and attributes (e.g. public, private, protected)
Polymorphism & Dynamic Binding
• Polymorphism
• The ability to take on several different forms
• Same message triggers different methods in different objects
• Dynamic binding
• The ability of O-O systems to defer the data typing of objects at
runt time.
• Methods—the specific method used is selected at run time
• Attributes—data type is chosen at run time

• E.g. computePay() method

• Both HourlyEmployee and SalariedEmployee compute a pay for
the individual instance.
Polymorphism Example
Polymorphism & Dynamic Binding
• Need to ensure semantic
consistency.
• E.g. in the case of an instance of
employee, the computePay()
method compute the amount that
the employee is owed by the firm,
whereas the computePay()
method associated with an
instance of a customer computes
the amount owed the firm by the
customer.
• Therefore, the key to controlling
the misuse of polymorphism is to
ensure the use of semantic
consistency. (i.e. having the same
meaning throughout the classes)
Inheritance
• Permits reuse of existing classes with extensions for
new attributes or methods.
• Types
• Single inheritance – allows a subclass to have only one parent
class.
• Multiple inheritance – a subclass may inherit from more than
one superclass.
Inheritance Conflicts
• An attribute or method in a sub-class with the same name
as an attribute or method in the super class
• E.g. computePay() method  which one are we referring to,
the one in the Doctor class or the one in the Employee class?
• May also occur in cases of multiple inheritance
• E.g. runningTime attribute, which one do we inherit?

• The only way to prevent these situations is for the

developer to catch it during the design of subclasses.
Principles Leading to Good Design
•Overall goals of good design:
• Increasing profit / reducing cost / increasing revenue
• Ensuring that we actually conform with the requirements
• Accelerating development
• Increasing qualities such as
• Usability
• Efficiency
• Reliability
• Maintainability
• Reusability
Design Principle 1: Divide and conquer
•Trying
to deal with something big all at once is normally
much harder than dealing with a series of smaller things
• Separate people can work on each part.
• An individual software engineer can specialize.
• Each individual component is smaller, and therefore easier to
understand.
• Parts can be replaced or changed without having to replace or
extensively change other parts.
Ways of dividing a software system
• A distributed system is divided up into clients and servers

• A system is divided up into subsystems

• A subsystem can be divided up into one or more packages

• A package is divided up into classes

• A class is divided up into methods

Design Principle 2 & 3
• A set of criteria exists that can be used to determine
whether the design is a good one or a bad one.
1. Coupling—refers to the degree of the closeness of the
relationship between classes
2. Cohesion—refers to the degree to which attributes and
methods of a class support a single object
Design Principle 2: Reduce coupling
where possible
•Couplingoccurs when there are interdependencies
between one module and another
• When interdependencies exist, changes in one place will require
changes somewhere else.
• A network of interdependencies makes it hard to see at a glance
how some component works.
• Type of coupling:
• Common, Stamp, Interaction, and Inheritance
Coupling
• Refers to how interdependent or interrelated the modules (classes,
objects and methods) are in a system.
• Close coupling: The higher the interdependency, the more likely changes
in part of a design can cause changes to be required in other parts of the
design.
• Types
• Interaction coupling: deals with the coupling among methods and objects
through message passing.
• In a good design, methods do not call one another.

• Inheritance coupling: deals with how tightly coupled the classes are in an
inheritance hierarchy.
• In a good design, inheritance should be used only to support generalization (a-
kind-of) relation.

• We should try to minimize coupling so that if there are changes in the

design, then less changes will be required in other parts of the design.
Common coupling
•Occurs whenever you use a global variable
• All the components using the global variable become coupled to
each other
• A weaker form of common coupling is when a variable can be
accessed by a subset of the system’s classes
• e.g. a Java package
• Can be acceptable for creating global variables that represent
system-wide default values
• The Singleton pattern provides encapsulated global access to an
object
Stamp coupling:
•Occurs whenever one of your application classes is
declared as the type of a method argument
• Since one class now uses the other, changing the system becomes
harder
• Reusing one class requires reusing the other

• Two ways to reduce stamp coupling,

• passing simple variables
Example of stamp coupling
public class Emailer
{
public void sendEmail(Employee e, String text)
{...}
...
}

Using simple data types to avoid it:

public class Emailer
{
public void sendEmail(String name, String email, String text)
{...}
...
}
 Design Principle 3: Cohesion
• Refers to how single-minded a module (class, object, method) is
within a system.
• A class or object should represent only one thing, and a method should
solve only a single task.
• Types
• Method cohesion
• Class cohesion
• Generalization/specialization cohesion

31
 Cohesion
• Method cohesion
• Does a method
perform more than
one operation?
• Methods should do
one and only one
thing.
• Performing more than
one operation is more
difficult to understand
and implement

32
 Cohesion
• Class cohesion
• Do the attributes and methods represent a single object?
• Classes should not mix class roles, domains or objects
• A class should represent only one thing, such as an employee.
• An employee class should include (name, address, benefits), but it should not
have attributes such as (door, engine, hood).
 Cohesion
• Generalization/specialization cohesion
• Addresses the sensibility of the inheritance hierarchy.
• Classes in a hierarchy should show “a-kind-of” relationship, not
associations or aggregations
• E.g. instances of the ClassRooms and Staff classes are not a-kind-of
Department (i.e. they should be associated with a-part-of relationship)

34
Design Principle 4: Increase abstraction
•Ensure that your designs allow you to hide or defer
consideration of details, thus reducing complexity
• A good abstraction is said to provide information hiding
• Abstractions allow you to understand the essence of a subsystem
without having to know unnecessary details
• Examples of abstractions:
• Classes
• UML associations
• Interfaces
Design Principle 5: Increase reusability
where possible
•Design the various aspects of your system so that they
can be used again in other contexts
• Generalize your design as much as possible
• Simplify your design as much as possible
Design Principle 6: Reuse where possible
•Design with reuse is complementary to design for
reusability
• Actively reusing designs or code allows you to take advantage of
the investment you or others have made in reusable components
Design Principle 7: Design for flexibility
•Actively
anticipate changes that a design may have to
undergo in the future, and prepare for them
• Reduce coupling and increase cohesion
• Create abstractions
• Do not hard-code anything
• Leave all options open
• Do not restrict the options of people who have to modify the system
later
• Use reusable code and make code reusable
Design Principle 8: Anticipate
obsolescence
•Planfor changes in the technology or environment so the
software will continue to run or can be easily changed
• Avoid using software libraries that are specific to particular
environments
• Avoid using undocumented features or little-used features of
software libraries
• Avoid using software or special hardware from companies that are
less likely to provide long-term support
• Use standard languages and technologies that are supported by
multiple vendors
Design Principle 9: Design for Portability
•Have the software run on as many platforms as possible
• Avoid the use of facilities that are specific to one particular
environment
• E.g. a library only available in Microsoft Windows
Design Principle 10: Design defensively
•Never trust how others will try to use a component you are
designing
• Handle all cases where other code might attempt to use your
component inappropriately
• Check that all of the inputs to your component are valid: the
preconditions (Constraints)
• Unfortunately, over-defensive design can result in unnecessarily
repetitive checking