DOCSLIB.ORG

Conversion of Legacy COBOL Systems Into the Unified Modeling Language Using the Wide-Spectrum Language

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Conversion of Legacy COBOL Systems Into the Unified Modeling Language Using the Wide-Spectrum Language Evolution of Batch-Oriented COBOL Systems into Object-Oriented Systems through Unified Modelling Language Richard Charles Millham A thesis submitted in partial fulfilment of the requirements for the degree of Doctor of Philosophy De Montfort University February, 2005 Abstract Throughout the world, there are many legacy systems that fulfil critical business functions but often require new functionality to comply with new business rules or require redeployment to another platform. Legacy systems vary tremendously in size, functionality, type (such as batch-oriented or real-time), programming language source code, and many other factors. Furthermore, many of these legacy systems have missing or obsolete documentation which makes it difficult for developers to re-develop the system to meet any new functionality. Moreover, the high cost of whole scale redevelopment and high switchover costs preclude any replacement systems for these legacy systems. Reengineering is often proposed as a solution to this dilemma of high re-development and switchover costs. However, reengineering a legacy system often entails restructuring and re-documenting a system. Once these restructuring and re-documentation processes have been completed, the developers are better able to redevelop the parts of the systems that are required to meet any new functionality. This thesis introduces a number of methods to restructure a procedurally-structured, batch-oriented COBOL system into an object-oriented, event-driven system through the use of an intermediate mathematical language, the Wide Spectrum Language (WSL), using system source code as the only documentation artefact. This restructuring process is accomplished through the application of several algorithms of object identification, independent task evaluation, and event identification that are provided in the thesis. Once these transformations are complete, method(s) are specified to extract a series of UML diagrams from this code in order to provide documentation of this system. This thesis outlines which of the UML diagrams, as specified in the UML Specifications version 1.5, can be extracted using the specified methods and under what conditions this extraction, using system source code only, can occur in a batch-oriented system. These UML diagrams are first expressed through a WSL-UML notation; a notation which follows the semantics and structure of UML Specifications version 1.5 in order to ensure compatibility with UML but is written as an extension of WSL in order to enable WSL to represent abstract modelling concepts and diagrams. This WSL-UML notation is then imported into a visual UML diagramming tool for the generation of UML diagrams to represent this system. The variety of legacy systems precludes any universal approach to reengineering. Even if a legacy system shares a common programming language, such as COBOL, the large number of COBOL constructs and the huge number of possible dialects prevents any universal translator of the original program code to another. It is hoped that by focusing on one particular type of legacy system with constraints, in this case a batch-oriented COBOL system with its source code its only surviving artefact, and by providing validated algorithms to restructure and re-document these legacy systems in the Unified Modelling Language, an industry system modelling standard, and by determining which of these Unified Modelling Language can be extracted practically from such a system, some of the parameters and uncertainties, such as program understanding of an undocumented system, in reengineering this type of system can be reduced. 2 Acknowledgments The author wishes to thank principally his first supervisor, Hongji Yang, for all his help, advice, and suggestions during this research process. Thanks must also go to my second supervisors, Professor Hussein Zedan and Mr. Steve McRobb, for all the help and advice that they provided along the way. Additionally, I would like to thank my local supervisor, Dave Shellenberg, for his helpful comments and suggestions as well as lending his expertise with legacy systems. I would like to dedicate this thesis to the memory of Jan Kwiatkowski, a former research student of Hongji Yang, whose arduous task in formulating a tool to translate common COBOL constructs into WSL was tragically cut short by his death in a car accident several years ago. 3 Contents ABSTRACT ............................................................................................................................................................................................................... 2 ACKNOWLEDGMENTS ......................................................................................................................................................................................... 3 CONTENTS ............................................................................................................................................................................................................. 4 LIST OF FIGURES................................................................................................................................................................................................... 9 LIST OF TABLES................................................................................................................................................................................................... 10 CHAPTER 1: INTRODUCTION ................................................................................................................................... 11 1.1 PURPOSE OF RESEARCH AND OVERVIEW OF PROBLEM .................................................................................................................... 11 1.1.1 Motivation ............................................................................................................................................................................................ 12 1.1.1.1 Business Case .......................................................................................................................................................................................................... 12 1.1.1.2 Academic Case ....................................................................................................................................................................................................... 13 1.1 EXISTING RESEARCH AND ITS DEFICIENCIES: COMPARISON OF EXISTING REENGINEERING TOOLS ........................... 16 1.2 PROBLEMS TO BE RESEARCHED.......................................................................................................................................................... 20 1.3 RESEARCH QUESTIONS ......................................................................................................................................................................... 21 1.4 RESEARCH METHODOLOGY ..................................................................................................................................................................... 21 1.4.1 Overview of Research Process ........................................................................................................................................................ 23 1.5 ORIGINAL CONTRIBUTION ....................................................................................................................................................................... 26 1.6 STRUCTURE OF THESIS ............................................................................................................................................................................... 28 CHAPTER 2: BACKGROUND ..................................................................................................................................... 30 2.1 INTRODUCTION ........................................................................................................................................................................................... 30 2.2 HISTORY OF SOFTWARE DEVELOPMENT .............................................................................................................................................. 30 2.3 REVERSE ENGINEERING AND REENGINEERING ................................................................................................................................ 30 2.4 COBOL-BASED SOFTWARE SYSTEMS .................................................................................................................................................... 32 2.5 OBJECT-ORIENTED PROGRAMMING ...................................................................................................................................................... 33 2.6 RESTRUCTURING PROCEDURAL LEGACY SYSTEM TO OBJECT ORIENTED SYSTEMS ................................................................. 34 2.6.1 Background of Program Function Abstraction........................................................................................................................... 34 2.6.2 Background of Object Identification Process.............................................................................................................................. 36 2.6.3 Background of Independent Task Evaluation ............................................................................................................................. 37 2.6.4 Background of Event Identification .............................................................................................................................................
Load more

