|
 ABSTRACT
In software engineering, the traditional description of the software life cycle is based on an underlying model, commonly referred to as the “waterfall” model (e.g., [4]). This model initially attempts to discretize the identifiable activities within the software development process as a linear series of actions, each of which must be completed before the next is commenced. Further refinements to this model appreciate that such completion is seldom absolute and that iteration back to a previous stage is likely. Various authors' descriptions of this model relate to the detailed level at which the software building process is viewed. At the most general level, three phases to the life cycle are generally agreed upon: 1) analysis, 2) design and 3) construction/implementation (e.g., [36], p. 262; [42]) (Figure 1(a)). The analysis phase covers from the initiation of the project, through to users-needs analysis and feasibility study (cf. [15]); the design phase covers the various concepts of system design, broad design, logical design, detailed design, program design and physical design. Following from the design stage(s), the computer program is written, the program tested, in terms of verification, validation and sensitivity testing, and when found acceptable, put into use and then maintained well into the future.In the more detailed description of the life cycle a number of subdivisions are identified (Figure 1(b)). The number of these subdivisions varies between authors. In general, the problem is first defined and an analysis of the requirements of current and future users undertaken, usually by direct and indirect questioning and iterative discussion. Included in this stage should be a feasibility study. Following this a user requirements definition and a software requirements specification, (SRS) [15], are written. The users requirements definition is in the language of the users so that this can be agreed upon by both the software engineer and the software user. The software requirements specification is written in the language of the programmer and details the precise requirements of the system. These two stages comprise an answer to the question of WHAT? (viz. problem definition). The user-needs analysis stage and examination of the solution space are still within the overall phase of analysis but are beginning to move toward not only problem decomposition, but also highlighting concepts which are likely to be of use in the subsequent system design; thus beginning to answer the question HOW? On the other hand, Davis [15] notes that this division into “what” and “how” can be subject to individual perception, giving six different what/how interpretations of an example telephone system. At this requirements stage, however, the domain of interest is still very much that of the problem space. Not until we move from (real-world) systems analysis to (software) systems design do we move from the problem space to the solution space (Figure 2). It is important to observe the occurrence and location of this interface. As noted by Booth [6], this provides a useful framework in object-oriented analysis and design.The design stage is perhaps the most loosely defined since it is a phase of progressive decomposition toward more and more detail (e.g., [41]) and is essentially a creative, not a mechanistic, process [42]. Consequently, systems design may also be referred to as “broad design” and program design as “detailed design” [20]. Brookes et al. [9] refer to these phases as “logical design” and “physical design.” In the traditional life cycle these two design stages can become both blurred and iterative; but in the object-oriented life cycle the boundary becomes even more indistinct.The software life cycle, as described above, is frequently implemented based on a view of the world interpreted in terms of a functional decomposition; that is, the primary question addressed by the systems analysis and design is WHAT does the system do viz. what is its function? Functional design, and the functional decomposition techniques used to achieve this, is based on the interpretation of the problem space and its translation to solution space as an interdependent set of functions or procedures. The final system is seen as a set of procedures which, apparently secondarily, operate on data.Functional decomposition is also a top-down analysis and design methodology. Although the two are not synonymous, most of the recently published systems analysis and design methods exhibit both characteristics (e.g., [14, 17]) and some also add a real-time component (e.g., [44]). Top-down design does impose some discipline on the systems analyst and program designer; yet it can be criticized as being too restrictive to support contemporary software engineering designs. Meyer [29] summarizes the flaws in top-down system design as follows:
- 1. top-down design takes no account of evolutionary changes;
- 2. in top-down design, the system is characterized by a single function—a questionable concept;
- 3. top-down design is based on a functional mindset, and consequently the data structure aspect is often completely neglected;
- 4. top-down design does not encourage reusability. (See also discussion in [41], p. 352 et seq.)
REFERENCES
Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.
 |
