A Framework for Converting Classical Design to Reusable Design

Transcription

1 A Framework for Converting Classical Design to Reusable Design Abdul Khader Jilani 1, Dr. Syed Abdul Sattar 2 1 Research Scholar, Rayalaseema University, Kurnool, Andhra Pradesh, India 2 Dean, Royal Institute of Engineering and Technology, India 1 jilani40@yahoo.com Abstract: This work proposes a framework for transforming traditional approaches to object oriented approach for any software system. The framework is a systematic step-by-step approach that enables systems analysts and designers to achieve the transformation. Many existing legacy systems were designed using structured analysis and design methodology (SAD). Some of these legacy systems need to be re-designed and re-produced using object- oriented analysis and design (OOAD) method to make the system more maintainable. Here I show that a transformation should be done at three abstraction levels. I have presented the applicability of my frame work with a simple case study. Keywords: Class Diagram, Design Transformation, Data Flow Diagram, Entity Relationship, Sequence Diagram, OOAD, State Transition Diagram, UML. 40 I. INTRODUCTION Software systems always tend to change and evolve as technology and business rules change. Evolution of information systems is unavoidable, and it is a natural phenomenon. Organizations need to support systems evolution to take advantage of the new technology and to address the changing business rules. The evolutionary nature of software products, in fact, leaves us with two options: either maintain the products with their continual changing nature, or accept the degrading performance of the product. In this ever-increasing competitive business environment, the latter one would hardly be an option for most enterprises. Software systems designed with structured design methodology do not support some of the desired quality attributes such as reusability, and portability [2],[3]. Requirements documents generally consist of a textual description of the functional and non- functional requirements for the software product and the related scenario definitions (i.e. use-cases). The goal of well-described requirements is to represent the problem to be solved by the software system, not to specify a particular solution [4],[5]. In fact, a particular set of requirements could conceivably support multiple solutions for the problem[6]. Many large organizations find that systems designed with structured approaches are less reusable and less maintainable than those designed with object-oriented approaches. Many research results on software reverse engineering have been published in various forums, in particular, IEEE International conferences on software maintenance and IEEE workshops on program comprehension. Most papers on this topic focus on program transformation from one programming language to another. Very few of them address the methodological aspect of the transformation, which could aid the understanding of the process at much lower level of the design process. My work reported in this paper addresses the design level of the transformation from DFD to UML. Not surprisingly, the Unified Modeling Language (UML) is intended as the language to be used for model-driven development. The language was first standardized in 1997 as the end of the methods wars [7], and it quickly grew to become the most popular modeling language around for visualizing, constructing, and documenting the artifacts of a software intensive system [8]. I developed a step-by-step methodological approach, which is based on the hierarchical aspects of the design features. I found that it is vital to understand how various design features are organized in a hierarchy in a particular design paradigm. I first classify the design elements of DFD into three abstraction layers based on their interrelationship with each other. I do this to make transformation into the corresponding UML features. The paper is organized as follows. The next section presents the framework to transform DFD into UML. A case study is cited using the proposed framework in section 3 to demonstrate the applicability of the framework. Finally, the paper concludes in section 4. II. THE FRAMEWORK FOR TRANSFORMATION The proposed transformation framework uses a phase-based approach. There are three abstraction levels in this transformation framework. Various elements of DFD are step by step transformed to UML design features at three different levels of abstractions keeping the design information intact. Figure 1 presents the general view of three abstraction levels of our transformation framework. The shaded rectangles in the figure represent two different methodologies. Abstraction Level 1 deals with the highest level of the abstraction hierarchy. DFD in SAD is partially mapped into use case diagram and components of class diagram in UML. In SAD, DFD reformulates the problem from the real world into abstract concepts in terms of data flow and processing. DFD generally provides a broader representation of a software system from a process point of view. Hence, DFD coverage is very broad that cannot be transformed directly into a UML representation. Abstraction Level 2 deals with the transformation of data flow. This is where the interactions between objects are presented. Abstraction Level 3 is the conversion of ERD (entity relationship diagrams) to design class diagram. The

