on the criteria to be used in decomposing systems into modules team 3 nupur choudhary aparna...

On the Criteria to Be Used in Decomposing Systems into

Modules

Team 3

Nupur Choudhary

Aparna Nanjappa

Mark Zeits

CS-575 Software Design - Team 3

An Overview Introduction What is a Module ? Some Buzzwords Address book system Information Hiding Java Bean Example Modular Hierarchy Conclusion


A Risk of Bad Design

• 103-year-old man told to bring parents foreye test (comp.risks Aug 22, 2002)– British pensioner Joseph Dickinson, 103, had ashock when his local hospital called him in for aneye test and told him to bring his parents. "I mustbe getting younger, in fact much younger," he toldhis local paper, the Hartlepool Mail. He was bornin 1899, but because the hospital computer onlyread the last two digits it mistook his age as justthree years old....


Historic Context 1960s

Structured Programming Formally specifying the semantics of

programming languages and proving programs satisfy a predicate.

Adopted because it’s a better way to think about programming

1970s Structured Design

Methodology/guidelines for dividing programs into subroutines.


Historic Context (contd...) 1980s

Modular (object-based) programming

Grouping of sub-routines into modules with data.

1990s Object-Oriented Languages

started being commonly used Object-Oriented Analysis and

Design for guidance.


Introduction Decomposition in Engineering

Crystal Palace

– Built for the 1851 Great Exhibition

– Covered ~19 acres in London’s Hyde Park

– Completed in 17 weeks, possible in part

because of its modular design


Introduction

Because maintenance costs dominate development costs, it is desirable to design a system that can easily adapt to change

Change is costly when a whole system must be examined/altered to deal with a “small” change

Importance of Modularization


What is a Module?

A Work Assignment.Represented by a design decision

specific to itself and unknown to other modules

Support flexibility in implementationDo Not represent steps in processingLow coupling, high cohesion.


Some Buzzwords

Module - parts that can be put together to make a complete system

- work assignment, subroutine, memory load , functional component

Encapsulation - language facility Information Hiding - design principle


An Address Book System

Contacts are stored in a plain text file

They are stored in the following syntax

Powers,Austin 69 Mojo Drive 800-

OBEHAVE

All contacts are separated by a semi-

colon


Modularization 1

Data StorageData StorageControls format of data

storage

AddAddAdds a contact

DeleteDeleteDeletes a contact

SortSortSorts contacts

FindFindFinds a contact

w

rw

rw

r


Got Change?

But what if we would like to change the format of data storage to -

[Powers,Austin|69,Mojo Drive|1-800-OBEHAVE]

What modules will we need to modify?

ALL OF THEM!!!!


Modularization 2

Data StorageData StorageControls format of data

storage

Read/Write InterfaceRead/Write InterfaceReads from, writes to address

book

AddAddAdds a contact

DeleteDeleteDeletes a contact

SortSortSorts contacts

FindFindFinds a contact

w

rw

rw

r


Modularization 2

In this design, the new change would only

require modifying the Data Storage and the

Read/Write Interface modules.

The Add, Delete, Sort and Find modules do

not need any changes. Their algorithms

remain untouched.

Why?


Comparing Rationales

Modularization 1 Modularization 2

Design Criterion

Each major processing step is made into a module

Modules are designed using the principle of information hiding

Is task-specific?

Yes. For e.g., the Add module is responsible for directly adding a contact into the address book.

Yes. For e.g., the Add module is responsible for directly adding a contact into the address book

Inter-dependence

HIGH. All modules are heavily dependent on the Data Storage module

NONE. All modules are independent!


Information Hiding

Before decomposing a system into modules,

a list of all possible design changes is made -

Hiding Assumption List

Each module hides the implementation of an

important design decision so that only the

constituents of that module know the details

All design decisions are independent of each

other


Information Hiding in Modularization 2

Modularization 2 used this principle of

Information Hiding.

All of its modules are independent and

have well-defined interfaces.

There is very low coupling between

them.


Information Hiding in Modularization 2

Each module is very task-specific. All

modules are highly cohesive.

For example, the sorting algorithm is

known only to the Sort module. Similarly,

the format of data storage is known only to

the Read/Write Interface module.


Benefits of Good Modular Design

Independent Development

Since each module is

independent, they can be

developed independently at the

same time Shortened

Development Time!



Product Flexibility & Reusability

Modules can be easily modified

without affecting the rest of them.

More over, modules can be easily

replaced to add, enhance or

change product capabilities.



Comprehensibility

It is easier for programmers to

fully understand the design of

the entire product by individually

studying the modules.


Another example – JavaBeans

JavaBeans are modular by nature.Perform single tasksAre reusable and platform independentChangeable throughout lifeUse Introspection to retrieve information

about capabilitiesSupports bound & constrained

properties


Another example – JavaBeans

The “GetApplic” JavaBeanSupply Database, Cable number and/or

equipment numberRetrieves “Applicability” from databaseVery good example of Information

Hiding


Modular Hierarchy

For Modularization 2 of the Address

Book System, using Dijkstra’s

method, we have:

Level 1 – Data Storage

Level 2 – Read/Write Interface

Level 3 – Add, Delete, Find, Sort


Modular Hierarchy

Level 3

Level 2

Level 1

Depends on

Depends on


The Module Guide Assists a maintenance programmer during

debugging to find modules that are affected

by a change or are causing problems.

Includes brief description module role

Shows how responsibilities are allocated

among major modules

States the criteria behind responsibility

assignment


Conclusion

High utility of Parnas’ partitioning approach to

design of flexible computer systems

This approach does not obsolete other

modularity criteria

It is desirable to have small, manageable

modules and various design principle should

be used in conjunction with Parnas’

partitioning for best results


References

“Parnas Partitioning” by A.J. Maher Java World “Some Software Engineering Principles” by

D.L. Parnas “The Modular Structure of Complex Systems”

by D.L. Parnas Citations : IEEE Transactions on Software

Engineering


Any questions?

on the criteria to be used in decomposing systems into modules team 3 nupur choudhary aparna...

Documents

software design team

design principlecs

modules team

risk of bad design

design decision specific

obehavewhat modules

local hospital

sobjectoriented languages