Modular Software Design

Introduction
 What is design?

•  Provides structure to any artifact

–  not only code
•  Decomposes system into parts, assigns responsibilities,
ensures that parts fit together to achieve a global goal
•  Design refers to both an activity and the result of the
activity

Introduction to Design 2
 Two meanings of “design” activity in our
context
•  Activity that acts as a bridge between requirements and
the implementation of the software
•  Activity that gives a structure to the artifact
–  e.g., a requirements specification document must be
designed
•  must be given a structure that makes it easy to understand and
evolve

Introduction to Design 3
 The sw design activity

•  Defined as system decomposition into modules

•  Produces a Software Design Document
–  describes system decomposition into modules
•  Often a software architecture is produced prior to a
software design

Introduction to Design 4
 Software architecture

•  Shows draft structure and organization of the system to

be defined
•  Its description includes description of
–  main components of a system
–  relationships among those components
–  rationale for decomposition into its components
–  constraints that must be respected by any design of the
components
•  Guides the development of the design

Introduction to Design 5
 Two important goals

•  Design for change (Parnas)

–  designers tend to concentrate on current needs
–  special effort needed to anticipate likely changes
•  Product families (Parnas)
–  think of the current system under design as a member of a
program family

Introduction to Design 6
 Product families

•  Different versions of the same system

–  e.g. a family of mobile phones
•  members of the family may differ in network standards, end-user
interaction languages, …
–  e.g. a facility reservation system
•  for hotels: reserve rooms, restaurant, conference space, …,
equipment (video beamers, overhead projectors, …)
•  for a university
–  many functionalities are similar, some are different (e.g., facilities may
be free of charge or not)

Introduction to Design 7
 Modularity to the rescue

•  A modular design facilitates

–  change
•  change can be confined to isolated components
–  defining product families
•  changing components gives rise to a new family

Introduction to Design 8
 Module
•  A well-defined component of a software system
–  for example, a module managing a set of elements
–  or of a system in general, not only software
•  e.g., a button, a light, a lamp, etc.
•  A part of a system that provides a set of services to
other modules
–  Services are computational elements that other modules may
use
•  e.g., a module managing a set typically offers “service”
“addElement”
–  again, this notion can be generalized to “functionalities” that
are offered by non-sw components
•  e.g., a lamp offers the “service” “turn light on”
Introduction to Design 9
 Interactions between modules

•  A module interacts with (or “uses”) another one by

“calling” its services
–  the mechanism to realize the “call” depends on the nature of
the module
•  for a software module, the “call” is typically the invocation of an
operation (e.g., “addElement”)
•  for a physical module it could be an event (e.g., “push button”)
•  We name the caller the client, and the callee the
server
•  Modules offer their services through interfaces

Introduction to Design 10
 Interface vs. implementation (1)

•  To understand the interaction between modules, we

need to know what a used module exports through its
interface
•  The client imports the resources that are exported by its
servers
•  Modules implement the exported resources
•  Implementation is hidden to clients
–  e.g., a module realizing a set of elements offers service
“addElement”, but the client ignores whether the set is
implemented as an array or as a list (or as a tree)

Introduction to Design 11
 Interface vs. implementation (2)

•  Clear distinction between interface and implementation

is a key design principle
•  Supports separation of concerns
–  clients care about resources exported from servers
–  servers care about implementation
•  Interface acts as a contract between a module and its
clients

Introduction to Design 12
Interface vs. implementation (3)

interface is like the tip of the iceberg

Introduction to Design 13
 Information hiding

•  Basis for design (i.e. module decomposition)

•  Implementation secrets are hidden to clients
•  They can be changed freely if the change does not
affect the interface
–  e.g., we can change the implementation of the set of
elements from a list to a tree
•  Golden design principle
INFORMATION HIDING
–  Try to encapsulate changeable design decisions as
implementation secrets within module implementations

Introduction to Design 14
 Interface design

•  Interface should not reveal what we expect may change

later
•  It should not reveal unnecessary details
•  Interface acts as a firewall preventing access to hidden
parts