2 mapping from ERD to design class diagram is the finale stage in the transformation process. Figure 1. Three Abstraction Levels of The Transformation Framework A. Abstraction Level 1 The process defined in DFD representing a function is transformed into use case defined in UML. The external entities and data stores connected to the processes are transformed into actors and classes respectively. The external entity / Agent in DFD has similar characteristics as of an actor in UML. The data flow between a process and an external entity in DFD represents the relationship between a use case and an actor in UML. The data flow from a process to an external entity has quite a different characteristic than the relationship between a use case and an actor. The transformation of data flow is discussed in the next section. As mentioned earlier about the broad coverage of DFD, data store is transformed into class, which is not included in the use case diagram. Part of the data store is transformed into attributes of the class. This is the highest abstraction level; hence class obtains all attributes (data at rest) from data store to show the static structure of data in class diagram. All processes associated with a particular data store (e.g., the dataflow that connects external entity process data store) are transformed into operations/methods of classes. Again, data flow from or to data store is addressed in the next abstraction level. These three abstraction levels are described in details in the following subsections. 41 Table 1. Abstraction Level 1 Table SA&D OOA&D Component Process UseCase Example RecordPayment, UpdateCustomer Master Component ExternalEntity Actor Example Customer, Bank Component DataStore Class Example Customer, Bank,CustomerMaster Component DataFlow Remainedunsolved Table 1 shows the transformation of DFD features into UML representations with examples at the abstraction level 1. B. Abstraction Level 2 The abstraction level 1 addresses the transformation of main components of DFD into UML components. At this stage, use case diagram and class diagram are worked out. The entire artifact of the system in SAD is reproduced in a different way in OOAD. The use case diagrams and class diagrams (converted from DFD) roughly represent the conceptual design of the entire system. Data flow is considered as the bridge between various SAD components, and can be presented in five variations: (i) external entity-to-process (ii) data store-to-process (iii) process-to-data store (iv) process to-external entity (v) process-to-process. Table 2 illustrates the transformation of data flow of DFD to UML. Table 2. Abstraction Level 2 SAD DATAFLOWVARIATIONS External entity-to-process Data store-to-process Process-to-data store Process-to-external entity OOAD UML Interaction diagram (sequence diagram/ collaboration diagram) State transition Process-to-process diagram The first four types of data flow can be transformed into sequence diagrams (interaction diagrams). Data, which flows from process to external entity or data store or vice versa in DFD, can be represented as messages, which are sent from one object to another in the sequence diagram. The sequence diagram represents the interactions between objects in a use case. In another words, sequence diagram is constructed for a particular function of the system. Therefore it is broad enough to cover all information contained in a data flow. Interaction diagrams capture the flows of data in terms of messages passed between objects. Interaction diagrams such as sequence diagrams, collaboration diagrams in UML represent dynamic model of the system. Abstraction level 2 is the middle level in the abstraction hierarchy of our transformation framework. The transformation of four variations of data flows is slightly different each other. We now discuss each of these in turn.

3 Data flow from external entity to process or from data store to process in DFD can be transformed into sequence diagram in similar way. An external entity or a data in the data store may become a class instance. For example, Customer (external entity) becomes :Customer (Class Customer Instance). Data flow from external entity/data store to process becomes an object which may be sent from the class instance to the system as a parameter in the message. As shown in Figure 2, data flow DF1 is transformed into Object1 as a parameter in the message1() in UML. Similarly, external entity E1 becomes ClassE1 Instances. That means, message1(object1) passes object1 instance from :ClassE1 Instance to the :System. This transformation is depicted in Figure 2. Figure 3. Transformation of Data Flow to Sequence Diagram Figure 4. Transformation of Data Flow To State Transition Diagram Figure 2. Transformation of Data Flow to Sequence Diagram Data flow from process-to-external entity or from process to- data store can be transformed into sequence diagram in similar way. An external entity or a data store becomes a class instance. Data flow from a process to external entity/data store becomes an object which is sent from the system to a class instance as a parameter of the message. The process becomes the message which passes the object from the system to the class instance. In Figure 3, data flow DF1 flows from the process P1.0 to data store D1 in DFD. In UML, the process P1.0 is transformed into message1(), data flow DF1 becomes Object1 used as a message parameter and data flow D1 becomes class Instance :ClassD1 Instance. This transformation is depicted in Figure 3. The last variation of the data flow is process-to-process. Data flow between processes can be represented through a series of state changes in state transition diagram. State transition diagrams capture the change of states of an object or a use case when an event occurs. These changes go through different states to show the behavior of the system. An event is a significant or noteworthy occurrence [2]. An event occurs to change the system, for instance, from state 0 to state 1. The example cited in Figure 4 shows the transformation of data flow from process-toprocess in DFD into state transition diagram in UML. The figure shows that the flow of data from a process P1.0 to another process P2.0 has been transformed into a state transition diagram. The data flow DF1 is transformed into object1, process P1.0 becomes state1, and P2.0 is transformed into a termination of the state diagram. 42 Figure 5. A Transformation of Data Flow into State Transition Diagram Data flow variation (process-to-process) happens very often in SAD as shown in figure 5. It is noted that the event (in state transition diagram) from one state to another is not an exact representation of any component in DFD. In DFD, components (process, external entity, and data store) are connected to each other through data flows which are not the same as the relationship between use cases and actors in the use case diagram. If there are relationships between a process and an external entity or data store in DFD, those can become relationships between use case and actor in use case

