28 The software construction process oremsmog the methodoo issues of bjec noloyishow it afectsthe 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. [M1995]. 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 ofit-whereas in a large development no one can understand all of a system or even a major subsystem. Onsuper-modulessee “The architectural Clusters are not super-modules.In an earlier chapter we saw the arguments for role of selective avoiding the introduction of units such as packages,and instead keeping a single module exports".page 209. mechanism,the class
28 The software construction process Foremost 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
924 THE SOFTWARE CONSTRUCTION PROCESS $28.2 Unlike packages,clusters are not a language construct,although they will appear in On Lace see"Assem- the Lace control files used to assemble systems out of components.They are a blingasystem".page management tool.The responsibility for finding clusters will rest with the project leader; 198. 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 abstractions);grouping these classes into clusters is an organizational matter,for which many solutions are possible,depending on the resources available and on the expertise of the various team members.A less-than-optimal clustering decision may cause trouble and slow the development,but will not by itself bring the project down. 28.2 CONCURRENT ENGINEERING One of the consequences of the division into clusters is that we can avoid the disadvantages of the all-or-nothing nature of traditional software lifecycle models.The well-known "waterfall"approach,introduced in 1970,was a reaction against the"code it now and fix it later"approach of that bygone era.It had the merit of separating concerns, of defining the principal tasks of software engineering,and ofemphasizing the importance of up-front specification and design tasks. FEASIBILITY The waterfall STUDY model REQUIREMENTS (WARNING:this is ANALYSIS not the recom- mended process model for 0-0 de- SPECIFICATION velopment!) GLOBAL DESIGN DETAILED DESIGN IMPLEMEN- TATION VALIDATION VERIFICATION TIME DISTRIBUTION
924 THE SOFTWARE CONSTRUCTION PROCESS §28.2 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 abstractions); grouping these classes into clusters is an organizational matter, for which many solutions are possible, depending on the resources available and on the expertise of the various team members. A less-than-optimal clustering decision may cause trouble and slow the development, but will not by itself bring the project down. 28.2 CONCURRENT ENGINEERING One of the consequences of the division into clusters is that we can avoid the disadvantages of the all-or-nothing nature of traditional software lifecycle models. The well-known “waterfall” approach, introduced in 1970, was a reaction against the “code it now and fix it later” approach of that bygone era. It had the merit of separating concerns, of defining the principal tasks of software engineering, and of emphasizing the importance of up-front specification and design tasks. On Lace see “Assembling a system”, page 198. The waterfall model (WARNING: this is not the recommended process model for O-O development!) FEASIBILITY STUDY REQUIREMENTS ANALYSIS SPECIFICATION IMPLEMENDISTRIBUTION GLOBAL DESIGN DETAILED DESIGN TATION VALIDATION & VERIFICATION TIME
$28.2 CONCURRENT ENGINEERING 925 But the Waterfall Model also suffers (among other deficiencies)from the rigidity of its approach:taken literally,it would mean that no design can proceed until all the specification is complete,no implementation until all design is complete.This is a certain recipe for disaster:one grain of sand in the machine,and the whole project comes to a halt. Various proposals such as the Spiral model have attempted to reduce this risk by providing a more iterative approach,But they retain the one-thread approach of the Waterfall,which hardly reflects the nature of today's software development,especially for large"virtual"teams that may be distributed over many sites,communicating through the Intemet and other "electronic collocation"mechanisms. Successful object-oriented development needs to support a concurrent engineering scheme,offering decentralization and flexibility,without losing the benefits of the waterfall's orderliness.We will in particular have to retain a sequential component,with well-defined activities.Object-oriented development does not mean that we can or should get rid of sound engineering practices.If anything,the added power of the method requires us to be more organized than before. With a division into clusters we can achieve the right balance between sequentiality and concurrent engineering.We will have a sequential process,but subject to backward adjustments(this is the concept of reversibility,discussed in more detail at the end of this chapter),and applied to clusters rather than to the entire system. The mini-lifecycle governing the development of a cluster may pictured as this: Individual cluster Specification lifecycle Design Implemen tation V&V Generali- zation TIME The shape of the activity representations suggests the seamless nature of the development.Instead of separate steps as in the waterfall model,we see an accretion process-think of the figure as depicting a stalactite-in which every step takes over from the previous one and adds its own contribution
§28.2 CONCURRENT ENGINEERING 925 But the Waterfall Model also suffers (among other deficiencies) from the rigidity of its approach: taken literally, it would mean that no design can proceed until all the specification is complete, no implementation until all design is complete. This is a certain recipe for disaster: one grain of sand in the machine, and the whole project comes to a halt. Various proposals such as the Spiral model have attempted to reduce this risk by providing a more iterative approach, But they retain the one-thread approach of the Waterfall, which hardly reflects the nature of today’s software development, especially for large “virtual” teams that may be distributed over many sites, communicating through the Internet and other “electronic collocation” mechanisms. Successful object-oriented development needs to support a concurrent engineering scheme, offering decentralization and flexibility, without losing the benefits of the waterfall’s orderliness. We will in particular have to retain a sequential component, with well-defined activities. Object-oriented development does not mean that we can or should get rid of sound engineering practices. If anything, the added power of the method requires us to be more organized than before. With a division into clusters we can achieve the right balance between sequentiality and concurrent engineering. We will have a sequential process, but subject to backward adjustments (this is the concept of reversibility, discussed in more detail at the end of this chapter), and applied to clusters rather than to the entire system. The mini-lifecycle governing the development of a cluster may pictured as this: The shape of the activity representations suggests the seamless nature of the development. Instead of separate steps as in the waterfall model, we see an accretion process — think of the figure as depicting a stalactite — in which every step takes over from the previous one and adds its own contribution. Individual cluster lifecycle Generalization Implemen tation Design Specification V & V TIME
926 THE SOFTWARE CONSTRUCTION PROCESS $28.3 28.3 STEPS AND TASKS The steps listed in the mini-lifecycle of each cluster are: Specification:identify the classes (data abstractions)of the cluster and their major features and constraints(yielding invariant clauses). Design:define the architecture of the classes and their relations. Implementation:finalize the classes,with all details added. Verification Validation:check that the cluster's classes perform satisfactorily (through static examination,testing and other techniques). Generalization:prepare for reuse (see below). Given the high-level of abstraction of the method,the distinction between design and implementation is not always clear-cut.So a variant of the model merges these two steps into one,.“design-implementation”, The need remains for two system-wide,cluster-independent phases.First,as with any other approach,you should perform a feasibility study,resulting in a go or no-go decision.Then,the project needs to be divided into clusters;this is,as noted,the responsibility of the project leader,who can of course rely on the help of other experienced team members. 28.4 THE CLUSTER MODEL OF THE SOFTWARE LIFECYCLE The general development scheme,known as the Cluster Model,appears on the facing page.The vertical axis represents the sequential component of the process:a step that appears lower than another will be executed after it.The horizontal direction reflects concurrent engineering:tasks at the same level can proceed in parallel. Various clusters,and various steps within each cluster,will proceed at their own pace depending on the difficulty of the task.The project leader is in charge of deciding when to start a new cluster or a new task. The result is to give the project leader the right combination of order and flexibility. Order because the definition of cluster tasks provides a control framework and control points against which to assess progress and delays(one of the most difficult aspects of project management);flexibility because you can buffer unexpected delays,or take advantage ofunexpectedly fast progress,by starting activities sooner or later.The project leader also controls the degree of concurrent engineering:for a small team,or in the early stages of a difficult project,there may be a small number of parallel clusters,or just one; for a larger team,or once the basic existential questions seems to be under control,you can start pursuing several clusters at once. Better than traditional approaches,the cluster model enables project leaders to do their job to its full extent,exerting their decision power to devote resources where they are needed the most
926 THE SOFTWARE CONSTRUCTION PROCESS §28.3 28.3 STEPS AND TASKS The steps listed in the mini-lifecycle of each cluster are: • Specification: identify the classes (data abstractions) of the cluster and their major features and constraints (yielding invariant clauses). • Design: define the architecture of the classes and their relations. • Implementation: finalize the classes, with all details added. • Verification & Validation: check that the cluster’s classes perform satisfactorily (through static examination, testing and other techniques). • Generalization: prepare for reuse (see below). Given the high-level of abstraction of the method, the distinction between design and implementation is not always clear-cut. So a variant of the model merges these two steps into one, “design-implementation”. The need remains for two system-wide, cluster-independent phases. First, as with any other approach, you should perform a feasibility study, resulting in a go or no-go decision. Then, the project needs to be divided into clusters; this is, as noted, the responsibility of the project leader, who can of course rely on the help of other experienced team members. 28.4 THE CLUSTER MODEL OF THE SOFTWARE LIFECYCLE The general development scheme, known as the Cluster Model, appears on the facing page. The vertical axis represents the sequential component of the process: a step that appears lower than another will be executed after it. The horizontal direction reflects concurrent engineering: tasks at the same level can proceed in parallel. Various clusters, and various steps within each cluster, will proceed at their own pace depending on the difficulty of the task. The project leader is in charge of deciding when to start a new cluster or a new task. The result is to give the project leader the right combination of order and flexibility. Order because the definition of cluster tasks provides a control framework and control points against which to assess progress and delays (one of the most difficult aspects of project management); flexibility because you can buffer unexpected delays, or take advantage of unexpectedly fast progress, by starting activities sooner or later. The project leader also controls the degree of concurrent engineering: for a small team, or in the early stages of a difficult project, there may be a small number of parallel clusters, or just one; for a larger team, or once the basic existential questions seems to be under control, you can start pursuing several clusters at once. Better than traditional approaches, the cluster model enables project leaders to do their job to its full extent, exerting their decision power to devote resources where they are needed the most
$28.4 THE CLUSTER MODEL OF THE SOFTWARE LIFECYCLE 927 The cluster FEASIBILITY STUDY model of the software lifecycle DIVISION INTO CLUSTERS Cluster 1 Specification Cluster 2 Design Specification Implemen tation Design Cluster n V&V Specification Generali- Implemen tation zation Design Implemen fation V&V VV Generali- Generali- zation zation TIME To avoid divergence,the current states of the various clusters'development must be regularly reconciled.This is the task of integration,best performed at preset intervals,for example once a week.It is the responsibility of the project leader,and ensures that atevery stage after start-up there will be a current demo,not necessarily up to date for all aspects of the system,but ready to be showed to whoever-customers,managers...-needs reassurance about the project's progress.This also serves to remove any inconsistency between clusters before it has had the opportunity to cause damage,reassuring the project members themselves that the pieces fit together and that the future system is taking shape. What makes possible the cluster model's form of concurrent engineering is the set of information hiding properties of the object-oriented method.Clusters may depend on each other,for example a graphical interface cluster may need,for remote display,classes of the communication cluster.Thanks to data abstraction,it is possible for a cluster to proceed even if the clusters on which it depends are not yet finished;it suffices that the specification phase of the needed classes be complete,so that you can proceed on the basis
§28.4 THE CLUSTER MODEL OF THE SOFTWARE LIFECYCLE 927 To avoid divergence, the current states of the various clusters’ development must be regularly reconciled. This is the task of integration, best performed at preset intervals, for example once a week. It is the responsibility of the project leader, and ensures that at every stage after start-up there will be a current demo, not necessarily up to date for all aspects of the system, but ready to be showed to whoever — customers, managers... — needs reassurance about the project’s progress. This also serves to remove any inconsistency between clusters before it has had the opportunity to cause damage, reassuring the project members themselves that the pieces fit together and that the future system is taking shape. What makes possible the cluster model’s form of concurrent engineering is the set of information hiding properties of the object-oriented method. Clusters may depend on each other; for example a graphical interface cluster may need, for remote display, classes of the communication cluster. Thanks to data abstraction, it is possible for a cluster to proceed even if the clusters on which it depends are not yet finished; it suffices that the specification phase of the needed classes be complete, so that you can proceed on the basis FEASIBILITY STUDY TIME Cluster 2 Cluster n Cluster 1 Generalization Implemen tation Design Specification V & V DIVISION INTO CLUSTERS Generalization Implemen tation Design Specification V & V Generalization Implemen tation Design Specification V & V The cluster model of the software lifecycle