7/30/2019 INTRODUCTION TO SOFTWARE ENGINEERING Assignment #8 Submitted by: Mustafa DEERL

1/2

MIDDLE EAST TECHNICAL UNIVERSITY

INFORMATICS INSTITUTE

DEPARTMENT OF INFORMATION SYSTEMS

IS 507

INTRODUCTION TO SOFTWARE ENGINEERING

Assignment #8

Submitted by:

Mustafa DEERL

138214-2

Submitted to:

Assist. Prof. Dr. Aysu BETN CAN

Res. Assist. Mahir KAYA

Date of Submission: May 16, 2010

7/30/2019 INTRODUCTION TO SOFTWARE ENGINEERING Assignment #8 Submitted by: Mustafa DEERL

2/2

In this paper, I summarize the main points mentioned in D. L. Parnass On the Criteria to be Used in

Decomposing Systems into Module titled paper, in the form of bulleted list.

Modularization can be treated as a sort of mechanism that is there in order to improve the

flexibility and comprehensibility of a system, which also provides the development time of the

system shortened.

The criteria that are used to split the system into modules are the main factors that determine the

effectiveness of the modularization to be done.

When compared with the conventional decompositions, the unconventional ones provide

diverse pluses meant for the drawn goals. However, mixing the unconventional ones with the

ones of conventional, that is conventional assumptions done in unconventional decompositions,

the efficiency of the decompositions will remarkably be diminished

There are essentially two things provided by the advancements in the area of modular

programming. These are making it possible to write one module with a little knowledge of the

code in any other module, and making it achievable to reassemble and replace a module not

including doing the same things for the other modules. Including these benefits, there are

expected benefits that will stem from modular programming with respect to different contexts.

These can be stated as with respect to managerial context, development time is reduced; with

respect to product flexibility context, extreme changes could be done on one module without

doing the same for the other modules; and with respect to comprehensibility context, it is

feasible to work on the one module of the system at a time.

For most programmers, the modularization is done through dividing system into number of

modules with definite interfaces. In this context, dividing is done to prove that modules are

simply enough and small enough to be understood and programmed thoroughly.

In his paper, Parnas gives two modularization examples based on a system, namely KWIC

Index Production System. The first one is done by means of conventional decomposition model,

and the second one is done by means of unconventional decomposition model. Both models

used are to reduce the whole programming to relatively independent programming of small and

manageable programs.

Additionally, Parnas compares and contrasts the both models with respect to changeability,independent development and comprehensibility principles. Finally, he comes up with the

unconventional model, namely unconventional decomposition model, providing more expected

results and gains.

Whereas the conventional decomposition model is principally based on the flowcharts, the

unconventional decomposition model is mostly based on the information hiding principle,

which is hiding one modules design decisions from the others.

The foremost requirement of the unconventional decomposition model is that each module

hides some decision particulars from the rest of the system module or modules. Nonetheless,

there are other principles in unconventional decomposition model. These are: data structure, its

internal linking, accessing and modifying procedures are a part of a single module; instructions

necessary to call a given routine and routine of itself are a part of the same module; the formatof control blocks must be hidden within a control block module; a greatest flexibility module

must be there to include character codes, alphabetic orderings, and similar data; and the

sequence in which certain items will be processed should be hidden within a single module.

Parnas also criticizes the importance of the efficiency and implementation of the

decompositions, and he stresses that there must be a sort of decomposition common to a

compiler and interpreter for the same language.

In conclusion, starting to decompose a system into modules based on the flowcharts is the worst

thing to do to start for a decomposition process. Alternatively, Parnas offers that one had better

to start decomposition process with that he or she begins with a list of difficult design decisions

or changeable design decisions.