4 diagram. As mentioned earlier, in DFD it is possible to make data flow from process to process. There is no such provision in UML to make relationship between two use cases. However, it is possible in some exceptional situation, where the <<use>> relationship of use case can be applied. This is where one use case initiates or uses the behavior of another use case. C. Abstraction Level 3 Entities in ERD are transformed into classes in design class diagram. Attributes of the entities become properties of the corresponding classes. Relationships that connect one entity to another are transformed into methods of the corresponding classes. Table 3 lists the transformation rules. Table 3. Abstraction Level 3 SAD OOAD Component Entity Associated Entity Class Association Example Sales - Item Sales - Product - Invoice - Component Attribute Identifier Attribute Multi-Valued Attribute Attribute/ Property Example 43 Sale_Date, Receipt_No, Prod_ID, Prod_Desc Component Relationship Operation/ Method/ Association Example Sell(), Order(), Receive() The relationship in ERD has two different types which are Is a part of relationship (aggregation) and Is a relationship (generalization). The relationships are the same as the associations in design class diagram. Another aspect in ERD is cardinality. This is similar to the multiplicity in the design class diagram. III. CASE STUDY The case study discussed in this section is an inventory system called Hoosier Inventory Control System. This case study is used to illustrate the applicability of the proposed transformation framework from DFD to UML. Figure 6 cites the DFD for Hoosier Inventory Control System. A. Case Study: Level 1 Transformation: In the first level of the abstraction, Hoosier DFD [1] is analyzed and converted in to use case diagram. Table 4 presents the transformation of each component in DFD into UML. After the analysis, these components are put into use case diagram as shown in Figure7. Note that external entity Stock on Hand and data store Inventory can be transformed into Classes with corresponding attributes and operations in Class Diagram. B. Case Study: Level 2 Transformation: This level transforms the data flows into sequence diagrams. Data flows in DFD fall into following variations: process to external entity (Orders, Payments, Query Result); external entity to process (Invoices, Counts, Request); Process to data store (Amount Added, Amount Used, Query); data store to process (Inventory Levels, Minimum Order Quantities). Fig. 6. Data Flow Diagram for Hoosier s Inventory Control System (Source: Hoffer, George and Valacich [1]). Sequence diagram in UML represents dynamic models of interactions between objects. Messages which are sent from one object to another defined in sequence diagram, in fact, could represent data flows from one component to another (e.g., process to external entity) in DFD. As sequence diagram is developed for each use case, there are four sequence diagrams (not included all) for Hoosier Inventory Control System as shown in Figure 8. These are: (1) Update Inventory Added, (2) Update Inventory Used, (3) Generate Orders, and (4) Query Inventory Levels. Some data flows related to these processes are presented in those four sequence diagrams. Table 4. Transformation from SAD to OOAD

5 Figure 7. Use Case Diagram for Hoosier s Inventory Control System (ICS) Figure 8. Sequence Diagram for Use Case Update Inventory Added C. Case Study: Level 3 Transformation The ERD of the system is cited in Figure9. It has been transformed into class diagram as shown in fig10. Figure 9. ERD for Hoosier Inventory Control System 44 Figure 10. Class Diagram for Hoosier Inventory Control System IV. CONCLUSION My transformation framework is based on three abstraction levels. At the first level, DFD components are transformed into UML representations. Basically, the transformation is done from processes to use cases; from data stores to classes; and from external entities to actors. Data flow consists of five variations which are transformed into various artifacts of UML at the abstraction level 2. All data flow variations are transformed into sequence diagrams. At the abstraction level 3, ERD is mapped into a design class diagram. Based on three abstraction levels of the proposed framework, DFD elements are step by step transformed into components of UML. We acknowledge that the proposed framework does not address the detail in-depth issues of the transformation; nevertheless it lays the initial foundation for such a methodology. V. REFERENCES [1] Hoffer, J.A., George, J.F. and Valacich, J.S., Modern System Analysis and Design.Prentice Hall. New Jersey, [2] Wessels, D.M., Sloane, A.M, and Sommerville, I., Software Design. [3] Jacobson, I., Christerson, M., Jonsson, P., Overgaard,G.. Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, revised printing, [4] Fusaro, P., Lanubile, F., and Visaggio, G.. A replicated experiment to assess requirements inspections techniques, Empirical Software Engineering Journal, vol.2, no.1, pp.39-57, 1997.

6 [5] Meyer, B.. Object Oriented Software Construction, Second Edition, Prentice Hall Inc., [6] C. Szyperski, Component Software - Beyond Object- Oriented Programming, Addison-Wesley/ ACM Press, [7] C. Kobry. UML 2014: A Standardization Odyssey, Communicationsof the ACM, vol. 42, no. 10, October, [8] OMG, UML Unified Modelling Language Specification 45