The object-oriented systems life cycle

摘要: In software engineering, the traditional description of life cycle is based on an underlying model, commonly referred to as “waterfall” model (e.g., [4]). This initially attempts discretize identifiable activities within development process a linear series actions, each which must be completed before next commenced. Further refinements this appreciate that such completion seldom absolute and iteration back previous stage likely. Various authors' descriptions relate detailed level at building viewed. At most general level, three phases are generally agreed upon: 1) analysis, 2) design 3) construction/implementation [36], p. 262; [42]) (Figure 1(a)). The analysis phase covers from initiation project, through users-needs feasibility study (cf. [15]); various concepts system design, broad logical program physical design. Following stage(s), computer written, tested, in terms verification, validation sensitivity testing, when found acceptable, put into use then maintained well future.In more number subdivisions identified 1(b)). these varies between authors. general, problem first defined requirements current future users undertaken, usually by direct indirect questioning iterative discussion. Included should study. user definition specification, (SRS) [15], written. language so can upon both engineer user. specification written programmer details precise system. These two stages comprise answer question WHAT? (viz. definition). user-needs examination solution space still overall but beginning move toward not only decomposition, also highlighting likely subsequent design; thus HOW? On other hand, Davis [15] notes division “what” “how” subject individual perception, giving six different what/how interpretations example telephone stage, however, domain interest very much space. Not until we (real-world) systems (software) do 2). It important observe occurrence location interface. As noted Booth [6], provides useful framework object-oriented design.The perhaps loosely since it progressive decomposition detail [41]) essentially creative, mechanistic, [42]. Consequently, may “broad design” “detailed [20]. Brookes et al. [9] refer “logical “physical design.” become blurred iterative; boundary becomes even indistinct.The cycle, described above, frequently implemented view world interpreted functional decomposition; is, primary addressed WHAT does viz. what its function? Functional techniques used achieve this, interpretation translation interdependent set functions or procedures. final seen procedures which, apparently secondarily, operate data.Functional top-down methodology. Although synonymous, recently published methods exhibit characteristics [14, 17]) some add real-time component [44]). Top-down impose discipline analyst designer; yet criticized being too restrictive support contemporary engineering designs. Meyer [29] summarizes flaws follows: 1. takes no account evolutionary changes;2. characterized single function—a questionable concept;3. mindset, consequently data structure aspect often completely neglected;4. encourage reusability. (See discussion [41], 352 seq.)