An Example of Code Refactoring with Legacy Code in a Flight Model Software

Transcription

1 An Example of Code Refactoring with Legacy Code in a Flight Model Software Eric Shi H. Peter Stassen, Mentor The MITRE Corporation TJHSST Computer Systems Lab, January 11, 2008 Abstract As software code ages, it becomes increasingly important for it easily to be maintained and understood by programmers who may work with the code. Modern software may utilize legacy code for the purpose of supporting specific features. Therefore, refactoring techniques must be applied to the code to ease the process of implementing future modifications. Refactoring emphasizes improving the design of an already-written piece of code without changing its function. This project seeks to apply refactoring techniques to components of the flight model software used at the Air Traffic Management Lab at the MITRE Corporations Center for Advanced Aviation System Development. Keywords: Design patterns, flight simulation, legacy code, refactoring 1

2 Contents 1 Introduction 3 2 Background 4 3 Simflight Design Target Generation Module Structure Procedure Cataloging of Global Variables Data Classes Move to C C++ Coding Conventions Application of a Design Pattern Testing and Analysis Results and Conclusion 7 Appendix 8 References 10 Acknowledgments 11 2

3 1 Introduction In the simulation and modeling industry, many companies continue to use aging pieces of code in their programs simply because the code performs its function correctly. From a management perspective, there is no need to direct programmers to rewrite code that already works. Legacy code, however, may be inefficient, inflexible, and difficult to maintain as programmers take advantage of newer programming languages and techniques. The Air Traffic Management (ATM) Lab at the MITRE Corporations Center for Advanced Aviation System Development in McLean, Virginia conducts research from the perspective of National Airspace System stakeholders. This group includes the flight crew, air traffic controllers, and air traffic managers. The purpose of conducting such research is to gather both quantitative data and qualitative data via human feedback from simulations. This helps evaluate and mature new concepts to build an industry consensus. This project concerns the cockpit simulator of the ATM Lab, a fixed-base, medium fidelity generic air-transport category airplane. This simulator can implement new instrumentation and software rapidly and has data collection capability. The programmers at the cockpit portion of the ATM Lab have been continually modifying the cockpit component of the flight simulator software since its inception in 1993 without a comprehensive rework of its basic design. The code, originally written in C, was designed to run across the network on multiple machines due to processor limitations at the time and did not utilize an object-oriented design. Software design decays as programmers change a program to realize short-term goals. Today, the programmers have noticed that the code has become difficult to manage and that interprocess communications have proliferated in the form of redundant data structures. The purpose of this project is to refactor and rework the fltsim module in the ATM Lab Cockpit Simulator. Refactoring is important in the software design process because it ensures maintainability and readability in code. The software is changed such that its internal structure is improved, but its function remains the same. The C code used in the modules needs to be updated to meet todays programming standards, such as object-oriented design and naming conventions. This project develops skills in working with a mature software system, implementing design patterns, and learning to refactor software for maintainability. While refactoring software does not necessarily result in an expected performance gain and only affects the programmers who work directly with the code, it is expected to make the product cheaper to maintain over time compared to a non-refactored program. The result of this project is a single module in C++ which utilizes object oriented design, meets todays programming standards, and can be easily maintained in the future. 3