1
|
|
| |
2
|
|
| |
3
|
|
| |
4
|
Boehm, B.W. Software engineering. IEEE 7~ans Comput. C-25, (1976), 1226-1241.
|
| |
5
|
|
| |
6
|
|
| |
7
|
Borgida, A. Greenspan, S. and Mylopoulos, J. Knowledge representation as a basis for requirements specification, IEEE Comput. 18, 4 (1985), 82-101.
|
| |
8
|
|
| |
9
|
Brookes, C.H.P., Grouse, P.J., Jeffery, D.R. and Lawrence, M.J. Information Systems Design. Prentice-Hall, Sydney, 1982, 477.
|
| |
10
|
|
| |
11
|
Carver, D.L. and Cordes, D.W. An objectoriented framework to support architectural design development, In Proceedings of Hawaii International Conference Systems Science, v II, IEEE, (Los Alamitos, CA, 1990) pp. 349-357.
|
| |
12
|
|
| |
13
|
Constantine, L.L. Object Oriented and Struc~ tured Design Seminar. Digital Consulting Pacific, 1989.
|
| |
14
|
Constantine, L.L. and Yourdon, E. Structured Design. Prentice-Hall, Englewood Cliffs, NJ, 1979.
|
| |
15
|
|
| |
16
|
|
| |
17
|
|
| |
18
|
|
| |
19
|
|
| |
20
|
|
| |
21
|
|
| |
22
|
|
| |
23
|
|
| |
24
|
|
| |
25
|
|
| |
26
|
|
| |
27
|
Malhotra, A., Thomas, J.C., Carroll, J.M. and Miller, L. Cognitive processes in design. J. Man-Mach. Studies 12, (1980), 119-140.
|
| |
28
|
Meyer, B. Bidding farewell to globals,J. Object Oriented Program./, 3 (1988), 73-76.
|
| |
29
|
|
| |
30
|
Meyer, B. From structured programming to object-oriented design: the road to Eiffel. Structured Programmin~ 1, (1989), 19 -39.
|
| |
31
|
Meyer, B. Programming as contracting, 2~ch. Not. TR-EI-12/CO, Version 2, Interactive Software Engineering, CA, 1989, 46.
|
| |
32
|
Meyer, B. The new culture of software development: reflections on the practice of object-oriented design, In Proceedings of TOOLS '89, (Paris, November 13-15, 13-23, 1989).
|
| |
33
|
|
| |
34
|
|
| |
35
|
|
| |
36
|
|
| |
37
|
|
| |
38
|
|
| |
39
|
|
| |
40
|
|
| |
41
|
|
| |
42
|
|
| |
43
|
|
| |
44
|
|
| |
45
|
|
| |
46
|
|
| |
47
|
R. Wirfs-Brock , B. Wilkerson, Object-oriented design: a responsibility-driven approach, Conference proceedings on Object-oriented programming systems, languages and applications, p.71-75, October 02-06, 1989, New Orleans, Louisiana, United States
|
CITED BY 46
|
|
|
|
|
|
|
|
|
|
|
Daniel Breugnot , Michel Gourgand , David Hill , Patrick Kellert, GAME: an object-oriented approach to computer animation in flexible manufacturing system modelling, Proceedings of the 24th annual symposium on Simulation, p.217-227, April 1991, New Orleans, Louisiana, United States
|
|
|
|
|
|
|
|
|
Hermann Kaindl , Karl Frank , Ivar Jacobson , Stephen Mellor , Joaquin Miller , Laura Hill, How difficult is the transition from OOA to OOD? (panel session), Addendum to the 2000 proceedings of the conference on Object-oriented programming, systems, languages, and applications (Addendum), p.11-12, January 2000, Minneapolis, Minnesota, United States
|
|
|
|
|
|
|
|
|
|
|
|
Oliver Stiemerling , Helge Kahler , Volker Wulf, How to make software softer—designing tailorable applications, Proceedings of the conference on Designing interactive systems: processes, practices, methods, and techniques, p.365-376, August 18-20, 1997, Amsterdam, The Netherlands
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Volker Wulf , Markus Rohde, Towards an integrated organization and technology development, Proceedings of the conference on Designing interactive systems: processes, practices, methods, & techniques, p.55-64, August 23-25, 1995, Ann Arbor, Michigan, United States
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
James D. Herbsleb , Helen Klein , Gary M. Olson , Hans Brunner , Judith S. Olson , Joe Harding, Object-oriented analysis and design in software project teams, Human-Computer Interaction, v.10 n.2, p.249-292, September 1995
|
|
|
|
REVIEW
"John J. Hirschfelder : Reviewer"
The authors describe an “object-oriented” approach to the design of data processing applications and explore the effect of this approach on the phases of a product life cycle. They suggest that the life cycle of such a system is sign
more...
|
Adobe Acrobat
QuickTime
Windows Media Player
Real Player
Pdf
D.2