•  How do we define modular systems, their modules,

interfaces, relationships?

Introduction to Design 15
Object Oriented Design & UML
 Object-oriented Design

•  A design can be seen as a set of objects that interact by

invoking services on each other
–  this holds for both purely software systems, and for software-
based ones, in which software is but a part of the whole
•  UML is the de facto standard for OOD

OO Design & UML 17

 Objects models
•  In object models systems are described in terms of classes of
objects
•  A class is an abstraction for a set of objects that have the same
attributes and offer the same services
–  e.g., the class “Lamp” represents objects that offer services “turn on”
and “turn off”, and that have attribute “on/off”
•  Classes are a natural way of describing entities (software or
otherwise) of the system
•  Identifying classes is a creative process that requires knowledge
of the application domain
–  once the classes for a certain domain have been identified, they can be
re-used to define different systems
•  e.g., the notion of “button” can be used with lamps, lifts, etc.

OO Design & UML 18

 Key concepts

•  Objects
•  Classes
•  Relationships among classes

OO Design & UML 19

 Objects

•  An object is an entity that can be:

–  physical
•  button, lamp, car, etc.
–  conceptual (abstract)
•  property, constraint, etc.
–  software
•  array, list, etc.

OO Design & UML 20

 Features of objects

state (attributes) Object identity

behavior (operations, a.k.a. “methods”)

•  Objects can be composed of other objects

–  e.g., a lamp is composed of a button, a light bulb, etc.

OO Design & UML 21

 State

•  The state:
–  is the current configuration in which the object is
–  is defined by the values of its properties (attributes)
•  e.g., “the lamp is on” is represented as the attribute “on/off” of the
lamp being “on”

OO Design & UML 22

 Behavior

•  The behavior of the object determines how it acts and

reacts
–  how it changes its state, and how it interacts with other
objects
•  It is defined by the operations (methods) that the object
can perform

Turn on!

OO Design & UML 23

 Classes

•  A class is a set of entities with common features

–  e.g., the set of lamps with a button to turn them on
•  A class is a concept used to describe objects with
similar properties

•  A class is an abstraction
–  it emphasizes some features
•  e.g., the presence of the button
–  it disregards other properties
•  e.g., the color of the light

OO Design & UML 24

 An example of class

State
Behavior
Name
AddStudent
Teacher
Room UniversityCourse DeleteStudent
ListStudents
Semester
SetRoom
Students

OO Design & UML 25

 UML
•  UML: Unified Modeling Language
–  object-oriented notation that can be used during the analysis and design
phases of a system
–  de facto standard for object-oriented modeling
–  evolution and unification of three notations: Booch (named from its
author), OMT (Rumbaugh) and OOSE (Jacobson)
–  independent from programming languages
–  used in many different domains and for projects of very different sizes
•  A set of notations associated with a set of methods
–  Use case diagrams, Sequence diagrams, State diagrams, Activity
diagrams …
–  Class diagrams

OO Design & UML 26

 Class Diagrams

•  Define the static view of the system

–  classes
–  relationships among classes
•  association (use)
•  generalization (inheritance)
•  aggregation (containment)
•  It defines the basic elements of the system
–  as such, it’s possibly the most important diagram

OO Design & UML 27

 Classes

•  In UML a class is made of three parts

–  name
–  attributes (the state)
–  methods (the behavior)

OO Design & UML 28

Elevator

OO Design & UML 29

Class Diagram…

OO Design & UML 30

 Attributes

•  An attribute is a feature of the class

•  Attributes do not have an identity
–  they exist as features of the class
•  Every attribute must be precisely defined
–  it has a type
•  Good attributes for class Student
–  first name, last name, …
•  Not-so-good attributes
–  Classes taken

OO Design & UML 31

 Attributes (cont.)

•  Attributes defined depend on the application domain:

–  attributes of a Person for the banking domain
•  first name, last name, Social Security Number, n. of bank account…
–  attributes of a Person for the healthcare domain
•  first name, last name, allergies, weight, height…