4 2 Background Refactoring is a practice that is specific to software engineering. It is difficult to identify the origin of the term refactoring, and the process of improving code after it has been written has been recognized and practiced since the 1980 s. Some programmers habitually practice refactoring, while others view it as a new concept. The first dissertation on refactoring, Refactoring Object-Oriented Frameworks, was published in 1992 by William Opdyke, which examines refactorings useful for object-oriented C++ frameworks [5]. This paper is known as the most substantial work on this subject [2]. Another comprehensive resource is Refactoring: Improving the Design of Existing Code by Martin Fowler, originally published in This book identifies principles of refactoring and discusses over 70 refactorings. The Extract Method is a refactoring in which a code fragment in a particularly long method is turned into its own method. The purpose of the Extract Method is to improve code clarity. If a switch statement chooses different behavior depending on object type, then the Replace Conditional with Polymorphism can be applied. This refactoring moves each set of actions into a method in the class of the corresponding object. Different situations call for different refactorings. Design patterns is a practice separate from refactoring, but relevant to code design. They are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. The important aspect of design patterns is that they are solutions to general problems that occur in software design, so the same pattern can be applied in a variety of scenarios [3]. Many design patterns are based on object-oriented designs, so it would be appropriate to apply design patterns in this project in the rewriting of C code in C++. In programming environments, many developers may work on a piece of code. Therefore, there is a need for a consistent writing style throughout the code. Code consistency brings maintainability, robustness, and fewer bugs. Conventions for formatting, naming, documentation, programming, and packaging are important when striving for efficient code, especially in teams. Although there is no official set of conventions, many books on programming style offer suggestions. For the purposes of refactoring fltsim, The Elements of C++ Style by Trevor Misfeldt, Gregory Bumgardner, and Andrew Gray is used [4]. 3 Simflight Design 3.1 Target Generation Fltsim is a module that comprises the actual flight model in the cockpit simulator. It is a simulation event generator and a client of the Generic Target Generator (GTG), which is a simplified framework for Integrated Target Protocol (ITP) applications. Target generation refers to the creation of simulated aircraft among the multiple applications that comprise 4

5 a simulation. ITP facilitates the communication of target data to applications that require information updates for the target. The implication of using GTG is that the main loop GTG clients is in GTG and only defines the callback functions for the framework. The entire simulation is controlled by a central application, the Central Simulation Manager (CSM). It allows the user to define the applications involved in a simulation run and starts, pauses, and stops the applications simultaneously. A user can also define the networked computers on which different applications run. An important role of CSM is to ensure that the clocks in each application are synchronized throughout the entire simulation run. The refactored version of fltsim is called simflight. 3.2 Module Structure GTG requires fltsim to specify functions so that the application can be run properly: an internal initialization, an external initialization, check events, timeout, pause, resume, shutdown, and handle message. The module is further divided among components that create representations of aircraft, terrain, atmosphere, data collection, and more. In total, fltsim contains 36 files. These models communicate through data structures (structs) that are passed around in intercommunication functions. By introducing an object-oriented design, class representations of these components were created and the intermediate data structures were replaced with a set of data classes. 4 Procedure 4.1 Cataloging of Global Variables The first step in refactoring fltsim was to go through every file in fltsim and record the variables that would be preserved in the refactored module. These variables, found at the global scope, represented information that fltsim components and other ITP applications require to function, such as indicated airspeed (IAS), aircraft nose direction, pitch rate, etc. These variables were later placed in data objects, according to a new design. Fltsim had nearly 750 documented global variables. 4.2 Data Classes The most significant feature of the new simflight module is the way data is set and accessed. Simflight data is divided among various classes, depending on what the data describes. Specifically, the classes are divided according to an industry-wide standard for numbering aircraft systems, the ATA system. ATA Chapter 22 is the Auto Flight system, so variables related to Auto Flight would be found in FsDataAta22. With the data in a centralized location, the global interprocess structs were replaced by direct access to the data classes. By 5

