University of Tennessee, Knoxville TRACE: Tennessee Research and Creative Exchange

The Harlan D. Mills Collection Science Alliance

1993

Box-Structured Methods for Systems-Development with Objects

Hevner A. R

Harlan D. Mills

Follow this and additional works at: https://trace.tennessee.edu/utk_harlan

Part of the Software Engineering Commons

Recommended Citation R, Hevner A. and Mills, Harlan D., "Box-Structured Methods for Systems-Development with Objects" (1993). The Harlan D. Mills Collection. https://trace.tennessee.edu/utk_harlan/452

This Article is brought to you for free and open access by the Science Alliance at TRACE: Tennessee Research and Creative Exchange. It has been accepted for inclusion in The Harlan D. Mills Collection by an authorized administrator of TRACE: Tennessee Research and Creative Exchange. For more information, please contact [email protected]. Box-structured methods for systems development with objects

by A. R. Hevner H. D. Mills

Box structures provide a rigorous and systematic velopment and objects can be integrated into a process for performing systems development formal development methodology. In this paper, with objects. Box structures represent data abstractions as objects in three system views we discuss the use of box structures as a bridge to and combine the advantages of structured support the integration of structured concepts development with the advantages of object and object-oriented concepts. orientation. As data abstractions become more complex, the box structure usage hierarchy Object orientation (i.e., the object-oriented ap­ allows stepwise refinement of the system design with referential transparency and verification proach) is receiving a great deal of attention as a at every step. An integrated development promising approach for the analysis and design of environment based on box structures supports complex information systems. For many system flexible object-based systems development applications, it is very natural to view the system patterns. We present a classic example of object­ based systems development using box environment as a collection of identifiable objects structures. that collaborate to achieve a desired behavior. Recent research and development in object ori­ entation has led to a number of methods and tech­ niques to support object-oriented systems devel­ opment. Three principal areas have been studied: object-oriented analysis, object-oriented design, ystem and software development organiza­ and object-oriented programming. Stions face difficult decisions when selecting development methodologies. Complex develop­ Object-oriented analysis (OOA) applies object ori­ ment projects require formal methods for the in­ entation to the initial stages of the systems de­ tellectual control of the process and the resulting velopment process, specifically the analysis of system product. After many years of striving to desired or existing system behavior. Prominent achieve the proven benefits of structured analysis works in this area include Bailin's use of objects and design methods (e.g., Structured Analysis for requirements specification, 4 Ward's exten­ and Structured Design, 1 Jackson System Devel­ sion of structured analysis to support objects, 5 2 3 opment, and Information Engineering ), devel­ Coad and Yourdon's comprehensive framework opment organizations must now consider the important advantages of object-oriented develop­ ©Copyright 1993 by International Business Machines Corpo­ ration. Copying in printed form for private use is permitted ment methods. without payment of royalty provided that (1) each reproduc­ tion is done without alteration and (2) the Journal reference We propose that the decision between structured and IBM copyright notice are included on the first page. The development methods and object-oriented meth­ title and abstract, but no other portions, of this paper may be copied or distributed royalty free without further permission ods is not a choice of one or the other. With the by computer-based and other information-service systems. right conceptual representations and develop­ Permission to republish any other portion of this paper must ment processes, the advantages of structured de- be obtained from the Editor.

232 HEVNER AND MILLS IBM SYSTEMS JOURNAL, VOL 32, NO 2, 1993 for understanding object-oriented analysis, 6 and summarize separate transactions that need to be Shlaer and Mellor's text on data modeling in ob­ identified in good object-oriented designs. 16 jects. 7 Second, there is no systematic means of intellec­ Object-oriented design (OOD) produces a formal tual control over the hierarchical growth of a com­ specification of the desired system behavior in plex system. There is little clear discipline or or­ terms of objects and their interactions. Various der to the discovery, design, and implementation graphical and syntactic representations have of objects. In particular, the discovery of embed­ been proposed to support an OOD system speci­ ded objects (i.e., objects within objects) and of fication. In addition, processes for developing inheritance opportunities is not addressed. and evolving the object-oriented designs have been defined. The best known OOD methods in­ Third, the approach depends on the heuristic in­ clude Booch's design method, 8 Seidewitz and vention of objects from a data flow perspective. Stark's method, 9 Meyer's approach for software There is no formal, mathematical basis for eval­ construction as defined in the Eiffel programming qating the correctness or quality of design deci­ system, 10 and Coad and Yourdon's methods. 11 sions. Object-oriented designs are often pre­ sented as faits accomplis from data flow diagrams Object-oriented programming (OOP) languages, skipping important analytic steps. In small prob­ such as Small talk, Object Pascal, C++, and CLOS lems, this may be possible. But in larger ones, it directly support the implementation of an object­ becomes difficult to determine if the leap was in­ oriented design. Other languages, such as Ada, spired or flawed. As complex as large problems provide limited support for certain object-ori­ are, and as numerous the design alternatives, it is ented features such as inheritance and are collec­ risky business to accept the discontinuity be­ tively named "object-based" languages. 12 tween data flows and object stimuli and responses without a lot of engineering analysis. A systematic process for object-oriented devel­ opment should provide a seamless development Finally, the design and implementation of the environment that supports the complete systems transformational functions that tie together ob­ development process. Recent research projects jects are left as exercises for the programmer have defined object-oriented system develop­ once the objects are completed. Programmers ment life-cycle processes, 13 including the object who are not involved in the design process may modeling technique from General Electric Co. 14 not understand the intentions of the design and and the responsibility driven design from Tek­ may produce an incorrect system implementa­ tronix, Inc. 15 tion.

In recent years development organizations have Many of these problems arise because of the made large investments in areas such as training widely held misconception that top-down func­ experience, and computer-aided software engi­ tional decomposition found in structured meth­ neering (CASE) tools for the support of structured ods is inappropriate and even contradictory to an development methods. The question arises as to object-oriented development process. Instead, it whether there is a way to integrate the advantages is our premise that, with the correct representa­ of object orientation in this existing development tions and techniques, the advantages of both sys­ infrastructure. Several proposals have been made tem decomposition and object composition can to use the structured analysis results from data be combined into a rigorous systems develop­ flow diagrams as a basis for object-oriented de- ment with object orientation. ign (e.g., see Reference 5). A number of prob­ lems exist with these proposals. What is needed is a comprehensive process framework and integrated environment to sup­ First, there is a serious gap between data flow port systems development with objects from ini­ ·agrams and object-oriented designs. Block di­ tial requirements analysis through system imple­ arns coalesce separate uses of system objects mentation. The objective of this paper is to · -o single nodes and coalesce the separate usage present box structures as integrating components :--"lations among the objects into single arcs be­ for object-based structured systems develop­ . ·een nodes. Thus, such diagrams irreversibly ment. Box structures support a rigorous, yet