OO Design & UML 32

 Operations (Methods)

•  An operation is a transformation that can be applied to

an instance of a class
–  often its effect is to change the state (i.e., the attributes) of the
instance
•  Operations depend on the application domain
–  Banking domain
•  getLoan, getCredit, openBankAccount
–  Healthcare
•  hasExam, takeMedicine, enterHospital

OO Design & UML 33

OO Design & UML 34
 Classes
(Visibility)

•  Visible attributes and operations are the interface of the

class
–  i.e., what can be used and referenced by other classes

OO Design & UML 35

 Relationships (associations)

•  Objects and classes have relationships ("associations"

in UML parlance) with other objects and classes
•  Example:

OO Design & UML 36

 Associations

•  An association corresponds to a relationship between

classes
–  e.g., a person that works in a company
•  An association has a name
–  usually the name is a verb:

•  It can also have a direction

–  in this case Professor "refers to" Course, but not vice-versa
OO Design & UML 37
 Multiplicity

•  Multiplicity specifies:
–  whether the association is mandatory or not
–  the maximum and minimum number of objects that can be
related to another object

OO Design & UML 38

 Multiplicity (cont.)

1
Exactly 1

* zero or more
0..1
zero or 1

m..n
between m and n

OO Design & UML 39

 Associations and objects

•  An association defines a “communication channel”

between the objects of the classes involved in the
relationship
–  that is, the objects of a class can refer to/use the features of
the related objects of the other class
•  Multiplicity defines the number of objects that take part
in the relationship

OO Design & UML 40

 Role

•  A role is specific for each class in the association

–  it indicates the part played by the objects of that class in the
association

OO Design & UML 41

 Role (cont.)

•  The role is important when a class is involved multiple

times in the same association

OO Design & UML 42

 Association attributes

•  Sometimes the attribute does not belong to a single

class, but to the relationship between classes

Introduction to Design 43
 Aggregations

•  Aggregations are a special form of association

•  They correspond to a “part-of” relationship
–  i.e., when an object (the part) is part of another (the whole)

OO Design & UML 44

 Aggregating objects
•  An aggregation shows how the objects of a certain class are
composed by other objects

Notice the similarities...

OO Design & UML 45
 Compositions
•  A composition relationship is a strong form of
aggregation
–  The composing parts cannot exist without the container
•  creation and destructions occur when the container is created and
destroyed
•  components are not part of other objects

OO Design & UML 46

 Classifying entities
•  It is useful to minimize the number
of classes to improve productivity
Airspeed Roll actuator and reuse
•  Classify objects, identifying
Height
System
controller
Pitch actuator common features:
–  functionalities and behaviors
Attitude Yaw actuator –  features (attributes).
•  Example: first classification
(a) System Objects
identifies 3 groups: sensor,
Sensors Controllers Actuators controller and actuator
Airspeed System Roll •  Actuators are all the same, but
Height Pitch sensors differ in some details
Attitude Yaw

(b) Grouping of system objects •  What shall we do?

OO Design & UML 47

 Superclasses and subclasses
Superclass

Subclasses

Sub-subclasses

•  just one class for actuators

•  sensors, instead, are further classified

OO Design & UML 48

 Inheritance

•  Classes are typically organized in a hierarchy

•  Classes at the top of the hierarchy have features that
are common to all classes
•  Classes at lower level in the hierarchy inherit attributes
and services from the higher-level classes, but that can
be further specialized if necessary
•  Inheritance is called “generalization” in UML parlance

OO Design & UML 49

Library class hierarchy

OO Design & UML 50

 User class hierarchy

OO Design & UML 51

 Advantages of inheritance
•  Useful abstraction mechanism to classify entities and find
relationships between similar classes
–  E.g.: various types of sensors are different from one another, but they
have common features, which can be factored out in a common class,
from which all other inherit
•  It is a mechanism for reuse, both in the analysis of the domain
and in the software design and implementation phases
•  The inheritance graph is a source of information on the
application domain and on the systems realized, and it is useful
for the documentation
•  Cons: low readability
–  classes are not self-contained: to understand a class one has to look at its
superclasses…

