DESIGN MODULARITY
Extendibility
Reusability
WHY A DESIGN METHOD NEEDS TO BE
MODULAR
• Decomposability
• Helps in the task of obtaining independent sub-problems
(division of labor).
• E.g., Top-down design.
• Composability
• Favors development of well-defined software elements that
can be freely combined in different contexts.
• E.g., Subroutines for Numeric Computation (FORTRAN).
• E.g., Functions for List processing (LISP).
• In general, top-down design does not favor composability.
• Continuity
• Small changes in problem specification should trigger small changes
in software modules.
• E.g., Use of symbolic constants.
• E.g., Pascal’s monolithic programs vs Ada’s packages.
• E.g., C’s-Union type vs C++/Java’s Class hierarchy
(Polymorphism/Dynamic binding).
• Understandability
• E.g., Documentation
• Protection
• Containing the effects of run-time errors.
MODULAR SOFTWARE
• Direct Mapping
• Structure of the problem domain is reflected in the structure of the
software solution.
• Strong (Internal) Cohesion (intra-modular)
• Degree of binding among elements in the module.
• Minimal (External) Coupling (inter-modular)
• Dependency between modules.
• Information Hiding
• Separation of behavior specification from implementation
details.
• Client may rely only on server’s public interface.
• Open-Closed Principle
• Module for extension (by server) in future.
• Module for use (by client) now.
• Single Choice Principle
• Whenever a software system must support a set of alternatives,
one and only one module in the system should know their
exhaustive list.
BENEFITS OF REUSABILITY
• Enhancing reusability enhances almost all the other
software quality by promoting sharing of experts’
work.
• Timeliness (Time to market)
• Decreased maintenance effort
• Reliability
• Efficiency
• Consistency
• Economy
THE REUSE-REDO DILEMMA
• The realities of practical software development requires
combining reuse and adaptation.
• The right notion of module must reconcile reusability and
extendibility, closure and openness, satisfying today’s
demands and trying to guess what future holds.
REUSABLE MODULES
Reusable modules must be adaptable.
• Abstractions/Frameworks
• “Lower-level” details changeable/pluggable.
• E.g., Java applets, Java threads, etc.
• Generalization through parameterization
• Customizable by instantiation.
• E.g., Generic stack, Generic queue, etc.
• Software Components
• Design Patterns
EXAMPLE : TABLE DATA
• Applications
STRUCTURE
• Symbol table in Compiler
• File System Directory
• Database (Relations)
• Implementation based on:
Array, Linked list, Binary search trees,
Hash tables, B-trees, Heaps, etc
TABLE
IMPLEMENTATIONS
HASH SEQUENTIAL TREE
ARRAY LINKED FILE
SEARCHING A SEQUENTIAL
TABLE
Has(t
Has : seq_table; x : element) : bool is
do
from start
until after or else found(x)
loop forth end;
return (not after)
end;
REQUIREMENTS ON REUSABLE
MODULES
• Type variation
• E.g., Ada generics, C++ templates, etc
• Routine grouping (“quantum”)
• As it is possible to apportion “work” among the routines in
different ways and yet achieve the same overall behavior.
(Mutual consistency)
• E.g., Set of characters abstraction can be implemented using a
sorted list, a list without duplicates, a sorted list without
duplicates, a packed boolean array, a string, etc.
• Factoring commonality
• Code sharing (server)
• E.g., Inheritance, Abstract class, etc
• Organizing implementation variations
• Common behavior (server)
• E.g., Polymorphism, Dynamic binding, etc
• Representation Independence (client)
• E.g., Dynamic binding.
• Reusing existing modules (client)
• E.g., Composition, Delegation.
EXAMPLE MODULE
STRUCTURES
• Routines : Functions and Procedures
• E.g., C, Pascal, etc
• Packages
• E.g., Modula, CLU, etc
• Generic Routines and Packages
• E.g., Ada, etc.
• Class Hierarchy
• E.g., Java, etc.
• Generic Class Hierarchy
• E.g., C++, Ada-95, etc.
OVERLOADING
• Ad hoc polymorphism
• Capturing Similarity
• Convenient for code integration (avoiding apparent name
clashes).
• Name Overloading
• Conserving names.
• Operator Overloading
• Conforming to domain vocabulary.
OBJECT-ORIENTED SOFTWARE
DEVELOPMENT
• Bases the architecture of a software system on modules
deduced from the types of objects it manipulates (rather than
the functions it is intended to ensure).
• Issues
• How to find and use relevant object types?
• Object-Oriented Analysis and Design
• How to describe and implement the object types and their
relationships?
• Object-Oriented Programming (Language)
