Analyzing systems for object oriented design

ion and incremental development. A lack of data abstraction can induce a requirement to adhere to the waterfall model of system development. In fact, as soon as the first data flow diagram is constructed, a design decision has been made as to the eventual structure of the system under development. Some have tried to alleviate these problems by adding development phases for diagramming control flow and state transitions [10]. These improvements provide an attempt to partially bridge the gap between Structured Analysis and Object Oriented Design. The result, however, is typically not in the true spirit of Object Oriented Design. The objects within these designs are more created than derived from the real world. The basis of these conceptual objects may be found in system functionality rather than the reality which distinguishes true Object Oriented Design. This lack of substance may be due to the continued lack of front-end object analysis. There must be a better approach. THE JACKSON APPROACH A more effective analysis and design combination would incorporate an analysis method which is compatible with Object Oriented Design. This analysis method would base its analysis on the real world, as is an Object Oriented design. It would appropriately identify system components such that Object Oriented Design could reuse these components in the design. One method which bases its analysis on the real world is Jackson System Development (figure t) [3, 5]. A Jackson specification contains elements such as airplanes, ships, submarines, etc. to describe the reality of a system. These "entities", as they are called, correspond directly with objects. In his book "Software Engineering with Ada" [2], Grady Booch states: 'Keep in mind that objectoriented development is a partial life-cycle method; it focuses on the design and implementation phases of software development'. Mr. Booch continues : 'It is therefore necessary to couple object-oriented development with appropriate requirements and analysis methods in order to help create our model of reality. We have found Jackson Structured [sic] Development (JSD) to be a promising match'. The Jackson method consists of three stages, the modelling and analysis stage; the network stage and the implementation stage. The modelling stage analyzes the real world to identify "actions", "entities", data, and associated update logic. The entities are combined with their abstract data types to form "model process types" (Object classes). The network stage then includes the model process types along with additional functional processes in a network of communicating sequential process types, which represents the Jackson specification (figure 2). The specification has a high level of information hiding and concurrency [4]. Additionally, the actions identified by the Jackson analysis correspond with Object Oriented Design operations. Similarly, the entities identified by the Jackson analysis correspond directly with Object Oriented Design objects [1]. Since the processes identified in a Jackson specification require only local data, it is highly maintainable, supports incremental development, and distributed implementation [8]. These properties of the Jackson specification make it highly compatible with Object Oriented Design. The compatibility between the Object Oriented Design approach and the Jackson approach comes into fruition during the network and implementation stages of Jackson System Development (figure 3). During the network stage, it is necessary to populate the specification with functional process types. Object Oriented Design assists the developer especially in identifying various of the required functions, e.g. report functions and algorithmic functions. During this stage of the development, the Jackson method employs the use of bottom-up-components, in order to reduce the ambiguity and increase the conciseness of the specification. For example : matrix