ceg860 (prasad)l6mr1 modularity extendibility reusability

ceg860 (Prasad) L6MR 1

Modularity

Extendibility

Reusability


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.


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


Table Implementations

HASH

SEQUENTIAL TREE

ARRAY LINKED FILE


Searching a sequential table

HasHas(t : seq_table; x : element) : bool is

do

from start

until after or else found(x)

loop forth end;

return (not after)

end;


start forth after found(x)

Array i := 1 i++ i > count t[i] = x

List c:= first c:= c.right c = null c.item = x

File rewind read eof f^ = x


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 charactersSet 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).

• IssuesIssues– 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)l6mr1 modularity extendibility reusability

Documents