Jonathan Popp EKU CSC 440 Assignment #2 October 28, DFD vs. OO

Transcription

1 Jonathan Popp EKU CSC 440 Assignment #2 October 28, 2010 DFD vs. OO In Software Engineering different methods are used when developing a software system. Different methods operations can have substantial benefits in the effectiveness and efficiency of a specific Software s Development. Two particular methods of focus when detailing Software Engineering are Data Flow Diagram and Object Oriented. Each contains a decent quantity of similarities and differences which allow their utilizations to produce varied results in the structure of a product s design. The variances between these two methods come in their input and output of each phase in a Software Engineering Process Model, such as the Waterfall Model. By analyzing the distinctions of each method it helps one better understand the most beneficial model to employ and what is required in using each method. The Waterfall Model is a Process Model in Software Engineering that helps a person or team of software developers categorize the software process into unique phases for better organization. The Waterfall Model most commonly contains five phases that guide a project from beginning to end. It should be noted that the Waterfall Model is not often used in the Software Industry due to its impracticability. Often Software Customers will want to monitor the progress of their product and due to its structure, the Waterfall Process Model does not show actual product results until about 60-65% through a software s development. It is also imperative that a Developer has a complete list of Requirements and Constraints from the Customer before the project commences. This makes any changes to the Software System very difficult to implement as they could drastically alter the Design and Coding phases. Apart from its deficiencies, the Waterfall Model is a good theoretical Model because it helps to clarify and organize the process of how successful software can be developed. The Waterfall Model s phases are clearly defined in their nature. See Figure 1 to observe an illustrated diagram of the Waterfall Model. The model begins with the Requirement Analysis phase. This phase is implemented to acquire the Requirements and Constraints from a Customer or User, so that a plan can be assembled. Formal definitions of the Requirements are contractually written to better achieve understanding of the desired Software System. The next phase is the Design phase. This phase is crucial to the subsequent phases. Detailed diagrams and charts are constructed to guide the Coding process that follows. These diagrams can represent everything from functions to flows of data. Following Design comes the Implementation phase. This phase is where a person or team of programmers will actually write the necessary programming code in the specific languages to formulate the Software System. After Coding is 1

2 complete, it is important to create trials for the operating software, thus the Verification phase. Different methods of testing are implemented to correct any errors or problems that might exist in the Software code. The final phase is the Maintenance phase where a Software System goes into production and is updated with new versions or patches to fix any problems that ensue. Each of the phases work together to produce the Software s Life Cycle. Figure 1 (commons.wikimedia.org) The first method that can properly implement the different phases of the Waterfall Model is the Object Oriented Method. This method employs a specific type of Diagramming Language called UML, or Unified Modeling Language. This unique set of terms and symbols helps organize a design structure that is easy to follow and one that illustrates many aspects of a Software s behavior. Current UML schemes can consist of up to 13 different diagrams. Each diagram allows the consideration of different points of view as well as levels of abstraction (Niewiadomski, Wojciech, Maciej 2009). The second method that can also be used to execute Waterfall Model phases is the Data Flow Diagram Method. This method uses its own unique symbols and terms to demonstrate Software actions. Both have similarities and differences in each phase of the Process Model. In the Requirement Analysis phase, the Object Oriented Method obtains Customer defined Requirements as its input. This can include constraints, behavior, I/O, timing, performance, and any additional specifications made by the Customer. The Software Engineer must then formally define these Requirements into objectives or functions that the Software can perform. Each requirement can have multiple levels of performing constraints. These formal definitions must be written in clear and well-stated terms so that the Customer can grasp fullwell the capability of the Engineer and the Development team for producing the desired results. These formal definitions serve as the output of OO in the Requirement Analysis phase. These definitions can then be mapped directly in successive phases. Similarly to Object Oriented Methods, the Data Flow Diagram Method strives to achieve comparable input and output in this first Waterfall Model phase. The DFD Method is engineered to transform the requests of a Customer into the formal definitions that can be contractually 2

