1 / 14

On the Criteria to Be Used in Decomposing Systems into Modules

This paper discusses the criteria for decomposing systems into modules to improve flexibility, comprehensibility, and development time. It provides a historical perspective and highlights the benefits of using a modular approach in software design. Examples and techniques for information hiding are also presented.

lmcleod
Download Presentation

On the Criteria to Be Used in Decomposing Systems into Modules

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. On the Criteria to Be Used in Decomposing Systems into Modules D. L. Parnas

  2. Modularization • Modularization is a mechanism for improving the flexibility and comprehensibility of a system while shortening its development time • The system must be decomposed into modules (a.k.a subsystems) using certain criteria • A lot of what this paper talks about is common day knowledge, but remember that it was written in the early 1970’s

  3. Historical Perspective • The concept of a module was not new when this paper was written • BUT, although others spoke about what a module was, nothing was done to describe how a system is decomposed into modules • Major contribution is that Parnas provides criteria for decomposing systems into modules (and not for the notion of a module itself)

  4. Benefits of using a Modular Approach to Software Design • Managerial – individual modules can be developed concurrently since they will be specified by their external behavior and interfaces • Flexibility – individual modules should be able to be changed without radical impact to the rest of the system • Program Understanding – possible to study the systems more abstractly – by understanding the modules prior to understanding the code

  5. What is a Module • A module is not a subprogram it’s a work assignment • Design at the module level first – then define the modules themselves • A module is categorized by the design decision(s) that it hides from all of the other modules in the system (information hiding) • Sounds a lot like the approaches we use today for design of object- and component-oriented programs (30+ years later)

  6. Dividing a System into Modules • A module is physically categorized by a well defined interface that is small and simple enough to be thoroughly understood and well programmed • There is no question about what a modules is - the real question is about how a system is decomposed into modules, and how to compare one modularization to another modularization

  7. Parnas Example: KWIC Index – Classical Modularization Input Storage (File/Memory) CircularShift Controller Alphabetizing Output Criteria for Decomposition: Processing Steps

  8. Parnas Example: KWIC Index – Information Hiding Modularization Input Storage (File/Memory) Line Storage Controller CircularShifter Alphabetizer Output Criteria for Decomposition: Information Hiding

  9. Revisiting the Motivation for using a Modular approach to Design Software • Changeability – The information hiding approach supports change much easier. The classical technique would require modifications to many modules to support most changes – the IH approach hides representation behind module interfaces • Independent Development – IH interfaces are more abstract, supporting concurrent development easier (consider needing to change the data structure) • Comprehensibility – As per the changeability benefits described above – more detailed understanding of the overall system is required with the classical technique The IH approach better supports exception management and error processing

  10. Example: J2EE Generation 1: Servlets • Simple approach towards web-based system development • Servlet does not hide very much information • Manages the entire UI, all of the control logic, all of the business logic, and any database interaction http Servlet http

  11. Example: J2EE Generation 2: Servlets & JSP’s • Better separation of input and output processing • Support for different output formats • Servlet still “knows” too much about overall system • Its hard to reuse certain aspects of a system using a servlet/jsp solution http Servlet JSP http

  12. Example: J2EE Generation 3: Full MVC Approach • Good example ofinformation hiding • Well defined interfaces • Reuse presentation andbusiness logic • Reuse componentsoutside of the webdomain http Controller (Servlet) Configuration View Beans Action Classes Result Beans Exceptions Business Logic http JSP

  13. Summary • Parnas mentions some constraints about information hiding such as needing to go through interfaces and the cost associated with doing so • Parnas suggests some techniques to deal with these problems • Fortunately, today we don’t have to worry about the overhead of function and/or method calls • Doesn’t the information hiding approach sound a lot like OO?

  14. Summary • Parnas also gives another plug for upfront design by stating that the criteria used to decompose a system into modules cannot be easily determined at runtime • Parnas suggests that to check the degree of information hiding compliance you should investigate change scenarios • Parnas demonstrated this on the IH decomposition of the KWIC system by showing some IH gaps and a design flaw • Parnas further comments on hierarchies by stating that the decomposition of a system into modules does not necessarily need to be hierarchical

More Related