Lecture2

Lecture2 - decomposition .fm 9 February 2003 22:53...

Info iconThis preview shows pages 1–4. Sign up to view the full content.

View Full Document Right Arrow Icon
SOFTWARE QUALITY RESEARCH LABORATORY University of Limerick 1 /52 decomposition .fm 9 February 2003 22:53 Decomposition of Software Into Components David Lor g e P arnas,P .Eng , Ph.D, Dr .h.c., Dr .h.c., FRSC, F A CM, FCAE SFI Fellow, Professor of Software Engineering Director of the Software Quality Research Laboratory (SQRL) Department of Computer Science and Information Systems Faculty of Informatics and Electronics University of Limerick Abstract Most software products are too large to be completed by a single person in short period. To make the development manageable, the software must be divided into components that can be developed (and later maintained) separately. Each component will be a work assignment for a team or individual. It is often thought that this decomposition is a management decision, determined primarily by the talent available. This lecture explains that the decomposition is a critical design decision to be made on the basis of simple technical criteria, which will be stated and illustrated. The result is a very unconventional, but easily maintained, design.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
SOFTWARE QUALITY RESEARCH LABORATORY University of Limerick 2 /52 decomposition .fm 9 February 2003 22:53 Thinking about Lar g e Pr ograms What is a “lar ge program”? One too large to be written by one person in a few days. Wh y are lar ge programs dif ferent? There are many tiny details. It is difficult, often impossible to keep all of those details in mind all the time. When there are several programmers, nobody is familiar with everything in the program. If the program is written over a period of more than a few days, people forget the details of what they have done. Errors in one part often affect other parts. Ho w should we respond to these problems? We organise programs into components called modules. Production of a module is a piece of work for a programmer or a group of programmers. Modules can be subdivided into smaller modules. Even individuals organise their work in modules. Is modularisation an engineering issue? Some treat it as management: assigning people work. There are technical issues: issues independent of the people available. Dividing a program into modules is the subject of this lecture.
Background image of page 2
SOFTWARE QUALITY RESEARCH LABORATORY University of Limerick 3 /52 decomposition .fm 9 February 2003 22:53 What is a module? Historically modules were simply a unit of measure . Manufacturers learned to build parts that measured one such unit as this simplified both their job and that of the customers. The word now means the parts themselves. Modules are usually relatively self-contained systems that are combined to make a larger system. Design is often the assembly of many previously designed modules.
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 4
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 52

Lecture2 - decomposition .fm 9 February 2003 22:53...

This preview shows document pages 1 - 4. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online