Recommended publications
  • PL/SQL Multi-Diagrammatic Source Code Visualization
    SQLFlow: PL/SQL Multi-Diagrammatic Source Code Visualization Samir Tartir Ayman Issa Department of Computer Science University of the West of England (UWE), University of Georgia Coldharbour Lane, Frenchay, Bristol BS16 1QY Athens, Georgia 30602 United Kingdom USA Email: [email protected] Email: [email protected] ABSTRACT: A major problem in software introducing new problems to other code that was perfectly maintenance is the lack of a well-documented source code working before. Therefore, educating programmers about in software applications. This has led to serious the behaviors of the target code before start modifying it difficulties in software maintenance and evolution. In is not an easy task. Source code visualization is one of the particular, for those developers who are faced with the heavily used techniques in the literature to overcome this task of fixing or modifying a piece of code they never lack of documentation problem, and its consequent even knew existed before. Database triggers and knowledge-sharing problem [7, 9]. procedures are parts of almost every application, are typical examples of badly documented software Therefore, this research aims at investigating the current components being the hidden back end of software database source code visualization tools and identifying applications. Source code visualization is one of the the main open issues for research. Consequently, the heavily used techniques in the literature so as to mostly used PL/SQL database programming language has familiarize software developers with new source code, been selected for a flowcharting reverse engineering and compensate for the knowledge-sharing problem. prototype tool called "SQLFlow". SQLFlow has been Therefore, a new PL/SQL flowcharting reverse designed, implemented, and tested to parse the target engineering tool, SQLFlow, has been designed and PL/SQL code stored in database procedures, analyze its developed.
    [Show full text]
  • Component Diagrams in UML
    9. UML Component Diagrams Page 1 of 4 Component Diagrams in UML The previous articles covered two of the three primary areas in which the UML diagrams are categorized (see Article 1)—Static and Dynamic. The remaining two UML diagrams that fall under the category of Implementation are the Component and Deployment diagrams. In this article, we will discuss the Component diagram. Basics The different high-level reusable parts of a system are represented in a Component diagram. A component is one such constituent part of a system. In addition to representing the high-level parts, the Component diagram also captures the inter- relationships between these parts. So, how are component diagrams different from the previous UML diagrams that we have seen? The primary difference is that Component diagrams represent the implementation perspective of a system. Hence, components in a Component diagram reflect grouping of the different design elements of a system, for example, classes of the system. Let us briefly understand what criteria to apply to model a component. First and foremost, a component should be substitutable as is. Secondly, a component must provide an interface to enable other components to interact and use the services provided by the component. So, why would not a design element like an interface suffice? An interface provides only the service but not the implementation. Implementation is normally provided by a class that implements the interface. In complex systems, the physical implementation of a defined service is provided by a group of classes rather than a single class. A component is an easy way to represent the grouping together of such implementation classes.
    [Show full text]
  • Xtuml: Current and Next State of a Modeling Dialect
    xtUML: Current and Next State of a Modeling Dialect Cortland Starrett [email protected] 2 Outline • Introduc)on • Background • Brief History • Key Players • Current State • Related Modeling Dialects • Next State • Conclusion [email protected] 3 Introduc)on [email protected] 4 Background • Shlaer-Mellor Method (xtUML) – subject maers, separaon of concerns – data, control, processing – BridgePoint • data modeling (Object Oriented Analysis (OOA)) • state machines • ac)on language • interpre)ve execu)on • model compilaon [email protected] 5 History • 1988, 1991 Shlaer-Mellor Method published by Stephen Mellor and Sally Shlaer. • 2002 Executable UML established as Shlaer-Mellor OOA using UML notation. • 2004 Commercial Corporate Proprietary Licensed. • 2013 BridgePoint xtUML Editor goes open source under Apache 2.0. • 2014 all of BridgePoint (including Verifier and model compilers) goes open source under Apache and Creative Commons. • 2015 Papyrus Industry Consortium and xtUML/BridgePoint contribution • 2015 OSS of alternate generator engine (community building) • 2016 Papyrus-xtUML (BridgePoint) Eclipse Foundation governance • 2016 OSS contributions from industry, university and individuals [email protected] 6 Key Players • Saab • UK Crown • Agilent • Ericsson • Fuji-Xerox • Academia [email protected] 7 Current State • body of IP • self-hosng • Papyrus (and Papyrus Industry Consor)um) [email protected] 8 Related Dialects • MASL • Alf • UML-RT [email protected]
    [Show full text]
  • Using the UML for Architectural Description?
    Using the UML for Architectural Description? Rich Hilliard Integrated Systems and Internet Solutions, Inc. Concord, MA USA [email protected] Abstract. There is much interest in using the Unified Modeling Lan- guage (UML) for architectural description { those techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. IEEE P1471, the Recommended Practice for Architectural Description, represents an emerging consensus for specifying the content of an architectural descrip- tion for a software-intensive system. Like the UML, IEEE P1471 does not prescribe a particular architectural method or life cycle, but may be used within a variety of such processes. In this paper, I provide an overview of IEEE P1471, describe its conceptual framework, and investigate the issues of applying the UML to meet the requirements of IEEE P1471. Keywords: IEEE P1471, architectural description, multiple views, view- points, Unified Modeling Language 1 Introduction The Unified Modeling Language (UML) is rapidly maturing into the de facto standard for modeling of software-intensive systems. Standardized by the Object Management Group (OMG) in November 1997, it is being adopted by many organizations, and being supported by numerous tool vendors. At present, there is much interest in using the UML for architectural descrip- tion: the techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. Such techniques enable architects to record what they are doing, modify or ma- nipulate candidate architectures, reuse portions of existing architectures, and communicate architectural information to others. These descriptions may the be used to analyze and reason about the architecture { possibly with automated support.
    [Show full text]
  • A Prolog-Based Proof Tool for Type Theory Taλ and Implicational Intuitionistic-Logic
    A Prolog-based Proof Tool for Type Theory TAλ and Implicational Intuitionistic-Logic L. Yohanes Stefanus University of Indonesia Depok 16424, Indonesia [email protected] and Ario Santoso∗ Technische Universit¨atDresden Dresden 01187, Germany [email protected] Abstract Studies on type theory have brought numerous important contributions to computer science. In this paper we present a GUI-based proof tool that provides assistance in constructing deductions in type theory and validating implicational intuitionistic-logic for- mulas. As such, this proof tool is a testbed for learning type theory and implicational intuitionistic-logic. This proof tool focuses on an important variant of type theory named TAλ, especially on its two core algorithms: the principal-type algorithm and the type inhabitant search algorithm. The former algorithm finds a most general type assignable to a given λ-term, while the latter finds inhabitants (closed λ-terms in β-normal form) to which a given type can be assigned. By the Curry{Howard correspondence, the latter algorithm provides provability for implicational formulas in intuitionistic logic. We elab- orate on how to implement those two algorithms declaratively in Prolog and the overall GUI-based program architecture. In our implementation, we make some modification to improve the performance of the principal-type algorithm. We have also built a web-based version of the proof tool called λ-Guru. 1 Introduction In 1902, Russell revealed the inconsistency in naive set theory. This inconsistency challenged the foundation of mathematics at that time. To solve that problem, type theory was introduced [1, 5]. As time goes on, type theory becomes widely used, it becomes a logician's standard tool, especially in proof theory.
    [Show full text]
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007
    OMG Systems Modeling Language (OMG SysML™) Tutorial 25 June 2007 Sanford Friedenthal Alan Moore Rick Steiner (emails included in references at end) Copyright © 2006, 2007 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Status • Specification status – Adopted by OMG in May ’06 – Finalization Task Force Report in March ’07 – Available Specification v1.0 expected June ‘07 – Revision task force chartered for SysML v1.1 in March ‘07 • This tutorial is based on the OMG SysML adopted specification (ad-06-03-01) and changes proposed by the Finalization Task Force (ptc/07-03-03) • This tutorial, the specifications, papers, and vendor info can be found on the OMG SysML Website at http://www.omgsysml.org/ 7/26/2007 Copyright © 2006,2007 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should have an awareness of: • Benefits of model driven approaches for systems engineering • SysML diagrams and language concepts • How to apply SysML as part of a model based SE process • Basic considerations for transitioning to SysML This course is not intended to make you a systems modeler! You must use the language. Intended Audience: • Practicing Systems Engineers interested in system modeling • Software Engineers who want to better understand how to integrate software and system models • Familiarity with UML is not required, but it helps 7/26/2007 Copyright © 2006,2007 by Object Management Group. 3 Topics • Motivation & Background • Diagram Overview and Language Concepts • SysML Modeling as Part of SE Process – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 7/26/2007 Copyright © 2006,2007 by Object Management Group.
    [Show full text]
  • Introduction: C++ and Software Engineering
    Comp151 Introduction Background Assumptions • This course assumes that you have taken COMP102/103, COMP104 or an equivalent. The topics assumed are: – Basic loop constructs, e.g., for, while, repeat, etc. – Functions –Arrays – Basic I/O – Introduction to classes – Abstract Data Types – Linked Lists – Recursion – Dynamic Objects Why Take This Course You all know how to program, so why take this course? • In COMP104 you essentially only learned “the C part” of C++ and can write “small” C++ programs. • Most of the time you write code that is (almost) the same as code that’s been written many times before. How do you avoid wasting time “re-inventing the wheel”? How do you re-use coding effort? • What if you need to write a large program and/or work with a team of other programmers? How do you maintain consistency across your large program or between the different coders? • In this course you will learn the essence of Object Oriented Programming (OOP). The goal is to teach you how to design and code large software projects. A Short “History” of Computing • Early programming languages (e.g., Basic, Fortran) were unstructured. This allowed “spaghetti code” – code with a complex and tangled structure - with goto’s and gosub’s jumping all over the place. Almost impossible to understand. • The abuses of spaghetti code led to structured programming languages supporting procedural programming (PP) – e.g., Algol, Pascal, C. • While well-written C is easier to understand, it’s still hard to write large, consistent code. This inspired researchers to borrow AI concepts (from knowledge representation, especially semantic networks) resulting in object-oriented programming (OOP )languages (e.g., Smalltalk, Simula, Eiffel, Objective C, C++, Java).
    [Show full text]
  • VI. the Unified Modeling Language UML Diagrams
    Conceptual Modeling CSC2507 VI. The Unified Modeling Language Use Case Diagrams Class Diagrams Attributes, Operations and ConstraintsConstraints Generalization and Aggregation Sequence and Collaboration Diagrams State and Activity Diagrams 2004 John Mylopoulos UML -- 1 Conceptual Modeling CSC2507 UML Diagrams I UML was conceived as a language for modeling software. Since this includes requirements, UML supports world modeling (...at least to some extend). I UML offers a variety of diagrammatic notations for modeling static and dynamic aspects of an application. I The list of notations includes use case diagrams, class diagrams, interaction diagrams -- describe sequences of events, package diagrams, activity diagrams, state diagrams, …more... 2004 John Mylopoulos UML -- 2 Conceptual Modeling CSC2507 Use Case Diagrams I A use case [Jacobson92] represents “typical use scenaria” for an object being modeled. I Modeling objects in terms of use cases is consistent with Cognitive Science theories which claim that every object has obvious suggestive uses (or affordances) because of its shape or other properties. For example, Glass is for looking through (...or breaking) Cardboard is for writing on... Radio buttons are for pushing or turning… Icons are for clicking… Door handles are for pulling, bars are for pushing… I Use cases offer a notation for building a coarse-grain, first sketch model of an object, or a process. 2004 John Mylopoulos UML -- 3 Conceptual Modeling CSC2507 Use Cases for a Meeting Scheduling System Initiator Participant
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • APECS: Polychrony Based End-To-End Embedded System Design and Code Synthesis
    APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson Dissertation submitted to the faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Engineering Sandeep K. Shukla, Chair Lamine Mili Alireza Haghighat Chao Wang Yi Deng April 3, 2015 Blacksburg, Virginia Keywords: AADL, CPS, Model-based code synthesis, correct-by-construction code synthesis, Polychrony, code generators, OSATE, Ocarina Copyright 2015, Matthew E. Anderson APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson (ABSTRACT) The development of high integrity embedded systems remains an arduous and error-prone task, despite the efforts by researchers in inventing tools and techniques for design automa- tion. Much of the problem arises from the fact that the semantics of the modeling languages for the various tools, are often distinct, and the semantics gaps are often filled manually through the engineer's understanding of one model or an abstraction. This provides an op- portunity for bugs to creep in, other than standardising software engineering errors germane to such complex system engineering. Since embedded systems applications such as avionics, automotive, or industrial automation are safety critical, it is very important to invent tools, and methodologies for safe and reliable system design. Much of the tools, and techniques deal with either the design of embedded platforms (hardware, networking, firmware etc), and software stack separately. The problem of the semantic gap between these two, as well as between models of computation used to capture semantics must be solved in order to design safer embedded systems.
    [Show full text]
  • Systems Engineering with Sysml/UML Morgan Kaufmann OMG Press
    Systems Engineering with SysML/UML Morgan Kaufmann OMG Press Morgan Kaufmann Publishers and the Object Management Group™ (OMG) have joined forces to publish a line of books addressing business and technical topics related to OMG’s large suite of software standards. OMG is an international, open membership, not-for-profi t computer industry consortium that was founded in 1989. The OMG creates standards for software used in government and corporate environments to enable interoperability and to forge common development environments that encourage the adoption and evolution of new technology. OMG members and its board of directors consist of representatives from a majority of the organizations that shape enterprise and Internet computing today. OMG’s modeling standards, including the Unifi ed Modeling Language™ (UML®) and Model Driven Architecture® (MDA), enable powerful visual design, execution and maintenance of software, and other processes—for example, IT Systems Modeling and Business Process Management. The middleware standards and profi les of the Object Management Group are based on the Common Object Request Broker Architecture® (CORBA) and support a wide variety of industries. More information about OMG can be found at http://www.omg.org/. Related Morgan Kaufmann OMG Press Titles UML 2 Certifi cation Guide: Fundamental and Intermediate Exams Tim Weilkiens and Bernd Oestereich Real-Life MDA: Solving Business Problems with Model Driven Architecture Michael Guttman and John Parodi Architecture Driven Modernization: A Series of Industry Case Studies Bill Ulrich Systems Engineering with SysML/UML Modeling, Analysis, Design Tim Weilkiens Acquisitions Editor: Tiffany Gasbarrini Publisher: Denise E. M. Penrose Publishing Services Manager: George Morrison Project Manager: Mónica González de Mendoza Assistant Editor: Matt Cater Production Assistant: Lianne Hong Cover Design: Dennis Schaefer Cover Image: © Masterfile (Royalty-Free Division) Morgan Kaufmann Publishers is an imprint of Eslsevier.
    [Show full text]
  • LIGO Data Analysis Software Specification Issues
    LASER INTERFEROMETER GRAVITATIONAL WAVE OBSERVATORY - LIGO - CALIFORNIA INSTITUTE OF TECHNOLOGY MASSACHUSETTS INSTITUTE OF TECHNOLOGY Document Type LIGO-T970100-A - E LIGO Data Analysis Software Specification Issues James Kent Blackburn Distribution of this draft: LIGO Project This is an internal working document of the LIGO Project. California Institute of Technology Massachusetts Institute of Technology LIGO Project - MS 51-33 LIGO Project - MS 20B-145 Pasadena CA 91125 Cambridge, MA 01239 Phone (818) 395-2129 Phone (617) 253-4824 Fax (818) 304-9834 Fax (617) 253-7014 E-mail: [email protected] E-mail: [email protected] WWW: http://www.ligo.caltech.edu/ Table of Contents Index file /home/kent/Documents/framemaker/DASS.fm - printed July 22, 1997 LIGO-T970100-A-E 1.0 Introduction The subject material discussed in this document is intended to support the design and eventual implementation of the LIGO data analysis system. The document focuses on raising awareness of the issues that go into the design of a software specification. As LIGO construction approaches completion and the interferometers become operational, the data analysis system must also approach completion and become operational. Through the integration of the detector and the data analysis system, LIGO evolves from being an operational instrument to being an operational grav- itational wave detector. All aspects of software design which are critical to the specifications for the LIGO data analysis are introduced with the preface that they will be utilized in requirements for the LIGO data analysis system which drive the milestones necessary to achieve this goal. Much of the LIGO data analysis system will intersect with the LIGO diagnostics system, espe- cially in the areas of software specifications.
    [Show full text]