3 transcribed. The Customer s list of controls, along with the necessary functionality of the Software System, establishes the composition of the DFD Requirement Analysis inputs. The output created consists of a formally definitive inventory of the functional requirements that the System must perform. The Requirement Analysis of OO and DFD will look comparative if not identical. Both take into consideration the Functional, Non-Functional, and Domain Requirements imposed on the Software System. The Second phase of the Waterfall Model, the Design phase, is the most differentiating phase between the two methods. The OO method begins by mapping the contents of the Functional Analysis Requirements as inputs from the first phase into Diagrams that can easily illustrate the System Functionality. Every Diagram in OO is derived from its unique UML. The first Diagram one might find would be the Use Case Diagram. This diagram often illustrates a User/Actor, or Stick-figure, with Data Flow, Pointing arrows, often acting upon certain cases. Cases are demonstrated by an oval contained neatly within a System. It is important to note that each Case should represent exactly one of the Functional Requirements. Figure 2 below illustrates a Use Case Diagram example. Figure 2 (resource.visual-paradigm.com) Another Diagram that is often generated as output in the OO method is the Domain/Class Diagram. The objective of this diagram is to illustrate the many classes that the Software System is comprised of and how they relate to each other. The Classes are represented by Rectangles that hold the information of attributes and operations that the class can execute. The Class relationships are Arrows with different shape pointing heads that represent how the Classes interact with each other. Figure 3 below illustrates a Domain/Class Diagram. This Diagram is one of the most important of all the UML because it shows the interrelationships within the entire Software System. It also demonstrates which specific attributes are contained in each Class as well as the functions that they use to manipulate data. This diagram can contain anywhere from a few to a few hundred different Classes and Relationships. Keeping this Diagram well organized is crucial. 3

4 Figure 3 (developer.symbian.org) A Diagram that illustrates the different steps performed by the System in execution is the Sequence Diagram. There can be multiple Sequence Diagrams in a Software s Design because each Diagram endeavors to display the Sequence of Events for just one System Function. The Diagram is composed of specific classes, shown by a Rectangle containing a Life-line. It then pictures the function calls operated by the different Classes to generate the necessary inputs and outputs of the System Function. Figure 4 below shows one specific Sequence Diagram. Figure 4 (argouml-stats.tigris.org) Similar to the Sequence Diagram is the Activity Diagram. This Diagram organizes the different Functions of specific Classes and their Flows of data into what resembles a standard Flow Chart. The Functions are separated into Swim Lanes which represent the containment within a Class. Like a Flow Chart the use of Decision Diamonds are prevalent and symbols called Join and Fork, which are solid horizontal bars, represents special cases of data flow in relation to multiple Functions. As with the Sequence Diagrams, there are multiple Activity Diagrams to show a different point of view for each System Functionality. Figure 5 below represents a single Activity Diagram. Figure 5 (argouml-users.net) 4

5 The Last Diagram commonly generated for output in the Design phase is the State Diagram. This Diagram exemplifies the different statuses of the Software System. As the System performs certain operations it s state changes. The States are shown as Rounded Rectangles and the transitions from state to state are show as Arrows. The Diagram also displays certain inputs and outputs necessary as well as any conditions to provoke a transitional change between states. Unlike the previous Diagrams, most UML Designs only consist of one State Diagram. This is because it represents the overall Software System s behavior and interaction within itself. Figure 6 below is a State Diagram for a Vending Machine System. initial state Getting Money do/ check money valid money not valid press return button Returning Money reset sale [input = price] Getting Drink Selection do/ check Availability press drink button Dispense Drink [if owed] Dispense Change reset sale display message Sold Out Figure 6 (Property of Jonathan Popp) There are many other UML Diagrams such as Package, Component, Deployment, Object, etc. but these are a few of the more commonly used. Any UML Diagram is considered output in the Design phase. Together all of these Diagrams represent the view points of the Software System from many perspectives and help to better clarify the Software s behavior. The Classes, Functions, and Attributes created in the Design phase can and should directly correlate to those created in actual programming code. It is practical to asses that the more detailed a Design phase is, the easier and more coherent the programming will be in the next phase of the Process Model. The Second Method, DFD, also creates Diagrams, however its output is completely different in design. The first type of Design chart that is created by this method is actually called a Data Flow Diagram. It is commonly accepted that there are two types of DFDs. Logical DFDs illustrate System Activites, while Physical DFDs focus on the who, where, and how of the System (Romney, Steinbart 2005). The purpose of this diagram is to show a complete layout of a Software System s Processes and their relationships with each other as well as additional External Entities. The External Entities represent the User of the Software System and they are symbolized by a Rectangle. The processes themselves are rounded Shapes that are numbered and titled to identify what actions they perform. The Data Flow between these entities and processes is shown as an Arrow. There are also Data Stores, which are open ended Rectangles that represent Database Storage that the processes need to access. The DFDs have multiple diagrams with the objective of decomposing the complexity of the Software System into levels. Each level of DFD shows the inner workings, or sub-processes, within a larger process. The digrams are at their highest level when each process only performs one function. Figure 7 5

