Comparative Study on DFD to UML Diagrams Transformations

World of Computer Science and Information Technology Journal(WCSIT) ISSN: 2221-0741 Vol. 1, No.1,10-16, 2011. Comparative Study on DFD to UML Diagrams Transformations Atif A. A. Jilani Muhammad Usman Aamer Nadeem National University of Computer Mohammad Ali Jinnah University Islamabad Mohammad Ali Jinnah University Islamabad and Emerging Sciences, Islamabad [email protected] [email protected] [email protected] Zafar I. Malik Academy of Education & Planning, Ministry of Education, Pakistan [email protected] Zahid Halim National University of Computer and Emerging Sciences, Islamabad [email protected] Abstract—Most of legacy systems use nowadays were modeled and documented using structured approach. Expansion of these systems in terms of functionality and maintainability requires shift towards object-oriented documentation and design, which has been widely accepted by the industry. In this paper, we present a survey of the existing Data Flow Diagram (DFD) to Unified Modeling language (UML) transformation techniques. We analyze transformation techniques using a set of parameters, identified in the survey. Based on identified parameters, we present an analysis matrix, which describes the strengths and weaknesses of transformation techniques. It is observed that most of the transformation approaches are rule based, which are incomplete and defined at abstract level that does not cover in depth transformation and automation issues. Transformation approaches are data centric, which focuses on datastore for class diagram generation. Very few of the transformation techniques have been applied on case study as a proof of concept, which are not comprehensive and majority of them are partially automated. Keywords-Unified Modeling Language (UML); Data Flow Diagram (DFD); Class Diagram; Model Transformation. I. machine, and ER diagram are also there, but DFD has certain advantages over them. DFD is the primary artifact and INTRODUCTION Most of the legacy systems in use nowadays were modeled and documented using structured approach [1]. These systems were developed in languages that have become out-dated now. With the passage of time, systems demand numerous modifications, expansion in terms of functionality and incorporation of latest high-speed hardware. Still, legacy systems are reliable enough and considered irreplaceable by the user. However, it is possible to modify system code but modifications in the code add inconsistencies between code and design and system design becomes no longer usable for future maintenance. Besides, modifying such a system is also very costly, the only viable solution for up-gradation and maintenance is to preserve system design and incorporate it with latest software development strategies as described by Newcombe and Doblar [2]. is required be created for every systems in structured approach. DFD has hierarchal structure, which provides different abstraction level, useful in system designing. Besides, DFD is such a fundamental artifact that clearly depicts the structure of a system. Other artifacts use the information provided by the DFD to represent dynamic aspect of the system [3]. Structured design techniques have been replaced by objectoriented analysis and design approach, which has gained popularity now and majority of the software modeling and development techniques are adopting this paradigm [4]. With the passage of time, the level of abstraction in system development has raised. Object Management Group (OMG) has been recently promoting a new vision for software development, i.e., Model Driven Architecture (MDA) [5]. In MDA, main emphasis is on modeling design separately from the implementation (platform). MDA encourages the use of Platform Independent Model (PIM) and Platform Specific Model (PSM) to represent platform independent and platform specific details. Soul of MDA is transformation between models. In MDA, code may be generated either from PSM or from the PIM. Model transformations can be between PIM and PSM, PIM and code or between PSM and code. For modeling object-oriented systems and model creation, Unified Modeling Language (UML) [6] has now become the de-facto industry standard [7-8]. UML is a collection of diagrams used to model If running system code is available, it is possible to generate design from code. However, if the code is modified numerous times, the generated design and original design may become inconsistent. Design recovery from such code is ambiguous and no more useful for future up-gradation and maintenance. Like Dietrich et al. [3], we also consider legacy systems irreplaceable and trusted by the users. We, too, emphasize on saving legacy system by providing and using an object-oriented interface. A major design artifact in structured approach is the Data Flow Diagram (DFD). Other artifacts like structure chart, state 10 WCSIT 1 (1), 10 -16, 2011 [17] propose an approach that recover class diagram from data different aspects of object oriented software. UML Class intensive legacy system code. diagram is one of a major artifact in object-oriented design used to represent the system’s static structure. Other UML It is apparent that many of the discussed techniques are diagrams, like sequence diagram, state machine, and activity effective only for data centric systems. For our approach, we diagram etc, are used to model the system’s dynamic behavior. are firmly interested in structured design instead of code. In design, we have observed that in literature, both structured In this paper, we present a survey of transformation design to non-UML design and structured design to UML techniques that are used to generate legacy system design in design transformations exist. We briefly explain both the UML. We include DFD to UML diagrams transformation in views. our survey. We analyze different existing transformation techniques using set of Analysis parameters identified in the B. Structured Design (DFD) to a Non UML Objectsurvey. Based on the parameters analysis matrix is created, oriented Design which highlights the weaknesses and strengths of different In this section, we will discuss those techniques that techniques. Motivation behind DFD-UML models transform structured design to a non-UML object-oriented transformations is that designers/analysts can use surveyed design. Alabiso [18] use FDC (Functional Design Chart) to transformations from DFD to class diagram, with the existing express functional behaviors and OSC (Object Structure MDA transformation [9] either as PIM to PSM or as PIM to Chart) to express breakdown of data structures of object. His code. transformation approach is not automatable and does not II. SCOPE OF THE SURVEY provide detail transformation rules. George and Carter [19] propose mapping strategy that uses Entity Relationship Modernization of legacy systems cost effectively has Diagram (ERD), Functional Data Flow Diagram (FDFD) and become the primary focus of software designers and Data Dictionary as a source model and generates Object researchers. In literature, both structured code to objectStructure and Mapping Diagram (OSMD). Their approach too oriented design and structured design to object-oriented design is not automatable. transformations exists. Code to design techniques cause maintenance issue because code is written in programming III. CRITERIA FOR EVALUATION languages, which have become out-dated now. Besides, code In this section, we describe and discuss set of analysis might have undergone numerous modifications, which make parameters. Analysis parameters provide criterion to evaluate code and design inconsistent. Design recovery from that code different techniques. is useless and no more usable for future maintenance. Contrary to this, in structured design to object-oriented design For parameters selection, we comprehensively consider transformations, new design provides basis for development of transformation techniques description, their limitations and new system and becomes future reference for maintenance. comparison discussed by the authors while describing their We limit our scope to legacy system design to UML design. In respective technique. On reviewing different techniques, particular, we focus only on data flow diagram to UML design certain parameters are identified. Detailed description of transformation. parameters and their values is given below. In literature, both structured code to object-oriented design A. Automatable and structured design to non-UML object-oriented design This parameter describes whether a transformation techniques exists. In this section, we discuss both the views. technique is automated or can only be applied manually. The A. Structured Code to Object-oriented Design parameter value depicts practical importance of the technique Techniques and used in determining the efficiency and applicability of the approach. The values assigned to the parameter are ‘Yes’, ‘No’ In structured code to object-oriented design techniques Liu and ‘Partial’. Table 1 shows value selection criteria for and Wilde [9], propose methodologies for identifying object automatable. from non-object-oriented languages. They propose type base and global base object finder methodologies. Jacobson and TABLE 1 EVALUATION CRITERIA FOR AUTOMATION. Lindstrom [10] describe reverse engineering strategies and Value Criteria discuss object-oriented model to incorporate changes. Livadas Yes Technique automatically transform source model into target model. and Johnson [11] propose an approach that maintains existing No Technique does not automatically transform source model into relationship in the maintained code. Similarly, another target model. approach by Gall and Klösch [12] defines two types of data Partial Author explicitly mentioned or after analysis of case study and entities: data store entities and non-data store entities. They transformation rules, we have found that some manual support describe relationship between the two types for expressing is needed for automation. entities as objects. B. Tool Support Newcombe and Kotik [13] present a tool for abstract Tool support parameter describes whether a tool or an object-oriented model generation. Subramanian and Bwirne automatable environment is available for the technique or not. [14] generate objects from FORTRAN code. They discuss Table 2 shows value selection criteria for tool support. constraints like private, virtual, and pure virtual. Cimitile et al [15] and De Lucia et al [16] present approaches that revolve around data stores. Authors propose approaches that consider functions and subroutines, interacting with tables, data-store and use them as objects methods. Similarly, De Lucia et al Value Yes No 11 TABLE 2 EVALUATION CRITERIA FOR TOOL SUPPORT. Criteria Author explicitly mentioned tool support. No information related to tool is provided. WCSIT 1 (1), 10 -16, 2011 TABLE 7 EVALUATION CRITERIA FOR DIRECTION. C. Additional Artifact Used Value Criteria This parameter describes the additional artifacts used by Bidirectional Technique transforms structured model to object-oriented the transformation technique. Values for this parameter model and can retransform object-oriented model to include Data Dictionary (DD), Entity Relationship Diagram structured model. Unidirectional Technique transforms structured model to object-oriented (ER) etc. model only. D. Output Artifact This parameter describes UML artifacts that are generated because of transformation technique. Values for this parameter could be Class, Use-Case, Sequence, state chart diagram etc. J. Input Model Coverage Input model coverage parameter describes the coverage of different constructs of source model. Since, our primary focus is on DFD, we check that different constructs of DFD like external entities, data-stores, processes and data-flows between them are properly transformed into target model or not. Table 8 shows value selection criteria for input model coverage. E. Case Study This parameter defines whether a transformation technique applied on a case study or not. This parameter is important because a technique needs to be applied on case study to check it applicability. Table 3 shows value selection criteria for case study. Value Yes No TABLE 8 EVALUATION CRITERIA FOR INPUT MODEL COVERAGE. Value Criteria Low Basic constructs like external entities, data-stores, processes are only transformed. Medium Few data-flows between components along with basic constructs are transformed High All data-flows between components along with all the constructs are transformed TABLE 3 EVALUATION CRITERIA FOR CASE STUDY. Criteria Case Study provided or discussed. No Case study discussed. F. Transformation level This parameter defines type of transformation given technique follows. Value for this parameter includes rulebased or metamodel-based transformation. Table 4 shows value selection criteria for transformation level. K. Target Model Coverage: Target model coverage parameter describes the coverage of different constructs of the target model. Since, we focus on UML models this parameter describe construct of different UML models. For class diagram, construct of class diagram like owned attribute, owned operation, association, dependency, inheritance relationship are considered. Class diagram metamodel describe in UML superstructure, helps in identifying different constructs. Table 9 shows value selection criteria for output model coverage. TABLE 4 EVALUATION CRITERIA FOR TRANSFORMATION LEVEL. Value Criteria Rule-based Transformation rules are provided for models instances. Metamodel-based Transformation mappings and rules are provided at metamodel level. TABLE 9 EVALUATION CRITERIA FOR TARGET MODEL COVERAGE. Value Criteria Low Basic constructs, like owned attributes and owned operation are catered. Medium Association between components along with basic constructs is catered. High All the constructs including inheritance are catered. G. UML Conformance This Parameter describes the conformance of the generated model. It shows model produce by transformation technique follows UML syntax and semantics or not. Table 5 shows value selection criteria for UML conformance. Value Yes No TABLE 5 EVALUATION CRITERIA FOR UML CONFORMANCE. Criteria Generated model follows UML syntax and semantics, describe in UML Superstructure. Generated model do not follow UML syntax and semantics. L. DFD Level Used: This parameter defines the level of DFD used in transformation technique. Values for this parameter include context level DFD and Extended level DFD. Table 10 shows value selection criteria for DFD level used. H. Scalability This parameter defines whether a transformation technique has potential, to be applied on larger size case study or not. Case study description provides the basis for this parameter. Table 6 shows value selection criteria for scalability. Value Yes No TABLE 10 EVALUATION CRITERIA FOR DFD LEVEL USED. Value Criteria Context Level DFD in transformation has hierarchy which is not refined Extended Level DFD in transformation is refined and no hierarchy exists. TABLE 6 EVALUATION CRITERIA FOR SCALABILITY. Criteria Size of case study is appropriate and technique fully transformed source model to target model in feasible time. Technique description helps in determine in efficiencies. Size of case study is small and approach does not fully transformed model in feasible time. Based on the above-mentioned criteria, we evaluate the techniques explained below. IV. I. Direction This parameter defines transformation direction. Values include unidirectional and bidirectional. Table 7 shows value selection criteria for direction. STRUCTURED DESIGN TO UML DESIGN TRANSFORMATION TECHNIQUES In this section, we will analyze structured design techniques that generate UML Object-oriented design based on evaluation criteria discussed earlier. 12 WCSIT 1 (1), 10 -16, 2011 No tool and automation issues for framework are discussed. A. Documentation Maintenance: DFD by Means of Technique describes informal transformation rules and is UML. [20] unidirectional. Technique is not practical, because it is In documentation maintenance DFD by means of UML, partially automatable and no case study is discussed. Every authors generate several UML diagrams from DFD. UML construct of source model is catered in transformation rules, diagrams generated from DFD are Use-Case Diagram, Class which makes source model coverage high. Transformation Diagram and Interaction Diagram. Context diagram of DFD rules for basic construct of target model are provided, which transform into Use-Case diagram by mapping data stores and makes target model coverage Medium. sinks into actors, processes into use cases and data flows into relationships between processes. For class Diagram D. Functional and Object-oriented Views in Embedded generation, data-stores are considered as classes, processes Software Modeling. [23] attached to the data stores are considered as functions and all In Function and Object-oriented Views in Embedded the data elements of data store expressed as attributes of Software Modeling, Fernandes and Lilius describe DFD and classes. For interaction diagrams, processes are used as UML diagram transformation. They propose that DFD is used relationship between generated classes. in an integrated way to refine UML models including UseCase and Class Diagram. They also use DFD to detail the B. Meta Model Approach for Mediation [21] behavior of a system component. Authors describe that since, In metamodel approach for mediation, authors propose DFD are more expressive to represent user requirement, as formal DFD metamodel. DFD metamodel describes DFD compare to use case diagram it should be used to represents semantics formally. DFD instance can be created by user requirements. DFD transformation to UML diagrams at translating semantics describe in metamodel. Authors also context level is only applicable. Similarly, for sequence, discuss generation of UML models using DFD metamodel. collaboration and class diagram DFD can also be used. UML models that transform using DFD metamodel are UseCase diagram, Class diagram and Sequence diagram. Technique proposed by authors is partially automatable. Incomplete and informal mapping rules are also proposed, Technique generates valid UML models. Technique uses which are used for DFD to UML models transformation. informal rules. Rules for very few construct of source and Shiroiwa proposed metamodel is a mediator between DFD and target model are provided, which make both source and target UML. metamodel also preserves DFD hierarchy structure. model coverage low. The technique proposed by author is generalized as it is E. Tool Support for DFD-UML Model-based based on metamodel. Case study and tool support description Transformation [24] is not provided. Generated UML models conformance UML In the paper tool support for DFD-UML, model-based semantics. Context level DFD is used for transformation. Both transformation, authors propose an approach that combines the source and target models have medium coverage because both functional and object-oriented models for modeling transformation technique does not provide rules for every embedded system. They also implemented a tool for construct of source and target models. Only basic constructs of transformation between different views. Truscan et al, propose source model are transformed into the basic constructs of Software Modeling Workbench (SMW) that gathers target model. requirements, create use-case diagram and transforms it into C. Framework for transforming Artifacts of DFD to non-UML, so call Initial Object Diagram (IOD). SMW also transforms DFD’s into Class Diagrams. Through UML. [22] transformation scripts, basic rules are implemented to perform In framework for transforming artifacts of DFD to UML, transformation. Rules are specific only for IPv6 case study. Tran et al, propose a framework that works on DFD at three levels of abstraction. At DFD abstraction level 1, framework In this paper, SMW tool discussed by authors, run script to translates DFD into UML Use-Case diagram. At DFD generate class diagram. Proposed technique is automatable and abstraction level 2, framework translates DFD into UML mapped only on specific case study. We consider proposed interaction diagram. Instead of DFD, Entity Relationship approach impractical for others systems as of specific rules for Diagram (ERD) is used as an additional artifact for generation IPv6 case study. of UML class diagram structure. At abstraction level 1, F. Systematic Transformation of Functional analysis processes in DFD are mapped to Use-Cases, external entities into Object-Oriented Design and Implementation are mapped as actors, and data stores are mapped to classes. [25] Data flows mapping is remained unresolved. At abstraction level-2, data flows variations includes external entity to In systematic transformation of functional analysis into process, data store to process, process to data store and process Object-Oriented Design and implementation, the authors to external entity are transformed into interaction diagram. proposed an enhanced data flow diagram called DF net, which Data flow variations process to process are mapped on state is used to specify use cases from requirements. The proposed transition diagram. At abstraction level 3, ERD components DF net is also used in transformation to generate objectincluding entity, association entity, attributes, and relationships oriented design. According to authors, the transformation map to class association, attributes and operations. It is also between DF net is carried in different steps. During first step, mentioned by the authors that framework does not address inprocesses in DF net dealing with data stores, data buffers and depth issues of transformation as complete transformation external entities are grouped together. Similarly, processes that rules are not provided. share the same data such that one process output is the input of other process are grouped separately. Next step is to generate The proposed framework generates valid UML models. It classes from the separated group. Similarly, use-cases are also is clearly describe by the author that technique is not scalable. 13 WCSIT 1 (1), 10 -16, 2011 identified by using DF net. The whole process is automatable data-store for class diagram generation. Although authors and tool support is available for transformation. The proposed discuss process-to-process component data flow but none of approach according to authors is scalable and practicable. them proposes complete solution for their transformation. ERdiagram is also used as an additional artifact to generate class G. A Framework for Transformation Structured diagram in some of the techniques. Analysis and Design Artifact to UML [26] In the paper, framework for transformation structured analysis and design artifact to UML, Fries converts DFD and Entity Relationship Diagram (ERD) into UML models. UML models include use-case diagram, sequence diagram, state machine diagram and class diagram. DFD Process in level-1 DFD is mapped on use-case, external entity creates an actor in use-case and data flow creates association line in use case diagram. Similarly, for sequence diagram different data flows are mapped on sequence diagram. State machines are generated by transforming data flows between processes as event parameters. Number of processes defines number of states. ERD is used for creation of class diagram. The proposed framework is partially automatable. Author partially defines transformation rules that generate valid UML models. Transformation is not practical, as of partial automation, though it is applied on a case study but incomplete rules are provided. Transformation is not scalable because transformation rules are defined at very abstract level. Transformation technique is partially automatable as rules are incomplete. Coverage for the source model is high as it caters every construct of DFD but coverage for target model is medium as basic constructs are only catered for target model. Table 11 shows the comparison of all the techniques based on the evaluation criteria explained in section 3. V. The comparison in Table 4.1 shows that a solution for DFD to UML class diagram transformation is needed. A solution that will cover in-depth transformation issues by providing detailed transformation rules. Besides, transformation should provide solution for the sequence that transformation follows and cater data flow transformation between processes. Transformation should follow MDA transformation strategy because it is the latest initiative of OMG for model transformations. By following MDA transformation strategy one can use the technique with the existing MDA and Model Driven Engineering (MDE) transformation approaches. Transformation should generate UML class diagram, which is the major artifact in object-oriented design to represent system static structure. Proposed transformation should provide reusable modern object-oriented design that will be helpful for future maintenance. Transformation strategy should be based on formal DFD metamodel, so that DFD design ambiguity and inconsistency is not reflected in generated class diagram. CONCLUSION OF SURVEY From the comparison of the existing DFD-to-UML design transformation techniques (Table 4.1), we conclude that most of the presented approaches are rule-based and are incomplete; do not supports model validity and model generalization. Techniques in majority of approaches define abstract rules for transformations, which do not cover in depth transformation and automation issues. Few of the techniques have been applied on case study as a proof of concept. Although few authors discuss process-to-process component data flow but none of them proposes appropriate solution for their transformation. It is observed that rules are defined, but at abstract level, which does not cover in depth transformation and automation issues. Majority of transformation techniques are unidirectional, lacks automation. Few of the transformation techniques have tool support. Some of the techniques have been applied on case studies, which are not comprehensive and majority of them are partially automated. Very few techniques provide high source and target model coverage. We have found that only one metamodel-based technique exists, which too discussed transformation at very abstract level. It is also observed from the literature review that different analysts/designers have their own interpretation of different DFD graphical symbols as DFD has informal syntax. Transformation approaches are data centric, which focuses on 14 WCSIT 1 (1), 10 -16, 2011 TABLE 11 ANALYSIS OF THE EXISTING DFD-TO-UML MODEL TRANSFORMATION TECHNIQUES Target Model Coverage Yes No Unidirectional Medium Medium Context Class Diagram. No Meta-Model Based Yes No Unidirectional Medium Medium Context Yes Rule Based Yes No Unidirectional Medium High Context Class, UseCase & Interaction Diagram No Rule Based No No Unidirectional Low Low Context NIL Class Diagram Yes Rule (script) Based No No Bidirectional Medium High Extended Yes DF Net Class Diagram Yes Rule Based Yes Yes Unidirectional Medium Medium Extended No ER Diagram Class, UseCase, Sequence & State Chart Diagram Yes Rule Based Yes No Unidirectional Medium High Context NIL Yes No NIL Partial No ER Diagram Partial No NIL Yes Yes Yes Partial Case Study Output Artifact Use-Case, Class Interaction Diagram Use-Case, Class, Sequence & State Chart Diagram REFERENCES [1] Yourdon, E. (1989). Modern Structured Analysis. Yourdon Press. Upper Saddle River, NJ. Newcombe, P. and Doblar, R. A. (2001 December). Automated Transformation of legacy systems. Crosstalk, 14, 18-22. [2] Dietrich, W., Nackman, I., Gracer, L. (1989), Saving a legacy with objects. In Proceedings of OOPSLA, pp. 77-88. [3] Kendall, K. E., Kendall J. E. (1999). System Analysis and Design. (3rd Edition), Prentice Hall. [4] Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. (3rd Edition), Addison Wesley Professional. [5] MDA (Model Driven Architecture), (2001 July). Retrieved on August 2006, Document ormsc/2001-07-01 from http://www.omg.org/ [6] UML (Unified Modeling Language): Superstructure. Version 2.1.2. Object Management Group (OMG). Document 07-1102.pdf From http://www.omg.org/spec/UML/2.1.2/ [Accessed: March 1, 2008] [7] Booch, G., Jacobson, Rumbaugh, J. I. (2005). Unified Modeling Language User Guide. (2nd Edition), Addison Wesley, Upper Saddle River, NJ. [8] Booch, G., Rumbaugh, J., Jacobson, I. (1999). The Unified Modeling Language User Guide. Addison Wesley. [9] Liu S., Wilde, N. (1990). Identifying objects in a conventional procedural language: an example of data design recovery. In: Proceedings of Conference on Software Maintenance, San Diego, CA, IEEE CS Press, pp. 266-271. [10] Jacobson, I., Lindstrom, F. (1991). Re-engineering of old systems to an object-oriented architecture. In: Proceedings of OOPSLA, pp. 340-350. [11] Livadas, P.E. and Johnson, T. (1994). A new approach to finding objects in programs. Journal of Software Maintenance: Research and Practice, vol. 6, pp. 249-260. [12] Gall, H. and Klösch, R. (1995). Finding objects in procedural programs: an alternative approach. In: Proceeding of 15 DFD Level Used Input Model Coverage Rule Based No Direction No Partial Scalability & Additional Artifact Used UML Conformance Functional and Object-oriented Views in Embedded Software Modeling. Tool Support for DFD-UML Model-based Transformation Systematic Transformation of Functional analysis into Object-Oriented Design and Implementation A Framework for Transformation Structures Analysis and Design Artifact to UML Transformation Level Documentation maintenance: DFD by means of UML Meta-Model Approach for Mediation Framework for transforming Artifacts of DFD to UML. Tool Support Transformation Technique Name Automatable Analysis Parameter WCSIT 1 (1), 10 -16, 2011 [21] Shiroiwa, M., Miura, T., Shioya, I. (2003). Meta model approach for mediation. In: Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC ’03) IEEE Press, 480-485, New York. [22] Tran, T. N., Khan, K. M., Lan, Y.C. (2004). A framework for transforming artifacts from data flow diagrams to UML. In: Proceedings of the 2004 IASTED International Conference on Software Engineering (Innsbruck, Austria, Feb. 17-19, 2004). ACTA Press, Calgary, AB, Canada. [23] Fernandes, J. M., Lilius, J. (2004). Functional and objectoriented views in embedded software modeling. In: Proceedings of the IEEE International Conference and Workshop on the Engineering of Computer-Based Systems (ECBS ’04) (Brno, Czech Republic, May 24-27, 2004). pp 378-387, IEEE Press, New York. [24] Truscan, D., Fernandes, J. M., Lilius, J. (2004). Tool support for DFD-UML model-based transformations. In: Proceedings of the IEEE International Conference and Workshop on the Engineering of Computer-Based Systems (ECBS ’04) (Brno, Czech Republic, May 24-27, 2004). Pp 388-397, IEEE Press, New York. [25] Tan, H. B. K., Yang, Y., Blan, L. (2006 February). Systematic transformation of functional analysis model in OO design and implementation. IEEE Transaction on Software Engineering. 32(2), pp 111-135. [26 ]Fries, T. P. (2006). A Framework for Transforming Structured Analysis and Design Artifacts to UML. In: Proceedings of the 24th annual conference on Design of communication, pp 105 – 112, Myrtle Beach, SC, USA. 2nd Working Conference on Reverse Engineering, Toronto, Canada, IEEE CS Press, pp. 208-216. [13] Newcombe, P. and Kotik, G. (1995). Reengineering procedural into object-oriented systems. In: Proceeding of 2nd Working Conference on Reverse Engineering, Toronto, Canada, IEEE CS Press, pp. 237-249. [14] Subramaniam, G.V. and Bwirne, E. J. (1996). Deriving an object model from legacy FORTRAN code. In: Proceeding of International Conference on Software Maintenance, Monterey, CA, IEEE CS Press, pp. 3-12. [15] Cimitile, A., De Lucia, A., Di Lucca, G.A., Fasolino, A.R. (1997). Identifying objects in legacy systems. In: Proceeding Of 5th International Workshop on Program Comprehension, Dearborn, Michigan, IEEE CS Press, pp. 138-147. [16] De Lucia, G.A., Di Lucca, G.A., Fasolino, A.R., Guerra, P., Petruzzelli, S. (1997). Migrating Legacy Systems towards Object-Oriented Platforms. In: 13th International Conference on Software Maintenance ICSM'97. [17] De Lucia, G.A., Fasolino, A.R., Carlini, U. D. (2000). Recovering Class Diagrams from Data-Intensive Legacy Systems. In: 16th IEEE International Conference on Software Maintenance ICSM'00. [18] Alabiso, B. (1988). Transformation of Data Flow Analysis Models to Object-Oriented Design. In: ACM SIGPLAN Notices, 23 (November), 335-353. [19] George, J., Carter, B.D. (1996 Mar). A strategy for mapping from function oriented software models to object-oriented software models. ACM Software Engineering Notes, vol. 21, no. 2, pp. 56-63. [20] Shiroiwa, M., Tokuda, H., Miura, T. (2002). Documentation Maintenance DFD by Means of UML. In: proceeding of Information System and Engineering (ISE). 16