6/26/2009

Software Modularity and

Software Design Software Modularity

Summary Modularity
• Software Modularity: Benefits and Principles
• Object-Oriented (OO) Design • Constructing systems is a complex task
• Features of Good OO Design
• Software Maintenance Activities • Systems are designed and constructed such
• Design Defects that they consist of smaller, independently
• Refactoring manageable subsystems.

1
 6/26/2009

Modularity Software Modularity

• A problem is • Modern software systems consist of
decomposed to several thousands of lines of code.
sub problems.
• Decomposition of software into several
• For example, a subsystems is a fundamental issue in software
mechanical engineer engineering.
designs a car in terms
of engine, brakes, • The purpose is to manage the complexity of
transmission, chassis, software.
etc.

Software Modularity Software Modularity

• In software construction, subsystems are
commonly referred as modules.
• In earlier days of computer programs,
modularity in software was not an issue: • Software modularity refers to creating
– Small applications independent, self-managing modules in software
that are connected by well-defined interfaces.
– Tiny set of commands
– Limited Memory
• Modules are constructed such that
– software is decomposed into several modules, and
• Thus, programs were not complex. – each module is independent of other.

2
 6/26/2009

Benefits of Modularity Principles of Modularity

• A software design method can be called modular
if:
• Architectural Design – It helps in the task of decomposing a software
problem into a smaller number of problems,
• Debugging
– Software elements can be freely combined with each
• Testing other to produce new systems,
– It favors understandability such that a human reader
• Maintenance can understand each module without having to know
the others
• Independent Development – A small change in software specifications will trigger a
• Software Reuse change of just one module, or a small number of
modules

Software Modularity Modular Continuity

• Various programming languages provide • Most important principle as far as software
different constructs to create modules. change and evolution is concerned
• Continuity means that the changes should
Language Support for Modules
affect individual modules rather than the
Pascal Procedures or Functions
C Functions
whole system.
Java Classes and Packages • Can save a lot of effort and thus investment
C# Classes and Assemblies

3
 6/26/2009

Alarm Clock Example

Some Rules for Modularity
• Few Connections (Interfaces) • Alarm Clock Example
– Every module should communicate with as few others – What are the attributes and methods of an alarm
as possible
clock object?
• Small Interface
– Two communicating modules should exchange as little – Attributes: Hour, Minute, AlarmStatus,
information as possible AlarmHour, AlarmMinute

• Information Hiding – Methods: Set_Time(), Set_Alaram(),

– A subset of module’s interfaces be selected as the ResetAlarm(),
official information that is available to client modules

Object-Oriented Classes Objects vs. Classes

• Classes are the basis for modular software in • Class is a recipe to create objects
object-oriented paradigm
Hour Minute AlarmStatus
• Classes are the real world entities AlarmHour AlarmMinute

• Classes are identified from the domain

analysis
Hour = 3 Hour = 9 Hour = 7
• Classes contain the attributes and behavior of Minute = 40 Minute = 05 Minute = 55
an object AlarmStatus = off
AlarmHour = 6
AlarmStatus = on
AlarmHour = 9
AlarmStatus = on
AlarmHour = 10
AlarmMinute =40
• One class should capture one object AlarmMinute =55 AlarmMinute =46

4
 6/26/2009

Encapsulation
• How many people can build an alarm clock?
• How many people know what an alarm clock
is?
Features of Good Object-Oriented • Public Interface vs. Implementation
Design • All the data and associated behavior should be
encapsulated in a single class
• A class should expose its behavior through
public interfaces

Hiding Data Cohesion

• All data belonging to a class should be hidden • A measure of how well the lines of source
within the class code within a module work together to
provide a specific piece of functionality.
• Data should be hidden behind the public
interfaces
• In object-oriented programming, the degree
• Methods should be used to change the to which a class implements a single object.
attributes of an object
• Methods that implement a single function are
described as having high cohesion.

5
 6/26/2009

Cohesion
• Keep related data and behavior in one place
• Spin-off non-related information into
another class
Software Maintenance
• Class should capture only one key
abstraction
• Example …

21

Coupling Software Maintenance

• Coupling is a measure of how much two • “There is nothing permanent except change”
items, such as classes or methods, are
interrelated. • Software maintenance starts once the product
is delivered to the customer
• Low coupling often correlates with high
cohesion, and vice versa. • Maintenance efforts are required because:
– Rapidly changing technology
• High cohesion and low coupling are attributes – Ever changing user expectations
of good design. – Bugs in software

6
 6/26/2009

Software Maintenance Types Maintainability

• Corrective Maintenance • Maintainability: The ease with which
• Product does not meet customer requirements: bugs
• Preventive Maintenance software can be understood, corrected,
• Avoid potential future problems: Virus Updates adapted, or enhanced
• No direct discernible effect on the user, but lay the groundwork for
easier maintenance in future
• Adaptive Maintenance
• The process modifying the system to cope with technological or • Good software design can reduce these costs
environmental changes
• Perfective maintenance
because the changes that are requested are
• Users and marketers are never satisfied: Need new features easily brought about in the software (modular
• The process of receiving suggestions and requests for
enhancements or modifications and implementing them continuity)

Maintenance Costs Software Maintenance and Design