6 shows an example of a simple DFD for one level, most likely the second, of a Library Software System. Figure 7 (itsmeeashok.blogspot.com) After DFDs are created, provided they demonstrate the greatest simplicity, another diagram can be constructed. Using the input of the DFDs and the Functional Requirements of phase one, the Structure Chart is produced. Unlike the DFD, there is typically only one Structure Chart for a Software System. This Diagram takes every sub-process or function of the DFD and illustrates how processes call other subsequent processes and pass their data. By utilizing different levels of processes, it helps to define the order or timing that an action is executed in a System. This Diagram also strives to identify what the outcome of the overall system is, or by showing what process or processes are called to conclude operation. The basic design of a Structure Chart only involves a Rectangle and a connecting Line. Sometimes when processes are called in a decision instance, a Deciding entity is needed to pass the resulting data back to the calling process. Each module of the Chart should only represent one function conducted by the System. Figure 8 shows an example of a Structure Chart. Figure 8 (it.toolbox.com) Lastly, as part of the DFD Method, Data Store Designs are created to clarify Database composure. A Data Store Design is comprised of the analysis of how and where data flows in and out of the Database. It also focuses on the individual attributes of a Database table and endeavors to eliminate redundancy in Database Records. It utilizes the practice of Normal Forms by studying attribute dependency for both key and non-key attributes in a table. It is critical to properly design a Data Store to achieve maximum efficiency and ensure stability in 6

7 maintaining important data records. If a Database is improperly constructed it could negatively affect the integrity of the processes and their operations, thereby jeopardizing the functionality of the entire Software System. Often Software Engineering Firms will have a Database Administrator on the team that specializes in superior Database Design. Following the Design phase and the output of various categories of diagrams the Implementation phase can commence. This phase of the Waterfall Model is quite similar for both methods of Software Development. The only major difference is the input that enters this phase. Depending on the chosen method in the Design phase, the input charts will either follow from the UML set or from a DFD perspective. Both are beneficial in many ways to the coding process. The programmers responsibility is to choose a specific language or languages and implement the Software System code following the guidelines provided by the Design Diagrams. The output should theoretically be well structured, efficient, and compatible Software Code. The extensive detail of the Design phase should provide naming conventions for specific, functions, variables, and other objects. The flow of control and data passing is also represented in the Diagrams and should be easily transferrable into System code. Because the Waterfall Model is being employed, we know that at the end of this phase the project is now somewhere near 65% completed. Once the completed Software Code is finished, a pivotal phase, Verification begins. No Software System should be released without extensive testing to ensure the System s stability and to discover any errors that might occur. This phase is also necessary to identify if the Software satisfies all of the Requirements defined by the Customer in phase one. The Code itself poses as the input while the desired output of this phase is analytical data recorded and observed through vigorous trials and experiments conducted on the System. There are many ways to test a Software System and both OO and DFD use similar practices to perform these tasks. The first type of testing that is often conducted is Black Box Testing. This category of Verification is concerned with the overall input and output of the Software System. The details of the System including programming code is concealed and of no concern in this testing protocol. This kind of testing helps to ensure that the overall System is performing as expected and that its generated output is consistent with predicted outcomes. This testing also studies how varying the inputs affect the outputs and what inputs can cause an erroneous output. The second type of testing is White Box Testing. Unlike its counterpart, White Box Testing is primarily concerned with the details of the Software System including code, data passing, data storage, algorithm efficiency, as well as System performance. One method of White Box Testing is to follow a defined variable in the code and study its data assignments throughout the duration of the code. This is then repeated for every variable in the System to ensure stability and efficiency. Both OO and DFD use these principles in testing. White Box and Black Box Testing are crucial in exhaustively testing a successful Software System. 7

