Chapter28 - 28 The software construction process F oremost...

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

View Full Document Right Arrow Icon
28 The software construction process F oremost among the methodological issues of object technology is how it affects the broader picture of software development. We will now examine the consequences of object-oriented principles on the organization of projects and their division into phases. Such a presentation is part of a more general topic: the management perspective on object technology. Another book, Object Success , explores management issues in detail. The discussion which follows, drawing in part from Object Success , presents the essential ideas: clusters , the basic organizational unit; principles of concurrent engineering leading to the cluster model of the software lifecycle; steps and tasks of that model; the role of generalization for reusability; and the principles of seamlessness and reversibility . 28.1 CLUSTERS The module structure of the object-oriented method is the class. For organizational purposes, you will usually need to group classes into collections, called clusters — a notion briefly previewed in the last chapter’s sketch of the Business Object Notation. A cluster is a group of related classes or, recursively, of related clusters. The two cases are exclusive: for simplicity and ease of management, a cluster that contains subclusters should not have any classes of its own. So a cluster will be either a basic cluster , made of classes, or a supercluster , made of other clusters. Typical basic clusters could include a parsing cluster for analyzing users’ text input, a graphic cluster for graphical manipulations, a communications cluster. A basic cluster will typically have somewhere between five and forty classes; at around twenty classes, you should start thinking about splitting it into subclusters. The cluster is also the natural unit for single-developer mastery: each cluster should be managed by one person, and one person should be able to understand all of it — whereas in a large development no one can understand all of a system or even a major subsystem. Clusters are not super-modules. In an earlier chapter we saw the arguments for avoiding the introduction of units such as packages, and instead keeping a single module mechanism, the class. [M 1995] . On super-modules see “The architectural role of selective exports”, page 209 .
Background image of page 1

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

View Full DocumentRight Arrow Icon
THE SOFTWARE CONSTRUCTION PROCESS § 28.2 924 Unlike packages, clusters are not a language construct, although they will appear in the Lace control files used to assemble systems out of components. They are a management tool. The responsibility for finding clusters will rest with the project leader; less challenging than the task of finding classes, studied in detail in a previous chapter, clustering classes mostly relies on common sense and the project leader’s experience. This point actually deserves some emphasis, as it is sometimes misunderstood: the truly difficult job, which can launch a project on to an auspicious life or wreck it, and for which one can talk of right and wrong solutions, is to identify the classes (the proper data
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 12

Chapter28 - 28 The software construction process F oremost...

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

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