Rick Kok 3399540 INFOME BUSINESS INFORMATICS UNIVERSITEIT UTRECHT
Introduction The paper MaRMI-RE : Systematic Componentization Process for Reengineering Legacy System, written by Jung-Eun Cha and Chul-Hong Kim, writes about legacy systems, which at a certain time have been written for a specific purpose, but whose purpose has slightly changed during the years it has been operational, e.g. by the upcoming e-business, which possibly did not exist during the time of development of the system. Also, the technology or the industry model might be changed. To adept the existing ('legacy') system to the changing needs, it may be required to re-engineer parts of the system, so new functions can be added. They developed a method called MaRMI-RE (Magic and Robust Methodology Integrated-ReEngineering), to help re-engineering legacy systems. Illustration 1 shows a visual representation of the model. The yellow squares show the steps, the purple arrows point to the knowledge area within the legacy system.
Illustration 1: Conceptual model of MaRMI-RE (Cha, J. and Kim, C., 2005) The main difference to other methods (see: related literature) is the architecture base. It will extract the architecture of the legacy system out of the system functions and business domain knowledge, and convert it into a new architecture needed for the new system. In this manner, old, legacy, code can be reused, changing the technical and business aspects of the program to new needs. According to Jung-Eun Cha and Chul-Hong Kim (2005), the MaRMI-RE componentization process has been used twice in case studies. One case study is about converting a COBOL machine within the textile industry, another case study about a banking system running with 124 different COBOL programs.
Example There are two case studies which can be used as examples, but I unfortunately could not find the studies. Because the model is actually a guideline to re-engineer an existing system, an example cannot be given due to the complexness of it. Therefore, the components and of the model will be explained in this paper (note: only a short description of methods takes a lot of words; therefore it will take more than one page. Some aspects of the model will be literally the same as in the paper from Jung-Eun Cha and Chul-Hong Kim (2005), because they created the model, and rewriting will not make the aspects more clear or more readable.)
Illustration 2: MaRMI-RE model devided in phases The system consists of four phases, as can be seen in Illustration 2. Beginning south and clockwise, ending east, the first phase is Planning, followed by Re-engineering, Componentization and Transfer. The phases including their sub phases will be explained in this chapter. MaRMI-RE exists of four main phases: − − − −
Planning phase Re-engineering phase Componentization phase Transfer phase.
The last phase, the transfer phase, is not specific designed for the MaRMI-RE method, it will not be explained. The rest of the phases will be explained shortly below. If some deliverable is produced, the type of deliverable will stand just below the phase title. The actions to be taken to get that deliverable or to fulfill the phase task will be written below the deliverable or the title of the phase.
1. Planning phase The planning phase involves researching whether one should start with the re-engineering, and to be prepared. It presents you a re-engineering direction. During the planning phase, the direction will be improved, and the deliverable of the planning phase is a development plan. 1. Current situation grasping activity Deliverable: Analysis of the current situation, understanding the systems, subsystems and work within the organization. - Analyze configuration and work flow of the organization - List greatest issues the organization is dealing with - Understand the working and functioning of the (sub) systems - Analyze maintenance and management of legacy system 2. Improvement business model derivation activity Deliverable: Architecture (model) of business area; improved business model. - Create business improvement model by creating a requirements list of parties involved in the system by creating use cases and business object modeling - Determine the purpose and scope of the project based on business improvement model 3. Improvement strategy establishment activity Deliverable: Optimal approach method to perform re-engineering - Select system components to re-engineer - Analyze components from business value and system standpoint, with respect to work units - Determine re-engineering priority - Create transformation strategy 4. Development plan establish activity Deliverable: Draft develop plan - Analyze which of the items from the previous tasks will be applied to the development process - Create a development plan by collecting and arranging the analyzed items 2. Reverse engineering phase Target: Better understand static and dynamic action information. This can be achieved by analyzing the legacy system; architectural information like relationships between components should be understood and extracted. Then a model is made, consisting of an abstracted analysis of design information formed code semantics. 1. Program analysis activity Deliverable: Normalize overview of semantic and syntax information from source code - Analyze and extract syntax and semantic information from legacy program by source code restructuring - Analyze all of the data and control flows - Create normalized overview of the above information using relationship diagram 2. Design information understanding activity Deliverable: Structural diagram containing design information of the legacy system and abstracted modeling results Target: Identify functional unit processes, based on program analysis information - Specify control flow and data flow between unit processes - Provide system design information for architecture 3. Architecture understanding activity Target: Improve structural, technical and behavioral understanding of the architecture legacy system. - Analyze subsystems: how are call relations between them made? - Abstract the results: what do they tell about modules or the legacy system as whole?
3. Componentization phase Target: Transforming legacy system source code and architecture into the new (to-be) system. 1. Component mining activity The legacy system will be divided into parts performing a specific function, and each component will be grasped and extracted. 1. Component grasp Deliverable: Interrelation modeling table; Use case analysis table; Component entity description report - Use case related system entity grasp - Use case analysis - Component candidate gasp 2. Component extraction Deliverable: Component list table/interaction table/entity description report; Application use case/component correspondence table - Sharing element grasp - Component extraction - Grasp of interrelations/interactions between components 3. Component identification Deliverable: Component list table; Business use case/component correspondence table - Component candidate grasp - Component extraction 4. Component evaluation Deliverable: Component list table – component interaction table; application use case/component or business use case/component correspondence table - Establishment of component utility strategy, and evaluation criteria for utility strategy - Component evaluation - Readjustment of interrelations/interactions between components 2. Architecture transformation activity In this part the legacy system will be transformed in 1. Transformation strategy examination Deliverable: Transformation strategy examination report; Improvement strategy establishment report - Transformation strategy readjustment - Refinement of improvement strategy establishment report of target system 2. Software architecture definition Deliverable: Architecture information analysis report; Architecture functionality list table; Architecture quality attributes list table; Quality scenario - Architecture analysis information examination - Definition of functional requirements of target system - Quality attribute derivation - Architecture structure setting - Software architecture definition 3. System architecture definition Deliverable: Technical architecture; Component architecture; System architecture - Technical architecture definition - Component architecture definition - System architecture definition 3. Component transformation activity The purpose of the component transformation activity is to
- identify the extracted components' interfaces, - design the internal structure - identify operations of component interfaces based on dynamic message flow information between classes 1. Scenario design Deliverable: Use case specification - Drafting of normal scenario according to use case - Drafting of selective scenario according to use case - Drafting of exceptional scenario according to use case 2. Interaction design Deliverable: Component interaction diagram - Use case selection and actor placement - Object or entity arrangement - Message identification - Interaction diagram drafting 3. Component interior design Deliverable: Class diagram; Component diagram - Class extraction - Method and attribute grasp - Relation setting - Class allocation according to component 4. Component interface design Deliverable: Component specification; Component diagram (refinement) - Use case based interface identification - Data-based interface identification - Interface refinement - Interface details - Component details 5. Component detailed design Deliverable: Component detailed design report - Package definition - EJB mapping definition - Continuity design - Transaction design - Security design - Arrangement design 4. Component development activity Components will be built using the pieces of information extracted through the component transformation activity. Then it will be tested. 5. Component integration test activity In this phase, the integration of components is tested. Do they normally communicate with each other? 4. Transfer phase 1. Train user 2. Install system 3. Acceptance test and system observation 4. Transfer system
Example of Application Use Case Diagram As you can see in Illustration 3, this is an example of an application use case diagram, extracted from any business. Because almost no case studies have been done, it is only possible to provide an example.
Illustration 3: An Application Use Case Diagram (Walter Dosch, Roger Y. Lee, Chisu Wu, (2005))
Related literature According to the authors of the MaRMI-RE model, their method is built on the Horse Shoes meta model of CORUM II. To better understand this claim, we will first have a look at the CORUM (Common Object Based Re-engineering method). This method was based on experiences of “creating a data model for interoperability between several re-engineering toolsets” (Kazman, Woods & Carriere, 1998, p. 1), and it helped engineers use combining the strengths of different re-engineering techniques by means of this model. It had been a unification point for many re-engineers and later it became “a broader model for interchanging re engineering information and eventually, for creating a larger family of interoperable engineering tools” (Kazman, Woods & Carriere, 1998, p. 1). The model prevented some re-inventing of the wheel, as it created an inter-tool information sharing standard for the small re-engineer community. Some methods used by CORUM are − Abstract Syntax Trees (ASTs) − Control Flow Graphs (CGGs) − Data Flow Graphs (DFGs) However, as systems became more smart and abstract, so did the architecture. Soon people realized that a newer form of the CORUM method was needed; Kazman, Woods & Carriere (1998) created that model, they called it CORUM II. They basically added the abstract software architectural layer to it, following a bottom up way of re-engineering, followed by a top-down way of engineering the new architecture based development (which has the form of a horse shoe in their model). Also very important is the use of semantics within the model. Now it no longer depends on the code, but also on meaning of the functions. Jung-Eun Cha and Chul-Hong Kim (2005) built upon this model to more concretely define the reengineering techniques and procedures of the CORUM II Illustration 4: CORUM II: The Horseshoe Model (Kazman et al, 1998) model. They state that guidelines are missing, and because of that, users depend on making their own decisions. Walter Dosch, Roger Y. Lee, Chisu Wu (2005) show that it is possible to re-engineer old COBOL based systems to new purposes. Due to the relatively small amount of re-engineering being done, a lot of case studies are still to be done.
References Abowd, G., Goel, A., Jerding, D. F., McCracken, M., Moore, M., Murdock, J. W., (...) Wills, L. (1997). MORALE: Mission Oriented Architectural Legacy Evolution, Georgia Institute of Technology Cha, J. and Kim, C. (2005). MaRMI-RE : Systematic Componentization Process for Reengineering Legacy System, paper presented at ICCSA, Heidelberg, Berlin, Springer-Verlag, pp.896-905. Kazman, R., & Carriere, S. (1997). Playing Detective: Reconstructing Software Architecture from Available Evidence (CMU/SEI-97-TR-010). Retrieved February 15, 2013, from the Software Engineering Institute, Carnegie Mellon University website: http://www.sei.cmu.edu/library/abstracts/reports/97tr010.cfm Kazman, R., Woods, S. G., & Carriere, S. J. (1998). Requirements for integrating software architecture and reengineering models: Corum ii. Informally published manuscript, Carnegie Mellon University, Pittsburgh, Retrieved from http://www.sei.cmu.edu/library/assets/wcrekazman1998.pdf Kazman, R., Woods, S. G., & Carriere, S. J. (1999). Software Architectural Transformation. Informally published manuscript, Carnegie Mellon University, Pittsburgh, Retrieved from http://www.sei.cmu.edu/library/assets/wcrekazman1999.pdf Walter Dosch, Roger Y. Lee, Chisu Wu, (2005). MaRMI-RE: a Method and Tools for Legacy System Modernization. Software Engineering Research, Management and Applications. 1st ed. Berlin, Germany: Springer. pp.51-54. Woods, S., O’Brien, L., Lin, T., Gallagher, K., and Quilici, A (1998). An Architecture For Interoperable Program Understanding Tools. In Proceedings of the Sixth International Conference on Program Comprehension. Sagarin, B. J., & Lawler-Sagarin, K. A. (2005). Critically evaluating competing theories: An exercise based on the Kitty Genovese murder. Teaching of Psychology, 32(3), 167–169.