OO Design & UML 52

 Multiple inheritance
•  Possibility to inherit from more than one class
•  It can lead to conflicts between attributes or services with the
same name inherited from different classes

OO Design & UML 53

 A complete example

•  A simple system:
–  a controller uses a sensor with an analog-to-digital converter
to acquire information
–  the controller then uses an actuator to affect its environment
–  the system may use a temperature sensor to activate either a
heater or a fan for closed-loop control
–  additionally, it may use a pressure sensor to provide
information about a gas line that it uses to control a valve with
a stepper motor

OO Design & UML 54

Class Diagram for the example

OO Design & UML 55

 Communication bewteen objects

•  Objects communicate by exchanging messages

•  Message:
–  the name of the service invoked by the calling object
–  the data required to execute the service

OO Design & UML 56

From Class Diagrams...

Introduction to Design 57
...to Objects

Introduction to Design 58
 Sequence Diagrams

•  We can describe the interaction among objects through

Sequence Diagrams
•  Describe messages (i.e., invocations) sent and received
by interaction objects
•  They describe the behavior of the system over time
–  behavioral diagrams

Introduction to Design 59
Example of Sequence Diagram

Introduction to Design 60
 Sequence Diagram explained
object

lifeline
reply message
message
(synchronous)
recursive message

message
(asynchronous)
Introduction to Design 61
 Advantages of OO approach in the design of sw

•  Easier maintenance
–  objects can be understood (and modified) as stand-alone
entitires
•  Reusability of objects
•  In many systems, there is a clear correspondence
between the “real-world” entities (persons, roles,
devices…) and the (sw) objects of the system

OO Design & UML 62

 Objects in the sw world (OOP)
•  Object: an entity in memory, with a state and a set of operations
that modify the state
–  the state is represented by the values in memory of the attributes of the
object
–  operations provide services to other objects (clients), which use them
when necessary
•  Objects are created according to the definition of the
corresponding class
–  a class is a “template” for the creation of objects of the same type
–  it includes the declarations of all attributes and services that are part of
the objects of that class

OO Design & UML 63

Employee object class

OO Design & UML 64

 Communication bewteen objects in practice

•  In practice, messages are typically implemented as

procedure calls
–  name = procedure
–  data = parameter list

OO Design & UML 65

 Message examples

•  Call a method associated with a buffer object (named

circularBuffer) that returns the next value in the buffer:
v = circularBuffer.Get()

•  Call the method associated with a thermostat object

(named thermostat) that sets the temperature to be
maintained:
thermostat.setTemp(20)

OO Design & UML 66

Encapsulation (communicating through interfaces)

•  Features are:
–  public
ChangeOwner •  typically the operations
GetOperations –  private
DepositMoney •  typically the attributes
OpenAccount •  Private features are visible and can be
CloseAccount modified only through suitable public
features
number
owner •  From the point of view of the user (the client)
balance objects become black boxes that are used
through their interfaces
Bank account class

OO Design & UML 67

 Summary: objects in OOD

•  Objects are abstractions of entities in the system or in

the “outside world”
•  Objects are independent and encapsulate information
about the state
•  Objects provide services (functionalities)
•  Objects do not share memory; they communicate
through message passing
•  Objects can be physically or logically distributed, and
they can be executed in sequence or in parallel

OO Design & UML 68

 Object-oriented development
•  Using OO in different phases: analysis (OOA), design (OOD) and
programming (OOP)
–  related but separated
•  OOA: develop an object model of the application domain and identify the
responsibilities of the system being developed
•  OOD: develop an OO model of a sw system that implements the
requirements
•  OOP: realize an OO design using a OO programming language (Java, C++,
C#…)
•  When designing a system, one can use only OOA, or only OOA
and OOD, then implement everything with a non-OO
programming language (e.g., C)
–  but then one has to be careful in implementing the right semantics

OO Design & UML 69