• Software maintenance eats up to 70% of the software • Maintenance efforts do not always fit to the original
costs software design
– New features may not fit in the current classes and methods
– When these features are introduced in the current classes,
• The magnitude of this proportion seems to reflect the these break program design
lack of extendibility of commonly implemented
software
• Up-front (initial) design does not survive contact with
implementation
• Drawbacks – Unforeseen problems
– Lost opportunities (for new development) – Misunderstandings about the intended design
– Customer dissatisfaction
– Overall productivity • The design of software decays – as changes are applied to
code (and design), software loses its original structure.

7
 6/26/2009

Software Design Defects

• Design defects are problems in software design.

• These are deviations from well-known design norms.

Software Design Defects • Design defects also occur due to bad design practices.

• Caveat: Design defects are not technical flaws or bugs

that may hamper the smooth execution of programs

Erosion of software design Software Design Defects

• Software modularity dilutes and changes affect

many modules
• Bad design practices are also called
AntiPatterns.
• Software loses its self-documenting property – it
is not merely understood by reading code
• Deviations from well-known norms are known
• Hence, software design needs to be searched for as code smells.
Design Defects

8
 6/26/2009

An Example
Another Example
Class Student Class Course class Order {
{ { ...
boolean IsSameString(String s1, String s2){
String reg_no; String student_name; if(s1==s2) return true;
String course_name; Time time; if(s1==null) return false;
int age; } return(s1.equals(s2));
}
Course [ ] _courses; }
}
class Mail {
Class Student
...
{ Class Course static boolean IsSameString(String s1, String s2) {
String reg_no; { if (s1 == s2)
String student_name; String course_name; return true;
if (s1 == null)
int age; Time time; return false;
Course [ ] _courses; } return (s1.equals(s2));
}
}
}

Another Example Solution

class Order { class StringComparer {
... static boolean IsSameString(String s1, String s2) {
boolean IsSameString(String s1, String s2){ if (s1 == s2) Duplicate Code
if(s1==s2) return true; return true; moved or Refactored
if(s1==null) return false; if (s1 == null) to a new Class
return(s1.equals(s2)); return false;
} return (s1.equals(s2));
} } •Method reuse the
} code instead of
class Mail {
duplicating it
...
•One change point
static boolean IsSameString(String s1, String s2) { class Order { class Mail {
if (s1 == s2) ... ...
return true; boolean IsSameString(String s1, String s2){ static boolean IsSameString(String s1, String s2) {
return StringComparer.IsSameString(s1, s2); return StringComparer.IsSameString(s1, s2);
if (s1 == null) } }
return false; } }
return (s1.equals(s2));
}
}

9
 6/26/2009

Another Example Solution

Class Person
Class Person
{
{
string name;
string name;
TelePhoneNumber telno;
String officeAreaCode;
}
String officeNumber;
Class TelePhoneNumber
public String getTelephoneNo()
{
{
String officeAreaCode;
return (officeAreaCode + officeNumber);
String officeNumber;
}
public String getTelephoneNo()
}
{
return (officeAreaCode + officeNumber);
}
}

Another Example Code Smells

Class Person • Code smells refer to code-level design
{
string name;
problems present in software
String officeAreaCode;
String officeNumber;
public String getTelephoneNo() • Code smells indicate the presence of design
{ defect
return (officeAreaCode + officeNumber);
}
} • Indicate the opportunity to refactor the code
by removing the code smell

10
 6/26/2009

Some Code Smells Refactoring

• Duplicate Code • Program design needs to be continually evaluated and updated
– Most fundamental design problem in software
• Otherwise, design defects appear that mar software maintenance
– Some abstraction is missing activities
– Bugs get replicated easily
• “Refactoring is the process of changing a software system in such a
• Large Class way that it does not alter the external behavior of the code yet it
– Class has poor cohesion improves its internal structure”.
– Too many instance variables or methods means a class is doing too Martin Fowler
much
– Class interface does not provide consistent level of abstraction • Removing design anomalies
• Long Method • Reduces the changes of bugs and technical flaws
– A method trying to do too much • 70% of software cost is due to extensions, hence it is critical to
– Undermines the reusability of code maintain a coherent software structure.
– Complex method Difficult to change

SDLC and Refactoring

• Improving design after the code is written?
• But normally, we design and then we code
• Erosion in software structure introduces
Software Refactoring design defects
• Refactoring realigns design according to the
current specification
• William Opdyke introduced the idea in his PhD
dissertation

11
 6/26/2009

Agile Development Concluding remarks

• Agile Software Development is about iterative • A problem is decomposed to several sub problems.
software development • The purpose is to manage the complexity of software.
• Prototypes are rapidly developed • Continuity means that the changes should affect
• Four activities: planning, design, coding, and individual modules rather than the whole system.
testing • Classes are the basis for modular software in object-
• A small number requirements are worked upon oriented paradigm
each time • Continuous maintenance efforts erode program design
• Pair-Programming, Increased user integration, • Design defects are problems in software design.
and Automated Testing • Refactor recreates design in existing software
• Refactoring is considered a part of XP

Benefits of Refactoring
• Ease of making changes: no ripple effects

• Code Reuse

• Distribution of responsibilities

• Design improvement without breaking code

12