- SYSTEMS JOURNAL, VOL 32, NO 2, 1993 HEVNER AND MILLS 233 practical, set of methods for the development of black boxes are expanded at the next level of the 1 18 systems. 6- Box structure methods have been system box structure usage hierarchy into state used successfully on numerous systems develop­ box and clear box forms. ment projects both internal and external to IBM. (See Reference 19 for examples.) This paper pre­ Box structures have underlying mathematical sents an overview of the box structure theory, foundations that permit the analysis and design to shows that box structures are, in fact, formal rep­ be applied to larger systems of arbitrary size. resentations of objects by demonstrating that box These foundations are based on sets and func­ structures support essential features of objects, tions that can be described in mathematical no­ and presents an integrated object-based systems tation for small systems or subsystems or in well­ development environment with box structures. structured natural language in a given context in Good use of box structure operations provides larger systems. In any case, a black box is defined the flexibility to perform needed systems devel­ by a mathematical function from histories of stim­ opment tasks. Finally, these ideas are applied, by uli to the next response. Let S be the set of pos­ means of an example, to the development of a sible stimuli, and R be the set of possible re­ classic Master File-Transaction File processing sponses of a system or subsystem. In illustration, system. an airlines reservation system, with many thou­ sands of concurrent users, will accept their stim­ Box structure theory uli sequentially into the system in real time and return responses accordingly. The black box Box-structured systems development is a step­ function, say f, will map historical sequences of wise refinement and verification process that pro­ such stimuli, in this case S*, to responses, R , duces a system design. Such a system design is shown in the form defined by a hierarchy of small design steps that permit the immediate verification of their correct­ ness. Three basic principles underlie the box­ f: S* ~ R structured design process: 16 The description of function f may be very com­ 1. All data to be defined and stored in the design plex for an airlines reservation system, but it is are hidden in data abstractions. still only a function. This description of the black 2. All processing is defined by sequential and con­ box assumes no data storage between stimuli, current uses of data abstractions. even though such storage may be known to exist, 3. Each use of a data abstraction in the system or be planned for development. occupies a distinct place in the usage hierarchy of the system. In a simple illustration, consider a stack object of integers, defined by a set of commands, say Box structure methods define a single data ab­ RESET, PUSH, POP, EMPTY?, and TOP?, whose straction in three forms in order to isolate the functions are easily inferred from the names. A creative design steps involved in building the ab­ stimulus is a command plus data, if required. For straction. The black box gives an external de­ example, a possible sequence of stimuli might be: scription of data abstraction behavior in terms of a mathematical function from stimulus histories RESET, EMPTY?, PUSH 17, PUSH 31, POP, TOP?, to responses. The black box is the most abstract description of system behavior and can be con­ PUSH 11, . .. sidered as a requirements statement for the sys­ tem or subsystem. The state box includes a de­ signed state and an internal black box that The responses for the stimulus histories returning transforms the stimulus and an initial state into data are: the response and a new state. The state is de­ signed from an analysis of the required stimulus RESET, EMPTY? ~ yes histories and responses for the system. Finally, the clear box replaces the internal black box with RESET, EMPTY?, PUSH 17, PUSH 31, POP, the designed sequential or concurrent usage of other black boxes as subsystems. These new TOP?~ 17

234 HEVNER AN D MILLS IBM SYSTEMS JOURNAL, VO L 32, NO 2, 1993

...__ Although a data stack can be readily imagined, been designed into a state box, say (t,g), the cor­ the responses can be determined by examining rectness of (t,g) can be verified by comparing its only the stimulus histories, as above. behavior, say k, to the intended behavior f.

The state box of a system or subsystem expands Continuing, a state box can be expanded into a the black box by identifying data at this system clear box by replacing the internal data abstrac­ level to be stored between stimuli so that only a tion with a procedural structure of new data ab­ current stimulus is required, but not previous his­ stractions in either sequential or concurrent logic. tory. LetT be a set of possible data states at the Sequential structures may involve simple se­ top level, and lett be the initial state of the system quence, alternation, or iteration whose semantics or subsystem. As noted above, the state box con­ are well known from sequential programming. tains an internal data abstraction that is defined Since sequential programs are rules for mathe­ by another black box, say g. In this case, the matical functions, from initial states to final states internal black box has a compound stimulus con­ of computation, a clear box in sequential struc­ sisting of the external stimulus and the internal tures defines the functional behavior in terms of state, and a compound response consisting of the the next level black boxes. Concurrent structures external response and the new internal state. That require more analysis and discipline in use be­ is, g has the form cause of their potential complexities. g: (S X T)* ~ (R X T) Such a procedural structure of data abstractions can also be eliminated to produce the effect of a Then, each pair (t,g) of an initial state and an single internal data abstraction and the state, in internal black box function will uniquely define much the same way as the state was eliminated to the behavior of the system. Note that the internal derive a black box. Sequence and alternation data abstraction will be capable of maintaining structures are eliminated by function composition more deeply stored data, with the internal black and disjoint union directly. Iteration structures box using its compound stimulus histories. can be reformulated as noniterative decision structures or recursive structures. 20 Again, con­ To continue the stack illustration, consider the current structures require more specific treat­ state to be a list of integers, with the initial state ment. In this way, clear box designs can be ver­ being the empty list. Then the commands RESET, ified against state box specifications, as well. PUSH, POP, EMPTY?, and TOP? are functions from the stimuli and state resulting in a response and Figure 1 shows the relationships among the three new state. For example, the sequence of stimuli views of a single data abstraction. The creative above will produce states as well as responses as design steps, along the right side of the figure, are follows: called expansions. The design verification steps, along the left side of the figure, are called deri­ (RESET, ( )) ~ (null, ( )) vations. A given black box can be expanded into (EMPTY?, ( ) ) ~(yes, ( )) many correct state box designs. Conversely, a state box will define a unique black box by der­ (PUSH 17, ( )) ~(null, (17)) ivation. Also, a given state box can be expanded into many correct clear box designs, and con­ (PUSH 31, (17)) ~ (null, (31, 17)) versely, a clear box will define a unique state box POP, (31, 17)) ~(null, (17)) by derivation.

TOP?, (17)) ~ (17, (17)) In order to gain intellectual control over the de­ PUSH 11, (17)) ~(null, (11, 17)) velopment of a complex system, it is necessary to be able to decompose the system into smaller, '="urthermore, all intermediate states of this state more manageable parts. A box structure usage x can be eliminated by mathematical substitu­ hierarchy represents the use of black box abstrac­ ·on to derive a black box function, say k, in tions in a higher-level clear box abstraction. A ·ch the initial state will serve as a parameter. usage hierarchy of abstractions provides referen­ ~ us, whenever a specified black box, say f, has tial transparency among all black boxes within a

- SYSTEMS JOURNAL, VOL 32, NO 2, 1993 HEVN ER AND MILLS 235 Figure 1 Box structure expansion and derivation

-· BlACK BOX STIMULUS ·I .. .. :I . RESPONSE

ELIMINATE INTRODUCE STATE STATE STATE BOX

~----1 STATE ~--~ I I I I I I I I I I r..!~ STIMULUS ' RESPONSE I ELIMINATE INTRODUCE PROCEDURE PROCEDURE CLEAR BOX

~------~ ].------~ I I BLACKBOX I : I I RESPONSE STIMULUS----+.. +~ ·c ~: u L-'-'--"---'-----'---' 1 1

I• •••••••••• •I CREATIVE DESIGN STEPS (EXPANSIONS) I . . -1 DESIGN VERIFICATION STEPS (DER IVATIONS) STIMULUS RESPONSE FLOW ______SYSTEM STATE FLOW

clear box. 21 Thus, each black box in a clear box higher level in the usage hierarchy. The black box can be designed independently of the others. is then logically independent of the rest of the system, and can be designed to satisfy a well­ The effective use of box structures for the devel­ defined behavior specification. The principle of opment of information systems is guided by the referential transparency provides a crisp disci­ use of four basic box structure principles: refer­ pline for management delegation and assignment ential transparency, transaction closure, state mi­ of responsibility. gration, and common services. We briefly define each of these principles. Transaction closure-The principle of transac­ tion closure defines a systematic, iterative spec­ Referential transparency-Referential transpar­ ification process to ensure that a sound and com­ ency occurs when a black box abstraction is com­ plete set of transactions is identified to achieve pletely defined within the clear box at the next the required system behavior. The closure pro-