8 The last phase of the Waterfall Model is the Maintenance phase. This is a phase that is often forgot about and rarely focused on in Software Development, however it is just as an important part, if not more so, than any other phase. This phase encompasses the majority of a Software s Life Cycle. Often after a Software s release, patches, fixes, updates, and changes need to be implemented so that the System continues to function despite changes to external software components. It is also possible that not every possibility for error is discovered in the Verification phase, thus through exhaustive regular use errors could arise. A responsible Software Engineering firm will continue to monitor the System s stability and aid in any way to extinguish said errors upon their occurrence. This phase, like the previous two, uses DFD and OO in the same way. Now that the Waterfall Model phases are complete, the benefits and disadvantages of both DFD and OO methods should be evident. In general, instead of using functional decomposition of the Software System, as DFD does, the OO Method tries to identify objects and their activities (Wang 1996). Most of the differences occur in the Design phase. Through the use of UML, the Object Oriented method shows more perspectives than its rival. The DFD Method has more benefit in illustrating how the entire system is constructed by decomposing to show process on multiple levels. The DFD levels are usually more detailed then the UML equivalent charts. DFD s Structure Chart is more beneficial in illustrating the data flow and call controls of the individual modules of the System. The UML State Diagram is very beneficial for demonstrating the different modes a System can conduct and what causes their transition. This is something that DFD lacks. Another major disadvantage of DFD, compared to OO, is that it fails to specify attributes in its Diagrams. The UML Domain/Class Diagram names and specifies not only attributes, but operations of each Class and its relationships to other Classes. This OO benefit is quite time saving when in the Implementation phase because all of the naming conventions are already established. In terms of Data Storage, DFD incorporates this into their DFD Diagrams and shows process interaction with the individual Data Storage, which is something that OO UML diagrams do not often focus on. Overall, both methods are used to achieve the same results. Both can be beneficial in the Software Engineering Process. By analyzing the different operations conducted by both methods in the various phases of the Waterfall Model, one can see that the major differences are in Designing the Software System. Though, each carries its own advantages and disadvantages, their selection depends on the type of Software System and its design. It is not impractical to combine methods and generate both types of Diagrams to create an even further complex Design phase. In fact, some researchers are considering their grouping in three different ways: convert DFD to OO, convert OO to DFD, or use the combination of both. This is especially beneficial in Embedded Systems (Fernandes, Lilius, Truscan 2005). Other Researchers have worked to create a new model called the Object Function Model to reassign roles in both methods and combine them to form new diagrams (Wang, Cheng 2000). This will only confirm the generalization that the more detailed the Design, the easier and faster it is to implement. 8

9 Works Cited Fernandes, João M., Johan Lilius, and Dragos Truscan. "Integration of DFDs into a UML-based Model-driven Engineering Approach." Software & Systems Modeling 5.4 (2006): Academic Search Premier. EBSCO. Web. 24 Oct Niewiadomski, Artur, Wojciech Penczek, and Maciej Szreter. "A New Approach to Model Checking of UML State Machines." Fundamenta Informaticae 93.1/3 (2009): Academic Search Premier. EBSCO. Web. 20 Oct Romney, M., and P. Steinbart Accounting Information Systems. Upper Saddle River, NJ: Pearson Education, Inc. Wang, Shouhong. "Two MIS analysis methods: An experimental comparison." Journal of Education for Business 71.3 (1996): 136. Academic Search Premier. EBSCO. Web. 26 Oct Wang, Enoch Y., and Betty H. C. Cheng. "Formalizing the Functional Model Within Object- Oriented Design." International Journal of Software Engineering & Knowledge Engineering 10.1 (2000): 5. Academic Search Premier. EBSCO. Web. 26 Oct Image Sources: Waterfall Process Model: commons.wikimedia.org Use Case Diagram: resource.visual-paradigm.com Domain/Class Diagram: developer.symbian.org Sequence Diagram: argouml-stats.tigris.org Activity Diagram: argouml-users.net DFD: itsmeeashok.blogspot.com Structure Chart: it.toolbox.com 9