Modularity
Extendibility
Reusability
ceg860 (Prasad)
L6MR
1
Criteria for a Design Method to be Modular
• Decomposability
• Helps in the task of obtaining independent subproblems (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.
ceg860 (Prasad)
L6MR
2
• 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.
ceg860 (Prasad)
L6MR
3
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.
ceg860 (Prasad)
L6MR
4
• 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.
ceg860 (Prasad)
L6MR
5
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
ceg860 (Prasad)
L6MR
6
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.
ceg860 (Prasad)
L6MR
7
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
ceg860 (Prasad)
L6MR
8
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
ceg860 (Prasad)
L6MR
9
Table Implementations
HASH
ARRAY
ceg860 (Prasad)
SEQUENTIAL
LINKED
L6MR
TREE
FILE
10
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;
ceg860 (Prasad)
L6MR
11
start
forth
after
found (x)
A rray
i := 1
i+ +
i > count
t[i] = x
L ist
c:= first c:= c.right
c = null
c.ite m = x
F ile
rew ind
eof
f^ = x
ceg860 (Prasad)
read
L6MR
12
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.
ceg860 (Prasad)
L6MR
13
• 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.
ceg860 (Prasad)
L6MR
14
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.
ceg860 (Prasad)
L6MR
15
Overloading
• Ad hoc polymorphism
• Capturing Similarity
• Convenient for code integration (avoiding
apparent name clashes).
– Name Overloading
• Conserving names.
– Operator Overloading
• Conforming to domain vocabulary.
ceg860 (Prasad)
L6MR
16
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)
ceg860 (Prasad)
L6MR
17
Descargar

Modularity - Wright State University