DOCSLIB.ORG

Box-Structured Methods for Systems-Development with Objects

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Box-Structured Methods for Systems-Development with Objects 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
Load more

Recommended publications
  • Software Engineering Process Development
    MACHINES, TECHNOLOGIES, MATERIALS. ISSN 1313-0226. ISSUE 11/2013 SOFTWARE ENGINEERING PROCESS DEVELOPMENT M.Sc. Ivanova Milka. Faculty of Mechanical Engineering – Technical University of Sofia, Bulgaria Abstract: A software engineering (SE) process is a set of activities that leads to the production of software product. These activities may involve the development of software from scratch in a standard program language. However new software is developed by extending and modifying existing systems and by configuring and integrating off-the-self software or systems components. In the report they have understand the concept of software engineering, software engineering process models and when these models might be used. Keywords: Software, software product, software engineering, software process, process models Many people equate the term software as a computer programs. But software engineering (CBSE) This technique assumes that parts of software is not just the programs also all associate documentation the system already exist. The system development process focuses and configuration data that is needed to make these programs on integrating these parts rather than developing them from scratch. operate correctly. A software system usually consist of a number of Some examples of the types of software process model that may separate programs, configuration files which are used to set up these be produced are: programs, system documentation witch describe the systems’ structure and user’s documentation which explains how to use the I. THE LINEAR SEQUENTIAL MODEL system and web sites for users to download recent information. Sometimes called the waterfall model, the linear sequential model Software that can be sold to the customer named a software suggests a systematic, sequential approach to software development product; There are fundamental types of software product: that begins at the system level and progresses through analysis, design, coding, testing, and support.
    [Show full text]
  • Chapter 1: Introduction
    Just Enough Structured Analysis Chapter 1: Introduction “The beginnings and endings of all human undertakings are untidy, the building of a house, the writing of a novel, the demolition of a bridge, and, eminently, the finish of a voyage.” — John Galsworthy Over the River, 1933 www.yourdon.com ©2006 Ed Yourdon - rev. 051406 In this chapter, you will learn: 1. Why systems analysis is interesting; 2. Why systems analysis is more difficult than programming; and 3. Why it is important to be familiar with systems analysis. Chances are that you groaned when you first picked up this book, seeing how heavy and thick it was. The prospect of reading such a long, technical book is enough to make anyone gloomy; fortunately, just as long journeys take place one day at a time, and ultimately one step at a time, so long books get read one chapter at a time, and ultimately one sentence at a time. 1.1 Why is systems analysis interesting? Long books are often dull; fortunately, the subject matter of this book — systems analysis — is interesting. In fact, systems analysis is more interesting than anything I know, with the possible exception of sex and some rare vintages of Australian wine. Without a doubt, it is more interesting than computer programming (not that programming is dull) because it involves studying the interactions of people, and disparate groups of people, and computers and organizations. As Tom DeMarco said in his delightful book, Structured Analysis and Systems Specification (DeMarco, 1978), [systems] analysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult.
    [Show full text]
  • Software Engineering Process Development
    SCIENTIFIC PROCEEDINGS X INTERNATIONAL CONGRESS "MACHINES, TECHNOLОGIES, MATERIALS" 2013 ISSN 1310-3946 SOFTWARE ENGINEERING PROCESS DEVELOPMENT M.Sc. Ivanova Milka. Faculty of Mechanical Engineering – Technical University of Sofia, Bulgaria Abstract: A software engineering (SE) process is a set of activities that leads to the production of software product. These activities may involve the development of software from scratch in a standard program language. However new software is developed by extending and modifying existing systems and by configuring and integrating off-the-self software or systems components. In the report they have understand the concept of software engineering, software engineering process models and when these models might be used. Keywords: Software, software product, software engineering, software process, process models Many people equate the term software as a computer programs. But software engineering (CBSE) This technique assumes that parts of software is not just the programs also all associate documentation the system already exist. The system development process focuses and configuration data that is needed to make these programs on integrating these parts rather than developing them from scratch. operate correctly. A software system usually consist of a number of Some examples of the types of software process model that may separate programs, configuration files which are used to set up these be produced are: programs, system documentation witch describe the systems’ structure and user’s documentation which explains how to use the I. THE LINEAR SEQUENTIAL MODEL system and web sites for users to download recent information. Sometimes called the waterfall model, the linear sequential model Software that can be sold to the customer named a software suggests a systematic, sequential approach to software development product; There are fundamental types of software product: that begins at the system level and progresses through analysis, design, coding, testing, and support.
    [Show full text]
  • Appendix A: a Practical Guide to Entity-Relationship Modeling
    Appendix A: A Practical Guide to Entity-Relationship Modeling A Practical Guide to Entity-Relationship Modeling Il-Yeol Song and Kristin Froehlich College of Information Science and Technology Drexel University Philadelphia, PA 19104 Abstract The Entity-Relationship (ER) model and its accompanying ER diagrams are widely used for database design and Systems Analysis. Many books and articles just provide a definition of each modeling component and give examples of pre-built ER diagrams. Beginners in data modeling have a great deal of difficulty learning how to approach a given problem, what questions to ask in order to build a model, what rules to use while constructing an ER diagram, and why one diagram is better than another. In this paper, therefore, we present step-by-step guidelines, a set of decision rules proven to be useful in building ER diagrams, and a case study problem with a preferred answer as well as a set of incorrect diagrams for the problem. The guidelines and decision rules have been successfully used in our beginning Database Management Systems course for the last eight years. The case study will provide readers with a detailed approach to the modeling process and a deeper understanding of data modeling. Introduction Entity relationship diagrams (ERD) are widely used in database design and systems analysis to represent systems or problem domains. The ERD was introduced by Chen (1976) in early 1976. Teorey, Yang, and Fry (1986) present an extended ER model for relational database design. The ERD models a given problem in terms of its essential elements and the interactions between those elements in a problem domain.
    [Show full text]
  • A Comparative Analysis of Entity-Relationship Diagrams1
    Journal of Computer and Software Engineering, Vol. 3, No.4 (1995), pp. 427-459 A Comparative Analysis of Entity-Relationship Diagrams1 Il-Yeol Song Drexel University Mary Evans USConnect E.K. Park U.S. Naval Academy The purpose of this article is to collect widely used entity-relationship diagram (ERD) notations and so their features can be easily compared, understood, and converted from one notation to another. We collected ten different ERD notations from text books and CASE tools. Each notation is depicted using a common problem and includes a discussion of each characteristic and notation. According to our investigation, we have found that ERD features and notations are different in seven features: whether they allow n-ary relationships, whether they allow attributes in a relationship, how they represent cardinality and participation constraints, the place where they specify constraints, whether they depict overlapping and disjoint subclass entity-types, whether they show total/partial specialization, and whether they model the foreign key at the ERD level. We conclude that many of the ER diagrams we studied are different in how they depict the criteria listed above. In order to convert one diagram to another, some notations must be extended and carefully converted from one notation into another. We also discuss the limitations of existing CASE tools in terms of modeling capabilities and supporting diagrams. Keywords: Entity-Relationship Diagrams, ERD, design, modeling, CASE 1Correspondence should be addressed to Il-Yeol Song, College of Information Science and Technology, Drexel University, 32nd and Chestnut Streets, Philadelphia, PA 19104. Email: [email protected] 1 Journal of Computer and Software Engineering, Vol.
    [Show full text]
  • 36716885.Pdf
    Calhoun: The NPS Institutional Archive Theses and Dissertations Thesis Collection 1992-12 Information engineering and the Information Engineering Facility verus rapid application development and FOCUS Clark, Lucille Charlotte Monterey, California. Naval Postgraduate School http://hdl.handle.net/10945/23703 piPT.ASSTFTFn T25/791 IURITY CLASSIFICATION OF THIS PAGE REPORT DOCUMENTATION PAGE REPORT SECURITY CLASSIFICATION lb RESTRICTIVE MARKINGS UNCLASSIFIED SECURITY CLASSIFICATION AUTHORITY 3. DISTRIBUTION /AVAILABILITY OF REPORT Approved for public release; distribution DECLASSIFICATION / DOWNGRADING SCHEDULE is unlimited. PERFORMING ORGANIZATION REPORT NUMBER(S) 5. MONITORING ORGANIZATION REPORT NUMBER(S) OFFICE SYMBOL 7a. OF MONITORING . NAME OF PERFORMING ORGANIZATION 6b. NAME ORGANIZATION (If applicable) Naval Postgraduate School 53 Naval Postgraduate School ADDRESS {City, State, and ZIP Code) 7b. ADDRESS (City. State, and ZIP Code) Monterey, CA 93943-5000 Monterey, CA 93943-5000 NAME OF FUNDING /SPONSORING 8b OFFICE SYMBOL 9. PROCUREMENT INSTRUMENT IDENTIFICATION NUMftER ORGANIZATION (If applicable) ADDRESS (City. State, and ZIP Code) 10 SOURCE OF FUNDING NUMBERS PROGRAM PROJECT TASK WORK UNIT ELEMENT NO. NO. NO lACCESSION NO. I. TITLE (Include Security Classification) INFORMATION ENGINEERING AND THE INFORMATION ENGINEERING FACILITY VERSUS RAPID APPLICATION DFVFT.nPMF.NT AND FOCUS (UNCLASSIFIED) , I. PERSONAL AUTHOR(S) Clark. Lucille C, 3a. TYPE OF REPORT 13b. TIME COVERED 14 DATE OF REPORT (Year. Month, Day) 15 PAGE COUNT 231 Master's thesis FROM TO December 1992 5. supplementary notation ^ views expressed in this thesis are those of the author and do not government reflect the official policy or position of the Department of Defense or the U.S. COSATI CODES 18 SUBJECT TERMS (Continue on reverse if necessary and identify by block number) e FIELD GROUP SUB-GROUP E §S Engineering SSffBffiiiMWSiffiSI , I§F? !nfg§ma?f ' Facility, FOCUS, Rapid Application Development, Methodology 9.
    [Show full text]
  • The Use of Information Engineering As a Framework for Analyzing Records in Electronic Form
    THE USE OF INFORMATION ENGINEERING AS A FRAMEWORK FOR ANALYZING RECORDS IN ELECTRONIC FORM by Jayne Bellyk B. G. S., Simon Fraser University, 1981 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF ARCHIVAL STUDIES in THE FACULTY OF GRADUATE STUDIES School of Library, Archival and Information Studies We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA April 1995 ©Jayne Bellyk, 1995 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Departmsht of Li WfrT\j\, CA^cvlyj \/4c^4 \ S^/vv^A/\ ^±Ock\C < The University of British Columbia Vancouver, Canada •ate Afy\\ 3-5-, iqq.5 DE-6 (2788) ABSTRACT This thesis examines an approach and a methodology used by information technology professionals to develop information systems. Information engineering is a methodology for developing information systems following a specific process. It does not set out to create or manage records, yet it does have significance to archivists as a framework for analyzing information and records in electronic form. The framework that information engineering extends to archivists is one that links administrative goals and business functions to individual activities and acts.
    [Show full text]
  • Process Modeling Bibliography 3.1 Page 1 Provided by Tryon and Associates Brooks, Frederick P
    Process Modeling Series BIBLIOGRAPHY "The man who does not read good books has no advantage over the man who can't read them." - Mark Twain This bibliography is provided as a reference for any outside materials that were used in the development of the Tryon and Associates Process Modeling seminars. This is a partial bibliography in that we provide only the authors name, title of the work and the original date of publication. A short description of the significance of the materials is included with most of the titles. Many of the books listed are also available on cassette tape. Where that specific medium is recommended, it will be indicated with a "CASS" notice. You will also find a private rating system indicating our opinion of the title. "AAA" indicates a must-read and a book that we feel belongs in every professional's library. "AA" tells you this is an important work that should be in a corporate library for frequent reference. "A" identifies a title that should be browsed as soon as possible and read when there is time. We do not list titles below an "A" but will be happy to provide bibliographical information on any other material referenced in our seminars. You may find some of these books in your local bookstore but most of them are easier to find on the Internet. You may want to find a good source for out of print books for some of these titles. Chuck Tryon Adams, Richard. WATERSHIP DOWN, 1972. (AA – Okay, let’s start this list with something FUN.
    [Show full text]
  • Data Model As an Architectural View
    Data Model as an Architectural View Paulo Merson October 2009 TECHNICAL NOTE CMU/SEI-2009-TN-024 Research, Technology, and System Solutions Unlimited distribution subject to the copyright. This report was prepared for the SEI Administrative Agent ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2100 The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense. Copyright 2009 Carnegie Mellon University. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for inter- nal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works. External use. This document may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission.
    [Show full text]