Modularity

1
Modularity

• Extendibility
• Reusability

2
Criteria for a Design Method 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.

3

• Continuity
• Small changes in problem specification should
  trigger small changes in software modules.
• E.g., Use of symbolic constants.
• E.g., Pascals monolithic programs vs Adas
  packages.
• E.g., Cs-Union type vs C/Javas Class
  hierarchy (Polymorphism/Dynamic binding).
• Understandability
• E.g., Documentation
• Protection
• Containing the effects of run-time errors.

4
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.

5

• Information Hiding
• Separation of behavior specification from
  implementation details.
• Client may rely only on servers 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.

6
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

7
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 todays demands and trying
  to guess what future holds.

8
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

9
Example Table Data Structure

• Applications
• Symbol table in Compiler
• File System Directory
• Database (Relations)
• Implementation based on
• Array, Linked list, Binary search trees,
• Hash tables, B-trees, Heaps, etc

10
Table Implementations
TREE
HASH
SEQUENTIAL
FILE
ARRAY
LINKED
11
Searching a sequential table

• Has(t seq_table x element) bool is
• do
• from start
• until after or else found(x)
• loop forth end
• return (not after)
• end

12
(No Transcript)
13
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.

14

• 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.

15
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.

16
Overloading

• Ad hoc polymorphism
• Capturing Similarity
• Convenient for code integration (avoiding
  apparent name clashes).
• Name Overloading
• Conserving names.
• Operator Overloading
• Conforming to domain vocabulary.

17
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)