6 restricting initialization of each data class to a single instance, it is ensured that all simflight components have access the same set of data. Therefore all functions that replicated data structures were removed from fltsim. It should be noted that the sole purpose of these data classes is to store variables, so they do not contain any functions other than the constructor and the destructor. 4.3 Move to C++ The refactoring of the fltsim module also involved a rewrite of C code into C++. It is important to note that changing the language in which a program is written per se does not qualify as a refactoring. The important aspect of rewriting fltsim in C++ was that it made the new design possible. C++ also increases the range of applicable design patterns and future refactorings. Corresponding.h and.cpp files for every fltsim component and their respective functions were written. In extreme cases, functions had to be created from C macros (Figures 1 and 2). By using the C++ Standard Template Library (STL), char arrays were replaced by std::string statements. Although char arrays were replaced, there remain several instances in the refactored code in which c_str() must be called in order to send a string to a GTG or ITP callback. With native support in C++ for boolean data with bool, true, and false keywords, preprocessor macros defining FALSE as 0 and TRUE as 1 were eliminated C++ Coding Conventions 4.4 Application of a Design Pattern A problem that occurred was that multiple copies of models would be created by components that did not check for an already existing instance. Not only was spawning multiple FlightDynamic models nonsensical, but it also introduced pointer access errors. Therefore, a design pattern was used to solve the problem of restricting instantiations of a class to a single instance, the Singleton Pattern. The Singleton Pattern solves this problem because it makes the class responsible for keeping track of its instance. By calling the Instance function of a model, the class checks to see if there is an existing instance (Figure 3). If one does not exist, it calls the constructor to create an one and returns the pointer. If an instance exists, it simply returns the pointer to the object. To restrict access to a model s constructors, various functions were declared at the protected level. To take advantage of inheritance in C++, the simulation models (FsAeroynamics, FsAircraft, FsAtmosphere, FsControlModel, FsEngine, FsFlightDyanmics, FsTerrain, and FsWind) were declared as derivations of the base class FsModel (Figure 4). 6

7 4.5 Testing and Analysis 5 Results and Conclusion 7

8 Appendix System Codes 21 Air Conditioning 36 Pneumatic 22 Auto Flight 38 Water/Waste 23 Communications 44 Cabin Systems 24 Electrical Power 45 Central Maintenance Computer 25 Equipment/Furnishings 46 Information Systems 26 Fire Protection 49 Airborne Auxiliary Power 27 Flight Controls 52 Doors 28 Fuel 56 Windows 29 Hydraulic Power 73 Engine Fuel and Control 30 Ice and Rain Protection 74 Ignition 31 Indicating/Recording Systems 75 Bleed Air 32 Landing Gear 77 Engine Indicating 33 Lights 78 Engine Exhaust 34 Navigation 79 Engine Oil 35 Oxygen 80 Starting Table 1: ATA Chapter Codes [1] #define CF_Open(filen) { \ FILE *fp=null; \ if ((fp = fopen(filen, "r")) == NULL) { \ char config_fname[256]; \ sprintf(config_fname, "config/%s", filen); \ if ((fp = fopen(config_fname, "r")) == NULL) { \ fprintf(stderr, "Unable to open %s, trying to continue...\n", filen); \ } \ } \ if (fp!= NULL) { \ char config_word[21]; \ while (fscanf(fp, "%s", config_word)!= EOF) { \ if (*config_word == # ) { \ Read_To_Eoln(fp) Figure 1: Code fragment from config.h 8

9 void FsAircraft::initStructuralModel(FsConfigList::ConfigListRec *configrec) {... std::fstream ifile(("../config/"+configrec->m_filename).c_str(), std::ios::in); if (!ifile) { std::cout << "ERROR: " << configrec->m_filename.c_str() << " not found." << std::endl; return; } while (!ifile.eof()) {... }... } Figure 2: The refactored code in a FsAircraft initialization function FsModel* FsModel::Instance() { static FsModel inst; return &inst; } Figure 3: Code snippet of the Instance function from FsModel.cpp class FsEngine: public FsModel { public:... protected: FsEngine(); ~FsEngine(); FsEngine(const FsEngine&); FsEngine& operator = (const FsEngine&); }; Figure 4: FsEngine inherits the Instance function from FsModel 9

10 References [1] Eitel, James M. Table of Contents. Boeing 777 Master Minimum Equipment List. I-II. [2] Fowler, Martin. Principles in Refactoring. Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley, [3] Gamma, Erich, et al. Introduction. Design Patterns: Elements of Reusable Object- Oriented Software. By Gamma, et al.. Boston: Addison-Wesley, [4] Misfeldt, Trevor, Gregory Bumgardner, and Andrew Gray. The Elements of C++ Style. Cambridge, United Kingdom: Cambridge University Press, [5] Opdyke, William F. Refactoring Object-Oriented Frameworks. Diss. U of Illinois at Urbana-Champaign, Acknowledgments 10