236 HEVNER AND MILLS IBM SYSTEMS JOURNAL, VOL 32, NO 2, 1993 cess can be performed at each box structure view ior, and identity." 8 A collection of objects that of an object abstraction. At the black box, checks have a common behavior and structure is termed are performed to ensure that the system stimuli an object class. Booch establishes four major and are necessary and sufficient to generate the re­ three minor elements of any object-oriented mod­ quired system responses. At the state box, the el. 8 The four major (i.e., essential) elements are defined transactions must be necessary and suf­ abstraction, encapsulation, modularity, and hier­ ficient for the acquisition and preservation of all archy. The three minor (i. e., useful, but not es­ state data, and the state data must be necessary sential) elements are typing, concurrency, and and sufficient for the completion of all transac­ persistence. tions. At the clear box, the procedural design and the internal black boxes must include all trans­ An object-oriented systems development process actions. must support all major object elements and should support the minor object elements as ap­ State migration-State data should be identified propriate for its application environment. In this and stored in the system part (i.e., data abstrac­ section, we demonstrate that the box structure tion) at the lowest level in the box structure hi­ theory incorporates the essential elements of the erarchy that includes all references to those data. object model. We also discuss the box structure At any time in the systems development process, approaches for supporting other useful elements state data can be migrated upward or downward of the object concept. in the hierarchy in order to achieve some system objective, such as minimizing data scope. 22 State Essential object-oriented elements. We now briefly migration must be performed carefully in order to show that box structures provide the concepts of maintain the consistency and mathematical cor­ abstraction, encapsulation, modularity, and hier­ rectness of data abstractions throughout the hi­ archy. erarchy. Abstraction. An object is an abstract representa­ Common services-A common service is a data tion of an entity in the problem domain. Much abstraction that is described in a separate box creative skill and experience are needed to iden­ structure hierarchy, and used in other box-struc­ tify and design a good set of system objects and tured systems. System parts with multiple uses classes. Box structures provide an excellent set of should be defined as common services for reus­ abstraction capabilities for system description. ability. Also, predefined common services, such During analysis, a potential object can be defined as database management systems and input/out­ and studied in any of the three box structure put interfaces, should be used to advantage views. In particular, the black box view gives the throughout the box-structured system. The ad­ external, design-free system behavior that pro­ vantages of reusable common services for sys­ vides the essence of a system abstraction. 25 The tems development are obvious. Box structures state box views the object as a data abstraction directly support the identification and reuse of with the state visible. Within the clear box view common services within and among systems. complex object abstractions can be rigorously de­ composed into simpler objects and simple objects More complete descriptions of box structure the­ can be grouped into larger objects. ory and principles can be found in References 16-18. During top-down design, the box structure usage hierarchy provides a framework in which to cap­ Box structures as objects ture multiple levels of system abstraction in a con­ trolled manner. All system design units, from the Similar to box structures, the object concept can top-level complete system to the smallest sub­ be seen as an extension of abstract data types in system components, and even down to simple 23 24 programming languages. • A precise mathemat­ variables, are viewed and described as box struc­ ical definition of an object has not been widely ture objects. Throughout the hierarchy, the abil­ accepted or used. An object can be informally ity to manage abstraction applies to all system defined as a unique unit of information and de­ components; stimulus (i.e., input), responses scriptions of its manipulations. More concisely, (i.e., outputs), state (i.e., internal data), and pro­ Booch defines an object as having "state, behav- cedures.

- SYSTEMS JOURNAL, VOL 32, NO 2, 1993 HEVNER AND MILLS 237 The ability to handle abstractions is also impor­ of both system decomposition and object com­ tant for the reverse engineering of existing sys­ position. Top-down system decomposition en­ tems. Bottom-up system analysis abstracts func­ ables an essential intellectual control in develop­ tionality (i.e., black box behavior) from system ment. The system grows one level at a time. The implementation details of procedure and state. mathematical structuring of systems in usage hi­ The application of box structure theory to system erarchies of objects allows formal verification reverse engineering is presented in Reference 26. methods to be used. Also, the referential trans­ parency of objects in a clear box provides an es­ Encapsulation. Encapsulation, also known as in­ sential modularity and design independence to formation hiding, is supported by the state box each object. and clear box views of a box structure object. The state of an object and the procedural operations In addition, in this framework of a usage hierar­ on that state are hidden within the box structure chy, the advantages of object composition come as design constructs. The essential behavioral ab­ into play. An object requirement, stated as a straction, or interface, of the object is described black box, can be matched with existing object by the black box view. classes stored for reuse in a repository. During the systems analysis phase the benefits and costs An extension to object encapsulation can be of object reuse and modification can be studied. found in the box structure principle of state mi­ Another opportunity for object composition gration. As box structure objects are decomposed arises during the design of the clear box. Knowl­ and composed in a usage hierarchy, opportunities edge of existing object classes or insight into de­ for state migration may exist. Beneficial state mi­ sired object classes will influence the designer's grations provide insights into new class inheri­ invention of data abstractions as black boxes at tance structures. Upward migration of state can the next level in the object hierarchy. identify new superclass structures and downward migration of state can identify new subclass struc­ As an object is used in the system usage hierar­ tures. chy, it carries with it a description of its inherent behavior as defined in an inheritance hierarchy. Modularity. Modularity in systems development Inheritance is a fundamental aspect of object ori­ involves dividing the complete system into man­ entation. Inheritance is the means by which one ageable units of analysis, design, and implemen­ object class, the subclass, inherits the informa­ tation. Each system module must be internally tion and operations of another object class, the cohesive and loosely connected to the other mod­ superclass. The subclass can then be modified by ules of the system. 8 adding or deleting information or operations of its Modularity is one of the major strengths of the own. box structure development process. The princi­ ple of referential transparency throughout the box Inheritance is exhibited in the box structure de­ structure usage hierarchy provides module inde­ velopment process by building new classes from pendence for all box structures in the system de­ existing classes during systems development. Af­ sign. Furthermore, referential transparency ap­ ter an object has been instantiated in a system plies to both object decomposition and object design, the designer has the freedom to modify composition in the systems development process, the object design by altering the state design of as discussed in the next section on hierarchy. the state box (e.g., via state migration) and the procedural design of the clear box. If the modified Hierarchy. The concept of a system hierarchy is object is designated for reuse, then a choice can an essential component for systems develop­ be made as to its representation in the reuse re­ ment. Box-structured systems development with pository. The new object class, from black box to objects utilizes two distinct types of hierarchy: clear box, can be stored as a unit or the new sub­ usage hierarchies to describe system behavior class can be stored as a set of modifications with and inheritance hierarchies to describe object be­ a pointer to the existing superclass. Thus, an in­ havior via inheritance. heritance hierarchy can be developed of object classes. The physical structure of the hierarchy is A usage hierarchy of box structures is con­ a representation issue based upon an optimization structed during system design by the application of the reuse repository. Thus, an object is defined

238 HEVNER AND MILLS IBM SYSTEMS JOURNAL, VOL 32, NO 2, 1993

