1 / 17

Modularity

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

demetrius-kelly
Download Presentation

Modularity

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Modularity Extendibility Reusability L6MR

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

  3. 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’sClasshierarchy(Polymorphism/Dynamicbinding). • Understandability • E.g., Documentation • Protection • Containing the effects of run-time errors. L6MR

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

  5. 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. L6MR

  6. Benefits of Reusability • Enhancing reusability enhances almost all theother software quality by promoting sharing of experts’ work. • Timeliness (Time to market) • Decreased maintenance effort • Reliability • Efficiency • Consistency • Economy L6MR

  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 today’s demands and trying to guess what future holds. L6MR

  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 L6MR

  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 L6MR

  10. Table Implementations TREE HASH SEQUENTIAL FILE ARRAY LINKED L6MR

  11. Searching a sequential table Has(t : seq_table; x : element) : bool is do fromstart untilafteror elsefound(x) loopforthend; return (notafter) end; L6MR

  12. L6MR

  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. (Mutualconsistency) • 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. L6MR

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

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

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

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

More Related