~ ~ ~~ ~- and stored in the form of a generic common ser­ within and among systems has the potential to vice. 27 significantly raise the productivity of systems de­ velopment and the certified quality of systems. Important object-based features. Based upon the Box structure methods support a high level of fact that the box structure theory supports the object reuse. four essential elements of Booch's object model, we conclude that box structures support object­ In a top-down manner, each object in the system based systems development. In fact, box struc­ hierarchy is stored in its three box structure views tures provide important extensions for systems in a systems development repository. Certain of development with objects. These extensions in­ these objects, usually the smaller objects at lower clude the isolation and verifiability of all creative levels in the hierarchy, can be selected for future design steps in small units and systematic expan­ reuse. Objects are stored in the form of their in­ sion of the design in a top-down hierarchy for heritance hierarchies. Special design require­ intellectual design control. Thus, there is no need ments are imposed on the objects, such as inter­ to develop transformational functions to tie ob­ face standards, documentation standards, and jects together, as is required in some traditional 28 certification requirements. These reusable ob­ object-oriented design methods. jects are migrated to large organizational reposi­ tories as object classes for potential reuse across Next we discuss several important features of all development projects. By including all three box-structured development methods, to include box views of the object in the reuse repository, a Booch's minor elements of typing, concurrency, verified design trail of the object from require­ and persistence, as well as reuse and object rep­ ment to detailed design is available for evaluation resentations. and use during reuse decisions. Typing. The typing of an object identifies the ob­ ject as a member of a specific class with all in­ During design, reuse decisions are made for a herent states and behaviors. Object typing en­ given black box requirement. It may be possible sures that differently typed objects may interact to find a reusable object type in the reuse repos­ only in very restricted ways. The support in var­ itory that meets the requirement. (Current re­ ious OOP languages for typing ranges from weak search on repository structures and access meth­ enforcement to strong enforcement. The box ods for reuse is reported in Reference 33.) We structure syntax does not specifically enforce recognize several forms of object instantiation for strong typing in design specifications. reuse during a systems development.

Concurrency. We believe that the ability to ana­ An organization-wide object instantiation would lyze and design concurrent structures is essential encapsulate information and operations used by for realistic systems development. The clear box many systems. Such objects would include data­ structure provides the means to model the con­ base and file management systems, common user current behavior of black box objects. We have interfaces, and sensors that maintain the state of defined analysis and design methods to optimize physical properties (e.g., temperature, pressure). the use of concurrency in system specifications. 29 A system-wide object instantiation would encap­ However, many difficult questions remain to be sulate information (e.g., data types and con­ explored. stants) and operations used in several different places in the system usage hierarchy, but not out­ Persistence. Persistence through time and space side of the system. Examples would include com­ · embedded in the organization-wide common monly used data structures and their operations services as discussed in the next section on reuse. (e.g., files, stacks, queues) and monitors for crit­ The use or reuse of persistent common services, ical sections of the system. A one-time object in­ such as object-oriented database management stantiation would allow reuse of information and systems, allows data and procedures to be shared operations without information sharing. This 30 31 - oss many system boundaries. • would be beneficial primarily for reusing existing program code. The first two forms of object in­ ;reuse. Reuse is a fundamental concept in object­ stantiations are examples of box structure com­ ·ented development. 32 The reuse of objects mon services.

- SYSTEMS JOURNAL, VOL 32, NO 2, 1993 HEVN ER AN D MILLS 239 Table 1 The 16 box structure operations we describe the 16 operations and discuss several important patterns of object-based development. 1. Requirements determination 2. Black box definition 3. Black box analysis Each of the box structure operations shown in 4. Black box requirements review Table 1 is atomic, accepting stimuli from and pro­ 5. State box expansion ducing responses to the system developer and the 6. State box analysis systems development repositories. At any point 7. Black box derivation in systems development or systems evolution, an 8. Clear box expansion 9. Clear box analysis operation can be performed as needed as long as 10. State box derivation the stimuli for it are available. It is incumbent 11. Stepwise system decomposition upon the system developer to put the operations 12. System implementation to "good use" in the development process. Nat­ 13 . System operations 14. System analysis ural groupings of the operations are exploited in 15. System box structure description good-use patterns. The box structures that un­ 16. Stepwise system abstraction derlie all of the operations provide the essential formalism and integration required for rigorous systems development. We next briefly describe the objectives of each of the operations. Object representation languages. The search for appropriate languages for object-oriented devel­ 1. Requirements detennination involves a series opment has led to graphics-based aids such as 34 8 of investigation activities in which system re­ Small talk icons and Booch diagrams, and syn­ quirements are specified. The information is gath­ tactical forms such as Ada program description 35 ered via techniques such as user interviews, ques­ languages (PDLs). Box structures have both a tionnaires, documentation review, and analysis graphic notation and a syntactic notation, that be­ 17 of existing applications. The gathered require­ ing the box description language (BDL). While ments information is represented in box structure graphics may be appropriate for small system de­ formats. signs and high-level presentations, we see no al­ ternative for the use of a syntactically complete 2. The black box of the system is completely de­ design language for large-scale object-oriented fined (black box definition) based on the require­ development of systems. The use of the Z nota­ ments for the system. The black box is described tion has also been used to represent box-struc­ by its stimuli, responses, and the transactions that tured designs. 36 map stimulus histories into responses.

An integrated box-structured environment 3. Black box analysis evaluates the quality and for systems development with objects completeness of the black box specification. For Box structures and the box structure usage hier­ example, transaction closure would ensure that archy provide the common, unifying concepts for all stimuli are necessary and sufficient in the sys­ achieving a truly integrated object-based devel­ tem. opment environment. No artificial bridges and transformation procedures are needed to ex­ 4. The defined black box is reviewed (black box change information among development activi­ requirements review) to determine whether it ties. We have defined 16 fundamental box struc­ truly represents the desired system requirements. ture operations (see Table 1) and show these in a The review involves the customers, users, and schematic structure of an integrated development managers of the system. environment (see Figure 2). These operations, used and reused in various patterns, contain all 5. The state of the system is created (state box the required processing needed to perform all ac­ expansion) by encapsulating required stimulus tivities in object-based systems development. history in a state box. Data design methods, such The box structure information is stored in well­ as entity-relationship models, are used to create defined box structure formats, box structure a state design. An internal data abstraction is de­ graphics, and the box description language in sys­ signed to map stimuli and state into responses and tems development repositories. In this section, new state.

240 HEVNER AND MILLS IBM SYSTEMS JOURNAL, VOL 32, NO 2, 1993 ~-~~& ~~- ~~ --- ......

Figure 2 A schematic structure of an integrated development environment

REQUIREMENTS DETERMINATION

BLACKBOX ( BLACKBOX REQUIREMENTS DEFINITION REVIEW )

BLACK BOX STATE BOX :2 DERIVATION UJZ EXPANSION ~Q >-t:: ( STATE BOX (/)(f) UJO ANALYSIS (/)Cl. ~~ [Du STATE BOX CLEAR BOX f-UJ DERIVATION ( EXPANSION (/)Q CLEAR BOX ANALYSIS STEPWISE SYSTEM STEPWISE SYSTEM ABSTRACTION DECOMPOSITION

PROCEDURES (SYSTEM)

SYSTEM BOX STRUCTURE SYSTEM SYSTEM DESCRIPTION ANALYSIS /-IMPLEMENTATTEM ION OPERATIONS

6. State box analysis evaluates the quality and the next level of design are identified. The intel­ completeness of the state box design. The prin­ lectual control of stepwise system decomposition ciples of transaction closure and state migration is contained in this operation. are applied. Data design metrics, such as level of data normalization, are used to evaluate the qual­ 9. Clear box analysis evaluates the quality and ity of the design decisions. completeness of the clear box design. The prin­ ciples of transaction closure, state migration, and 7. The black box derivation operation discovers common services are applied. Design metrics of the black box representation of a given state box. structured programming can be used to study the A state box can be verified as correct by deriving clear box procedural design. an equivalent black box and comparing it to the original black box requirement. 10. The state box derivation operation discovers the state box representation of a given clear box. 8. Clear box expansion is a creative step whose A clear box can be verified as correct by deriving purpose is to design the procedural structure of an equivalent state box and comparing it to the the system. The uses of black box subsystems at original state box.

3M SYSTEMS JOURNAL, VOL 32, NO 2, 1993 HEVNER AND MILLS 241 11. The stepwise system decomposition operation cess continues until the complete system is de­ continues the system design in a top-down man­ scribed and understood at the top-level behavior. ner by recursively applying the above operations This operation is the basis of the reverse engi­ to each black box at the next level of the box neering of existing systems as presented in Ref­ structure usage hierarchy. Common service box erence 26. structures are identified and developed separately from the application system usage hierarchy. The integrated systems development environ­ ment for box structures would include support for 12. System implementation accepts the design the 16 box structure operations and a common specification in the form of a box structure usage and controlled repository for storing box struc­ hierarchy and provides the capabilities and re­ ture information. With the flexibility of being able sources to implement it. Implementation may be to perform any of these operations at any time an integration of hardware, software, and human during systems development, the developer is no behavior. Implementation objectives are to build longer bound by a rigid systems development life­ and optimize the specified system and to prepare cycle paradigm. However, a discipline is still users and operators for its operation and mainte­ needed for the good use of the operations toward nance. a well-defined systems goal.

13. Activities during system operations include The use of box structures can be adapted to any maintenance, performance monitoring, integrity development situation in a flexible way by defin­ control, operations assurance, and system evo­ ing good-use patterns of operations. These pat­ lution. Box structures provide a rigorous and terns would be placed under strict management common means of understanding and controlling control and adapted dynamically to changing cir­ the system during operation. cumstances in the on-going systems develop­ ment. Each box structure operation in the pattern 14. For an existing system, system analysis is an has well-defined completion criteria, allowing im­ investigation activity to support a better under­ mediate validation of the success or failure of any standing of system behavior. Operational system particular step in the development. In addition, metrics, such as performance, reliability, avail­ since the creative invention operations (i.e., state ability, etc., are computed and used to evaluate box expansion and clear box expansion) are self­ the quality and completeness of the system. In­ contained, it is easy to track and document the formation is gathered from interviews and docu­ critical design decisions in the system. mentation reviews to better understand system behavior. This information is stored in a reposi­ To illustrate, consider the following examples of tory. good-use patterns of box structure operations. For conciseness, we refer to the operations using 15. An existing system can be described in box their numbers as defined in Table 1. structure representations to support further rig­ orous analysis and reverse engineering. Our goal Object description example. The description of an is to enhance system understanding by describing object would begin from the discovery of the ob­ the system (system box structure description) as ject and a thorough requirements determination a usage hierarchy of referentially transparent (operation 1). The object would be designed as clear boxes. Methods for transforming natural part of an existing inheritance hierarchy (i.e., procedures into clear box formats are presented common service) or would initiate a new inheri­ in Reference 17. tance hierarchy. In either case, the design of the object would proceed through defining the black 16. The stepwise system abstraction operation box, state box, and clear box views (operations builds an increasingly abstract description of an 2-10). Subclasses of the object are defined using existing system in a recursive, bottom-up fashion. recursive application of these operations in the Detailed clear box descriptions of subsystems are inheritance hierarchy (operation 11). derived to state box and black box representa­ tions. These subsystems are then represented as New system development example. The develop­ black boxes within procedural clear boxes at the ment of a system from the beginning would start next higher level of system description. This pro- from extensive requirements determination (op-

242 HEVNER AND MILLS IBM SYSTEMS JOURNAL, VOL 32, NO 2, 1993 . ,,., __-.-. . ~ ,.,. . · ~

eration 1) and proceed recursively through the vious section to build a good-use pattern of box top-down construction (operations 2-11) of the structure operations for the object-based devel­ box structure usage hierarchy of the system de­ opment of a system. We propose an object-based sign. Finally, the system would be implemented systems development process that consists of five (operation 12) and brought into operation (oper­ phases. The order of performance of the phases ation 13). While this pattern of operations is op­ during a system development is based on the spi­ timistically possible, it is rare in practice. New ral paradigm in which the next phase of develop­ system development will require many iterations ment is determined by the results of the previous of requirements determination, box structure phases. 18 This requires definite result milestones analysis (to include reuse analysis), box structure and strict management control of the develop­ design, and system implementation. The flexibil­ ment process. The development phases follow. ity to dynamically select and perform the opera­ tion needed next is of great benefit. Problem definition-A clear problem statement must be generated to provide a basis for systems Reverse engineering of systems example. Reverse development. Extensive domain analysis is es­ engineering is defined as "the process of analyz­ sential for complete problem understanding. ing a subject system to identify the system's com­ ponents and interrelationships and to create rep­ Requirements definition-Requirements are elic­ resentations of the system in another form or at a ited from the system domain experts and system higher level of abstraction." 37 A pattern of oper­ users. The requirements are represented in for­ ations to support reverse engineering would be mats that facilitate review and feedback. defined by the application of system analysis and system box structure description (operations 14 Systems analysis-The system requirements are and 15). Then stepwise system abstraction would analyzed and information is gathered to support be performed as a recursive pattern of analyses subsequent design decisions. The discovery of and derivations (analysis operations 3, 6, and 9, relevant, reusable objects is an important part of derivation operations 7 and 10). systems analysis.

Prototyping example. A prototype is a limited ver­ Systems design and verification-Definitive de­ sion of a system built to provide requirements and sign decisions are made and the system design is operations information. Prototypes can range in grown via top-down functional decomposition in scope from a simple study to see if software pack­ a usage hierarchy. Each creative design step is ages can exchange data correctly to a large-scale verified to be a correct expansion of the existing prototype of the complete system. Once the de­ design. cision is made to prototype a portion of a system, the prototype development takes on an indepen­ Systems implementation-The system design is dent existence of its own. The pattern of box transformed into an operational system. The final structure operations would be similar to the pat­ system will be a combination of hardware, soft­ tern for developing a new system. However, not ware, firmware, and human behavior compo­ all branches of the box structure usage hierarchy nents. The boundaries and interfaces among would be completed. Only the portions of the sys­ these components must be specified in the final tem to be studied would be designed and imple­ system design. mented. By developing the design with the usage hierarchy, referential transparency of all system Our emphasis in this section is to detail the pro­ parts in the prototype is maintained. This sup­ cessing found in the middle three phases and to ports the ability to make use of these prototype demonstrate the inherent object basis of the box subsystems in the design and implementation of structure development process. The phases of re­ the desired final system. quirements definition, systems analysis, and sys­ tems design and verification will be performed as The box-structured systems development a tightly-integrated, iterative process. The ability process to achieve this tight integration comes about be­ cause of the unifying box structure concepts and In this section, we apply the integrated systems representations. (We use the term "box struc­ development environment discussed in the pre- ture" to refer to a component in the system hi-

SYSTEMS JOURNAL, VOL 32, NO 2, 1993 HEVNER AND MILLS 243 erarchy; however, the term "object" could be sign constraints. This box structure requirement used with equivalent meaning.) is stored in a repository as the initial definition of the system object. Requirements definition. The input into the re­ quirements definition phase is a complete prob­ Systems analysis. Analysis tasks are performed to lem statement, typically presented as a structured support the decisions that must be made during English document. Investigation tasks are per­ systems design. These tasks are performed as formed in order to precisely determine the re­ part of the creative state box expansion and clear quirements of a system that solves the presented box expansion structure operations. The box problem. Note that the requirements definition structure requirement is analyzed and informa­ phase is performed for each box structure in the tion is gathered to support one or more feasibility, usage hierarchy. reuse, prototpye, or tradeoff types of activities.

Requirements for any level of system object can Feasibility studies are performed to determine the be represented in a box structure format. The ul­ feasibility and cost versus the benefit of potential timate goal would be to state all requirements in designs. Reuse opportunities are explored in sev­ a state-free, procedure-free black box. Defining eral ways. Repositories of system objects from requirements solely as a black box places no con­ the current project or existing systems will be in­ straints on the eventual design. The first four box vestigated for requirements matching. The cost structure operations (requirements determina­ and benefit of reusing existing objects, along with tion, black box definition, black box analysis, and any required modifications, would be deter­ black box requirements review) are performed it­ mined. Prototyping is performed to evaluate de­ eratively during this phase. sign alternatives. The prototype development process will progress independently from other The transactions in a black box are defined as design activities with the five development phases mathematical functions for deterministic behav­ performed in an iterative manner. Objects devel­ ior or mathematical relations for nondeterministic oped in the prototype may be candidates for reuse behavior. For high-level, complex box structures and modification in the final system. Tradeoff it may be necessary to provide the function or studies are used to determine the advantages and relation in the natural language of the problem disadvantages of designing and implementing the domain, often a mixture of formal and informal current box structure as hardware, software, language. Whatever the notation, the black box firmware, human behavior, or some combination description is a set of mathematical functions, one thereof. Such decisions will impact reuse oppor­ per transaction. tunities and interface designs. Finally, the reuse potential of the current box structure should be Often system requirements do contain design analyzed. If the decision is made to design the box constraints on such things as the availability and structure as a reusable object, then reuse stan­ use of data or the need to conform to a defined dards may dictate certain design decisions (e.g., procedure. Such requirements cannot be re­ interface standards). corded in a black box; thus, a clear statement of state box and clear box design constraints must The above types of analyses are essential to sup­ be provided. In addition, certain "nonfunctional" port high-quality system designs. The informa­ requirements, such as performance and docu­ tion, analysis, and conclusions of these studies mentation standards, can be stated in structured are recorded with the evolving box structure in English forms. It is important during requirement the system repository. Some analysis discoveries reviews that the system owners understand that may cause changes in the system requirements, any requirements beyond a black box are con­ thus, iteration between the phases of require­ straints upon the design freedom for the system. ments definition and systems analysis is to be ex­ In this process, many nonessential "require­ pected and encouraged. ments" can be discovered and eliminated. Systems design and verification. In this phase the The results of the requirements definition phase box structure requirement and the analysis re­ are a precisely defined black box with accompa­ sults are used to produce a complete design spec­ nying state box, clear box, and nonfunctional de- ification of the box structure. This phase encom-

244 HEVNER AND MILLS IBM SYSTEMS JOURNAL, VO L 32, NO 2, 1993 passes operations 5 through 11 of the integrated action, a record is added to a transaction file with box structure environment. attributes of part identification (PARTID), action (ACTION), and quantity (QTY), where ACTION has First the state box is designed from the black box the values of "in" or "out." The system transfers requirement specification using the state box ex­ the transactions to the master file at the end of pansion, state box analysis, and black box deri­ vation operations. The completed and verified state box is stored in the repository. The clear box then can be designed using the clear box expan­ sion, clear box analysis, and state box derivation operations. A classic example The design and verification of the clear box com­ illustrates the application pletes the detailed design of the current box struc­ of object-based systems ture. The complete specification of the box struc­ development. ture object, from the black box requirement, through the intermediate state box, to the final clear box design, is stored in the system reposi­ tory. Finally, the stepwise system decomposition operation is used to build the complete system in a top-down manner. each day. A management control report is pro­ duced showing the disposition of each transaction The procedural clear box design, developed in the record and its effect on the master file . clear box expansion operation, ensures that each internal black box is referentially transparent We develop the top level of this system using a from all other peer black boxes and common serv­ box structure box description language notation ices in the clear box. Thus, each black box can be similar to typical program description languages designed independently. For each black box re­ (PDL) , and it should be self-explanatory. quirement the development process of require­ ments definition, systems analysis, and systems design and verification begins. Note that much of Requirements definition. We begin by listing all the work performed (and dutifully recorded in the of the stimuli and responses of the desired repository) for higher-level box structures in the INVENTORY system. They are: hierarchy can be used in the analysis and design of lower-level box structures. The desired system Stimuli Transaction file and master file is complete when no further black box require­ Responses Updated master file and manage­ ments exist in the leaves of the box structure us­ ment report age hierarchy. The detailed design of the com­ plete system is then sent to the final phase of The discovery of system requirements should systems implementation. point out omissions and needed extensions of the problem statement. For example, what are the correct actions to be taken when unusual or er­ The design of a Master File-Transaction File roneous conditions arise? We deal with two such system conditions in this example. If the transaction file We demonstrate the application of object-based is empty, the management report will note this development with box structures to a simplified and the system finishes. If the PAR TID in the trans­ ersion of the classic example of a Master File­ action file does not match any record in the mas­ Transaction File system. The following problem ter file, the transaction record will be written with atement is given: an error message. All pertinent conditions and contingencies should be studied during the re­ A supply business maintains a master file of parts quirements definition phase. inventory with attributes of part identification PARTID) and quantity on hand (QOH). Each day The black box notation for the INVENTORY sys­ . arts are received and shipped. For each trans- tem requirement is:

- SYSTEMS JOURNAL, VOL 32, NO 2, 1993 HEVNER AND MILLS 245 Black Box Inventory glish for exposition purposes. Equivalently, we could have presented a mathematical representa­ stimulus tion of conditional algebraic assignments for the Transaction_file : file of records transaction. record PARTID : integer, ACTION : type of ('in', 'out'), Systems analysis. We concentrate our analysis for QTY : integer the example in discovering reuse opportunities. endrecord. We assume that a File_manager object type exists Master_file : file of records as a box structure design in the existing reuse record library. The object type is designed to encapsu­ PARTID : integer, late a file of arbitrary design and size. Visible op­ QOH : integer erations on the file would include typical file op­ endrecord. erations, such as the following:

response Master_file : file of records OPEN Establishes currency pointer at first record record of file and checks access rights P ARTID : integer, ISEMPTY Checks if file is empty, returns Bool­ QOH : integer ean value endrecord. READ Reads record at currency pointer, Report: moves pointer to next record record ATEOF Checks if currency pointer is at EOF, HEADER : report_header, returns Boolean value BODY : report_body WRITE Overwrites given record at currency endrecord. pointer FIND Given a primary identifier value, finds behavior the first record with that identifier; if no match is found, a STATUS value is if The transaction file is empty returned then Write the management report else ADD Given a record with a valid identifier, for Each record in the transaction file places the record in the file in correct do order Match the PARTID value into the DELETE Given a record identifier, finds record master file and deletes it from file if A match exists CLOSE Establishes file integrity and update then Modify the QOH value by add­ commitments, releases any file locks ing (ACTION = 'in') or sub­ tracting (ACTION = 'out') the value of QTY; We assume that two object instantiations of File_ Write the transaction record manager encapsulate the master file and the and new master record in the transaction file. Since these files would also be management report used by other systems in the business, these else Write the transaction record objects would be organization-wide commori and an error statement in the services. We name the objects Master_file and management report Trans_file . if; od; fi· Systems design and verification. State box design end' Black Box Inventory. of the INVENTORY system would discover the need to store the evolving management report as Note that the transaction statement in the black intermediate state. Thus, the state box design is box is a mixture of keywords and structured En- given as follows:

246 HEVNER AN D MILLS IBM SYSTEMS JOURNAL, VOL 32, NO 2, 1993 State Box Inventory sulated into a data abstraction with visible oper­ ations? We choose to develop a system-wide common services common service object called Mgmt_report with Master_file. Report as encapsulated data and four visible op­ Trans_file . erations:

stimulus NEW Initializes Report with defined header response information, such as date, time, titles, Report: and column headings record ADD Adds correctly processed Trans_file HEADER : report_ header, record and new Master_file record to BODY : report_body body of Report endrecord. ERRORl Adds a Trans_file record and error state statement to body of Report when no Report: match is found in Master_file record PRINT Prints the current state value of theRe­ HEADER : report_ header, port BODY : report_body endrecord. The Mgmt_report object will be completely de­ veloped and verified, from black box requirement behavior to clear box design, and used in the INVENTORY system as a common service object. The clear if The transaction file is empty box design of INVENTORY could be presented as: then Write Report else Clear Box Inventory for Each record in Trans_file do Match the PARTID value in Master_file common services if A match exists Master_file. (* organization-wide then Modify the QOH value in Master_file common service *) by adding (ACTION = 'in') Trans_file. (* organization-wide or subtracting (ACTION = 'out') common service *) the value of QTY from Trans_file; Mgmt_report. (* system-wide Write Trans_file record and new common service *) Master_file record in Report else Write Trans_file record and an stimulus error statement in Report response if; state od; fi· ' behavior end State Box Inventory. data (* temporary data *) TESTl : Boolean, The state box can be verified as a correct design proc of the black box requirement in a straightforward use Mgmt_report(in: NEW); manner. Although we do not present all of the use Master_file(in: OPEN); details here, the critical tasks would be to verify use Trans_file(in: OPEN); the correct uses of Master_file and Trans_file ob­ use Trans_file(in: ISEMPTY, out: TESTl); jects and the Report state in the state box trans­ if NOT TESTl then use Update_master fi; action. use Mgmt_report(in: PRINT); use Master_file(in: CLOSE); During the clear box design, an important design use Trans_file(in: CLOSE) decision presents itself. Should Report remain as corp global state in the system or should it be encap- end Clear Box Inventory.

IBM SYSTEMS JOURNAL, VOL 32, NO 2, 1993 HEVNER AND MILLS 247 Again, the verification of the clear box can be proc done and will not be presented here. use Trans_file(in: ATEOF, out: TEST2); while NOT TEST2 The only new object at the second level of the do system hierarchy is the Update_master black use Trans_file(in: READ, out: T_REC); box. We would iterate the development process use Master_file(in: FIND, for this object, defining the black box, performing T_REC.PARTID out: M_REC, STATUS); if STATUS = NOT_FOUND then use Mgmt_report(in: ERRORl, T_REC) else The design work is complete if T_REC.ACTION = 'in' then M_REC.QOH ~ M_REC.QOH when there are no undefined + T_REC.QTY black boxes and the system else M_REC.QOH ~ M_REC.QOH is completely specified. - T_REC.QTY fi· use' Master_file(in: WRITE, M_REC); use Mgmt_report(in: ADD, systems analysis, and, finally, designing the state M_REC, T_REC) box and clear box. For purposes of space, we fi· show the final clear box design. use' Trans_file(in: ATEOF, out: TEST2); od Clear Box Update_master corp end Clear Box Update_Master. common services Since there are no undefined black boxes in Master_file. (* organization-wide Update_master, no further design work is needed common service *) and the INVENTORY system is completely speci­ Trans_file. (* organization-wide fied as a hierarchy of object uses. Figure 3 shows common service *) the box structure usage hierarchy for this result­ Mgmt_report. (* system-wide ing system. common service *) Observations for this example. In the INVENTORY system development, we have identified and cre­ stimulus ated five objects: Inventory, Update_master, response Master_file, Trans_file, and Mgmt_report. state Master_file and Trans_file are instantiations of a behavior file management object type to encapsulate the data (* temporary data *) master inventory file and the daily transaction TEST2 : Boolean, file, respectively. The objects are organization­ T_REC: wide common services to all application systems record that require access to these files. For example, an PARTID : integer, on-line application system will place transaction ACTION : type of ('in', 'out'), records into Trans_file during the daily inventory QTY : integer processing. endrecord. M_REC: The Mgmt_report object can be an instantiation of record an object-type that standardizes report formats PARTID : integer, and operations in the organization or it can be QOH : integer developed from scratch for this application. If it endrecord. is newly developed, then the object becomes a

248 HEVN ER AND MILLS IBM SYSTEMS JOU RNAL, VOL 32, NO 2, 1993 Figure 3 Inventory system box structure usage hierarchy

COMMON SERVICES

APPLICATION SYSTEM

system-wide object for use throughout the INVEN­ Summary TORY system. If the encapsulated management report is to be used further in other system ap­ Our goals in this paper have been to discuss and plications, then the Mgmt_report object can be demonstrate the use of box structures in a rigor­ designed to become an organization-wide object. ous and systematic object-based systems devel­ opment process. Box structures provide a bridge Inventory and Update_master are objects unique between structured development methods and to the INVENTORY application. While the final de­ object-oriented development methods. The fo l­ signs of Inventory and Update_master encapsu­ lowing observations support and summarize our late no persistent data (all persistent data are in discussion. the common services), the analysis and design of these objects provide the insights and the creative opportunities to perform the necessary object de­ • Box structures provide for the definition of data composition and composition for this system. abstractions and objects in three mathematical This example also demonstrates the ability to de­ views. sign objects within objects since Update_master • The box structure usage hierarchy allows intel­ is wholly contained within the Inventory object. lectual control over the development process.

M SYSTEMS JOURNAL, VO L 32, NO 2, 1993 HEVNER AND MILLS 249 Each box structure in the system usage hierar­ Cited references and note chy is an object. 1. E. Yourdon, Modem Structured Analysis, Yourdon • All design inventions are separated into clearly Press, Prentice-Hall, Inc., Englewood Cliffs, NJ (1989). identified small steps. Design verification is per­ 2. J. Cameron,JSP &JSD: TheJacksonApproach to Soft· formed after each inventive step of design and ware Development, IEEE Computer Society Press, Washington, D.C. (1989). provides a systematic basis for inspection. 3. J. Martin, Information Engineering: Book ]-Introduc­ • An object is stored in the system repository in tion; Book 2- Planning and Analysis; Book 3-Design all box structure views, from black box require­ and Construction, Prentice-Hall, Inc., Englewood Cliffs, ment to clear box detailed design. The object is NJ (1989). 4. S. Bailin, "An Object-Oriented Requirements Specifica­ described in an inheritance hierarchy as a com­ tion Method," Communications of the ACM 32, No. 5, mon service. 608-623 (May 1989). • Box structures support an integrated develop­ 5. P. Ward, "How to Integrate Object Orientation with Structured Analysis and Design," Software 6, No. 2, ment process, in that there is no need to trans­ 74-82 (March 1989). form the representation or content of develop­ 6. P. Coad and E. Yourdon, Object-Oriented Analysis , Sec­ ment\information from one phase to another. ond Edition, Prentice-Hall, Inc., Englewood Cliffs, NJ • The systems development process is com­ (1991) . 7. S. Shlaer and S. Mellor, Object-Oriented Systems Anal­ pletely flexible between development phases. ysis, Prentice-Hall, Englewood Cliffs, NJ (1988). The next phase to be performed is based upon 8. G. Booch, Object-Oriented Design with Applications, feedback from previous work results. The de­ Benjamin/Cummings Publishing Co., Redwood City, CA (1991). velopment of a system box structure usage hi­ 9. E. Seidewitz and M. Stark, "Towards a General Object­ erarchy provides a discipline of sound and com­ Oriented Software Development Methodology," Pro­ plete design. ceedings of the 1st International Conference on Ada Pro­ gramming Language Applications for the NASA Space Station, D.4.6.1-D.4.6.14 (1986). Future research will expand upon the critical is­ 10. B. Meyer, Object-Oriented Software Construction, Sec­ ond Edition, Prentice-Hall, Englewood Cliffs, NJ (1991). sues in this development process. We are cur­ 11. P. Coad and E. Yourdon, Object-Oriented Design, Pren­ rently performing research in three areas: tice-Hall, Inc., Englewood Cliffs, N.T (1991). 12. L. Cardelli and P. Wegner, " On Understanding Types, Data Abstraction, and Polymorphism," ACM Computing • Requirements definition- The process of elic­ Surveys 17, No.4, 471 - 522 (December 1985). iting requirements and representing system re­ 13 . B. Henderson-Sellers and J. Edwards, "The Object-Ori­ quirements in box structures needs important ented Systems Life Cycle," Communications ofth e A CM 38 33, No. 9, 142-159 (September 1990). new research. While the goal of requirements 14. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and definition is to place all requirements in abstract W. Lorensen, Object-Oriented Modeling and Design, black boxes, there are often essential require­ Prentice-Hall, Inc., Englewood Cliffs, NJ (1991). 15. R. Wirfs-Brock, B. Wilkerson, and L. Wiener, Designing ments on data, procedure, and nonfunctional Object-Oriented Software, Prentice-Hall, Inc., Engle­ requirements, such as system performance. wood Cliffs, NJ (1990). • Concurrent and real-time systems- Current 16. H . Mills, " Stepwise Refinement and Verification in Box­ box structure theory supports the design and Structured Systems," Computer 21, No. 6, 23- 36 (June 1988). verification of sequential systems. Our recent 17. H . Mills, R. Linger, and A. Hevner, Principles of Infor­ research has provided extensions of box struc­ mation Systems Analysis and Design, Academic Press, tures to the design and verification of concur­ Inc., Orlando, FL (1986). 29 18. H. Mills, R. Linger, and A. Hevner, "Box Structured rent systems. Much more research is needed, Information Systems Development," IBM Systems Jour­ however, to handle all of the complexities of nal 26, No. 4, 395--413 (1987). real-time systems development. 19. R. Cobb and H. Mills, " Engineering Software under Sta­ • Integrated CASE-An eventual goal of this re­ tistical Quality Control," Software 7, No. 6, 44-54 (No­ vember 1990). search is to design and build a comprehensive 20. R. Linger, H. Mills, and B. Witt, Structured Program­ CASE system that provides integrated support of ming: Theory and Practice, Addison-Wesley Publishing object-oriented development from require­ Co., Reading, MA (1979). ments definition through system implementa­ 21. D. Parnas, "On a 'Buzzword' Hierarchical Structure," Proceedings of the IFIP Congress 1974, North-Holland tion. Our current research focuses on the rep­ Publishing Co., Amsterdam (1974). resentations of box structure information in 22. A. Hevner and R. Linger, "A Method for Data Re-En­ common system development repositories. 39 gineering in Structured Programs, Proceedings of the

250 HEVNER AND MILLS IBM SYSTEMS JOURNAL, VOL 32, NO 2, 1993 22nd Annual Hawaii International Conference on System Alan R. Hevner College of Business and Management, Man­ Sciences, Volume ]- Software Track, IEEE Computer agement and Public Affairs Building, University ofMaryland, Society Press, Los Alamitos, CA (January 1989), pp. College Park, Maryland 20742. Dr. Hevner is an associate 1025-1034. professor and chairman of the Information Systems Depart­ 23. B. Liskov and S. Zilles, "An Introduction to Formal Spec­ ment at the University of Maryland. He is a faculty member ification of Data Abstractions," Current Trends in Program­ of the Institute of Systems Research at Maryland. He has ming Methodology: Software Specification and Design, published over 50 refereed papers in the research areas of Vol. 1, Prentice-Hall, Inc., Englewood Cliffs, NJ (1977). distributed database systems, information systems develop­ 24. S. Danforth and C. Tomlinson, "Type Theories and Ob­ ment, and systems engineering. Dr. Hevner is a member of ject-Oriented Programming," ACM Computing Surveys ACM, the IEEE Computer Society, and the Operations Re­ 20, No. 1, 29-72 (March 1988). search Society of America (ORSA). 25. H. Abelson and G. Sussman, Structure and Interpretation of Computer Programs, The MIT Press, Cambridge, MA Harlan D. Mills Computer Science Department, Florida In­ (1985). stitute of Technology, Melbourne, Florida 32901. Dr. Mills is 26. P. Hausler, R. Linger, M. Pleszkoch, and A. Hevner, a professor of computer science at the Florida Institute of "Using Function Abstraction to Understand Program Be­ Technology and President of Software Engineering Technol­ havior," Software 7, No. 1, 55-63 (January 1990). ogy. He has written or coauthored six books and over 50 27. This description of an object inheritance hierarchy is sim­ refereed technical journal articles on topics related to software ilar to the use of the Ada generic structure. Thus, we use engineering. Dr. Mills received a Ph.D. in mathematics from the term "object-based" to describe the box-structured Iowa State University. He is an honorary Fellow of Wesleyan methods of systems development with objects. University and a Fellow of IBM, the American Computer 28. P. Jalote, "Functional Refinement and Nested Objects for Programming Association, and the IEEE. He also holds the Object-Oriented Design," IEEE Transactions on Soft­ Warner Prize for contributions to computer science. ware Engineering 15, No. 3, 264-270 (March 1989). 29. S. Becker and A. Hevner, "Concurrent System Design Reprint Order No. G321-5511. with Box Structures," Proceedings of the 13th Annual International Computer Software and Applications Con­ ference (COMPSAC), IEEE Computer Society Press, Washington, D.C. (September 1989), pp. 32-40. 30. Object-Oriented Concepts, Databases, and Applications, W. Kim and F. Lochovsky, Editors, Addison-Wesley Publishing Co., Reading, MA (1989). 31. J. Hughes, Object-Oriented Databases, Prentice-Hall In­ ternational Series in Computer Science, Hartfordshire, England (1991). 32. B. Meyer, " Reusability: The Case for Object-Oriented Design," Software (March 1987). 33. T. Biggerstaff and A. Perlis, Software Reusability: VoL ]-Concepts and Models, Vol. 2-Applications and Expe­ rience, Addison-Wesley Publishing Co. , Reading, MA (1989). 34. A. Goldberg and D. Robson, Smalltalk-80: The Language and Its Implementation, Addison-Wesley Publishing Co., Reading, MA (1983). 35. A da for Specification: Possibilities and Limitations, S. Goldsack, Editor, Cambridge University Press, Cam­ bridge, England (1985). 36. D. Fetzer and J. Poore, "Using Box Structures with the Z Notation," Proceedings of the 25th Annual Hawaii In­ ternational Conference on System Sciences, Vol. II­ Software Technology Track, IEEE Computer Society Press, Los Alamitos, CA (January 1992). 37. E. Chikofsky and J. Cross, "Reverse Engineering and Design Recovery: A Taxonomy," Software 7, No. 1, 13-17 (January 1990). 38. A. Hevner, "Box Structured Requirements Determina­ tion Methods," Proceedings of the First Workshop on Information Technologies & Systems (WITS-91), MIT Sloan School of Management, Cambridge, MA (Decem­ ber 1991). 39. A. Hevner, S. Becker, and L. Pedowitz, "Integrated CASE for Cleanroom Development," Software 9, No.2, 69-76 (March 1992).

A ccepted for publication August 17, 1992.

3M SYSTEMS JOURNAL, VOL 32, NO 2, 1993 HEVNER AND MILLS 251