Home > Free Essays > Tech & Engineering > Programming > Comparison Between Unified Modelling Language and Data Flow Diagrams

Comparison Between Unified Modelling Language and Data Flow Diagrams Report

Exclusively available on IvyPanda Available only on IvyPanda
Updated: Mar 28th, 2022

Introduction

Snow-NZ has been assigned to manage New Zealand’s premier recreational snow field under long term lease contract. These snow fields have different features and challenges to all the customers who include skiers, snowboarders and professional athletes when training. As a result, there is need to organise management and commercial activities of these snow fields. Snow-NZ was contracted to carry out this task for a period of ten years from January 2009 through New Zealand Tourist Authority by the New Zealand government. The main objective was to allow Snow-NZ to venture into better services through development and improvements. This includes automating ticketing system for ski lift passes, equipment hire, lessons, and the bus transport system to and from the snow field areas.

The methods used in analysis deals with content capturing and programming inputs in descriptions on use case. They are used in making use case field models timely and portraying status before and after the agreements in domain model (Levitt 2000). Teaching methods, on object-oriented design, is tackling a case at a time as well as commencing with fundamental design patterns. This paper entails the application of UML as compared to other data flow diagrams models.

The developments of software on basis of object oriented analysis and design have received warm welcome from large number of industries and individuals. According to Fowler, (2004), industrial standard notation has stabilized in terms of analysis and designing of models such as Unified Modelling Language (UML). However, some of better and understandable methods for analysis and design have not been adopted by higher learning institutions. The importance of software to users may be tough to explain how models can be derived using UML since it is a new encounter. Users need to understand that, analysis using these models has common functionality compared to conventional and structured analysis.

Some parts of New Zealand are characterised by rugged alps and island that hinders to tourism and sports ventures. The New Zealand government through its Tourism NZ Authority had to revisit this issue to benefit from the increasing skiing and tourism opportunities. The suggestion was to lease the land to specialised commercial organisation that had to improve infrastructure in these three premier snowfields.

It is this idea that led to notable modernisation and accessibility which was satisfactory to customers. Government on the other hand, chipped in large amount of money for setting up modern facilities in all the sites for all the categories of customers.

That was not enough though since current ticketing and service booking system was slowing field use, activities and transport. Manual data entry was discovered that it was prone to data entry errors, mechanical breakdown and cases of fraud. Snow-NZ had to venture into use of World Wide Web to organise, booking and advanced ticketing for holidays and activities. Ticketing and sales issue have been since then tackled properly through online system. Snow–NZ have realised good sales by use of internet global marketing for their winter sport activities. Customers can place reservations, order activities and pay through the web site for snowfield services.

Current Systems Specification

New Zealand tourism authority’s management was effective though basic administration system. Business system dealing with ticketing services had been a nightmare in realizing total returns from the growing popularity and increasing number of tourists. Currently, Snow-NZ offers tickets and sales services in Methven and Queenstown that are independent and labour intensive. A total of 30 computers are placed in these two sites that are used by all the staff members.

The requirement for customer’s arrival to the snow centre or guest service is to have either the upfront paying or prepaid voucher obtained from travel agent or tour operators. Guest service sales staffs carry out the transaction as per customer’s preference. At the end, the tickets and services bought are printed and handed to customers. For prepaid customers, details are entered to the system for authentication and referencing purpose. The print out of the ticket is then handed to customer. All these transactions are recorded by sales staff and entered later to system which is tiresome and prone to errors.

UML Models

A high level use case diagram.

UML Models

Use case diagram are used to bring out the connection between workability of the system and internal or external controllers which are known as the actors. Single use case diagram depicts a specific working of a system and hence to present whole system, several use case diagrams are used. The purpose is to depict the complex aspect of a system. They collect the specification of a system taking into account the internalities and externalities, which are vital for designing. Therefore, use case diagram plays a significant role in pinpointing the actor in a system. To commence the use of this principle, you must finish the use case diagram to model outside view.

Detailed description for any one use case

Use Case Name: Add customer ID: 1 Importance: High
Primary Actor: Snow-NZ Use Case Type: Essential
Stakeholders and Interests:
Snow-NZ wants to add new customers to the system. Clerk wants to provide a ticketing service to customers.
Brief Description: This use case describes how a new customer is added to the system.
Trigger: Snow-NZ has different services to offer to customers and the way to sell tickets have been a problem
Normal Flow of Events:
1. Snow-NZ fills out a form providing personal details.
  • Clerk adds information to the database.
Alternate/Exceptional Flows:
.2. If information is complete, clerk contacts customer to obtain ticketing information.
Detailed description for any one use case

Use the actor symbol in making the whole system shown by system boundary diagrams. Use case is therefore, enclosed into a rectangular system. Actors, who in this case are customers, placed in exterior of the rectangle. The system is the Snow-NZ, placed interior of the rectangle. As observed, the ticketing and sales leads to relationships in pricing of different services offered by Snow-NZ.

A structural (class) diagram showing attributes and methods of each class and the relationships between classes

A structural (class) diagram showing attributes and methods of each class and the relationships between classes

Order system of an application for ticket from Snow-NZ. It will describe the specific aspect of the whole application. To start with, order and customer are regarded as the two elements in the system, which have a relationship which ranges from single to multiple since customer is assumed to require several orders. Order class can be an abstract class that has two strong classes termed as special order and normal order, which have inheritance relationship.

Lastly, the two inherited classes are similar to the order class but they have other attributes such as dispatch and receive.

An activity diagram showing the main business processes

An activity diagram shows the flow of one activity to another in operating system.

The flow may be systematic, split or simultaneous that use elements such as fork, join among others.

An activity diagram showing the main business processes

we have order management system where four activities comes out in the manner they relate with circumstances. The activities are sending order by customer, receiving of the order, confirmation of order and dispatching of the order.

Structured Design Models

These structured models are discoveries offering assistance in structured programming, structured design, structured analysis and information engineering. Different software developers have come up with different analysis and design software. The aim of this software is to combine diagram editing, organization, authentication as well as harmonizing global dictionary and reporting. These models include; Data Flow Diagrams, that shows information stream and dispensation in a system. The starting point of this model is the context diagram, which portrays system bubble bordered with exterior factors marked by peripheral units. Data streaming regulates information into and out of the system, structured charts that displays component plan and calling associations and big structure charts arrangement into a pile of related diagrams.

State models comprise inclusion of diagrams and tables to show how significant they are in a system. As a result, we get procedures that lead to alterations among state and actions. Task diagrams is another model which has series of implementation and exact operating system tasks which includes; lines, incident flags and semaphores that bring them into a multi-tasking situation.

A Context Diagram

A Context Diagram

Context diagram marks the starting point for data flow diagrams that is viewed as system and its relationship with external situations. It is an easy version of the whole system of concern. In this process, the context diagrams spreads to lower stages of Data Flow Diagrams, which categorizes the system into reduced parts that allows information streaming among main and minor diagrams. Therefore, it requires multiple diagrams stages to demonstrate the complexity of this system. In the illustration above, we can conclude that one use of context diagram is to partition the entire system. A single process is the system from which data streams into or out of exterior factors.

Level 0 DFD

Level 0 DFD

At this level, three processes decomposition occurs in the system. These processes are; schedule sources, student assignment tackling and handing over the assignment to lecturer.

One (1) Level 1 DFD

In this level, we seek to get the overview of the business as whole to discover the areas of common interest. It will also use the information applied to context diagram only that it is in a higher level. In the diagram below, we find that the schedule courses decomposed into three related processes.

One (1) Level 1 DFD

A Rich Picture of the Problem Situation

According to Darzentas, Darzentas and Spyrou (1994), rich pictures give impression of managerial situation through problem characterization. The essence of rich picture is to assist an analyst to believe in problem existence. Soft Systems Methodology (SSM) believes that rich pictures symbolize concern in a certain problem and related elements of concern to a problem. Mainly, they suggest how some of these elements are not useful in formal means. They resemble Ad hoc drawings and lack formal syntax but serves as a direction for users in explaining their views to developers through symbols and diagrams in place of a situation.

Rich pictures perspectives differ from one analyst to another because they require development of personal style depending on people and the area of interest. In conclusion, they are neither system model or map nor are they organ gram since they are objects and items placed together (Jilani, Usman and Nadeem 2011).

A Rich Picture of the Problem Situation

An example Rich Picture showing elements from the list of issues/conflicts etc supplied above.

Proposed System Specification

A structural (class) diagram of your proposed solution showing attributes and methods of each class and the relationships between classes.

The increment in the diagram signifies that the owner’s rental houses range is wide, that is, it can be less than one or multiple. The main concern is that each house requires only one owner.

Customer

An activity diagram of your proposed solution

An activity diagram of your proposed solution

In the above diagram, we can have both diamonds for decision while else we may make decision even without diamond identification. Decision depends on the priority of the user.

Comparison and analysis

UML is an object modelling system while DFD are data modelling systems. In object models, we have systems based on object orientation termed to as blue prints in a system. They include; class diagrams, associations among the classes created and properties of these classes among others. On the other hand, data models encompass units in the stage of database. They are concerned with table schema that is, comparing a collection of tables

Secondly, data models lack complicated features such as polymorphism, inheritance and overloading, which are present in object-oriented models. For example, two classes used in object model require one table in the data model. This is evidenced by the way employee and executive can fit in one database table. Another difference is that data models focuses on design and making of database plans where data is saved while object models focuses on the way application cooperate with facts delivered by exterior sources such as database and web service among others. An example can be an effort to get the history of how a customer has transacted with a department dealing with sales. This requires department to acquire customers name, telephone number, home address and trend of purchases. For data models, you will require planning tables and fields to store the information individually, while in objects oriented models requires you to clarify the data entry. For example, proper formatting of email address is vital.

Therefore, object oriented models simplifies data management in an application as well as carrying out high level authentication of data before entering them into the database.

Both of these methods take advantage of application of event analysis in system disintegration. As early as 1980’s, event analysis had preference among techniques used in decomposition of systems that behaved differently to outside and temporal stimuli. Structured analysis uses ERD (entity-relationship diagram) for application domain, normalized by a group of data flow diagrams (DFD). Similarly, in object-oriented analysis, UML domain act the same way as in ERD.

In contrast, both methods perform similar task interchangeably. For example, assembly language programming can use object-oriented techniques in structured programming. It is therefore clear that most of these programming tasks require either object-oriented techniques or structured analysis since they require similar hardware. Similarly, both models require coding aspect but they differ in grouping. In structured programming, they are loose while in object-oriented programming, they are tight in objects. It is evidence that, structured code to object oriented design and structured design to techniques which are not UML object oriented design are in place. New Combe and Kotik describe the relationship between the two where they argue that it present item used to get object-oriented model (Scott 2009).

It is a fact that most of legacy systems we use currently have structured models approach. The language used in developing them is traditional, which requires modification or upgrading as suggested by New Combe and Doblar. In order to better, these systems in terms of workability and maintenance, it require a move to object oriented models that industries welcome. We cannot just ignore these legacy systems since improvising them may use object oriented crossing point as the case in Data Flow Diagrams. DFD is advantageous in that, it makes all the system that requires structured approach. It also has chain of commands taken from different stages. Lastly, DFD portrays and predicts the configuration of a system.

However, object-oriented analysis and design overpowers structured design techniques in popularity and adoption by software developers. This has led to object management group to deliver new vision for software development. There is no doubt that object-oriented design and analysis is the only way forward since they offer platform for making new systems and future reference for maintenance.In the proposed systems, they are trying to invent systems, which can integrate or transform the structured designs in a manner usable today. There are many suggestions, For example, Alabiso propose use of functional design chart to bring out the working of object structure chart to show the organization of data structures of objects. On the other hand, George and Carter suggest use of entity relationship diagram among others as root model to create object structure and mapping diagram although this approach does not produce automatic systems (Tutorials point 2011).

Reference List

Darzentas, J., Darzentas, J. and Spyrou, T., 1994. defining the Design “Decision Space”: rich pictures and relevant subsystems. Amadeus Project Document: TA/WP 21.

Fowler, M., 2004. UML Distilled, Third Edition: A Brief Guide to the Standard Object modeling Language. Boston: Addison-Wesley.

Jilani, A., Usman, M. and Nadeem, A., 2011. Comparative Study on DFD to UML Diagram Transformations. World of Computer Science and Information Technology Journal, 1(1), pp. 10-16.

Levitt, D., 2000. Introduction to Structured Analysis and Design, Pomona, California State Polytechnic University.

Scott, W., 2009. Data Flow Diagrams (DFD), Web.

Tutorials point, 2011. UML 2.0 – Overview, Web.

This report on Comparison Between Unified Modelling Language and Data Flow Diagrams was written and submitted by your fellow student. You are free to use it for research and reference purposes in order to write your own paper; however, you must cite it accordingly.
Removal Request
If you are the copyright owner of this paper and no longer wish to have your work published on IvyPanda.
Request the removal

Need a custom Report sample written from scratch by
professional specifically for you?

801 certified writers online

Cite This paper
Select a referencing style:

Reference

IvyPanda. (2022, March 28). Comparison Between Unified Modelling Language and Data Flow Diagrams. https://ivypanda.com/essays/comparison-between-unified-modelling-language-and-data-flow-diagrams/

Reference

IvyPanda. (2022, March 28). Comparison Between Unified Modelling Language and Data Flow Diagrams. Retrieved from https://ivypanda.com/essays/comparison-between-unified-modelling-language-and-data-flow-diagrams/

Work Cited

"Comparison Between Unified Modelling Language and Data Flow Diagrams." IvyPanda, 28 Mar. 2022, ivypanda.com/essays/comparison-between-unified-modelling-language-and-data-flow-diagrams/.

1. IvyPanda. "Comparison Between Unified Modelling Language and Data Flow Diagrams." March 28, 2022. https://ivypanda.com/essays/comparison-between-unified-modelling-language-and-data-flow-diagrams/.


Bibliography


IvyPanda. "Comparison Between Unified Modelling Language and Data Flow Diagrams." March 28, 2022. https://ivypanda.com/essays/comparison-between-unified-modelling-language-and-data-flow-diagrams/.

References

IvyPanda. 2022. "Comparison Between Unified Modelling Language and Data Flow Diagrams." March 28, 2022. https://ivypanda.com/essays/comparison-between-unified-modelling-language-and-data-flow-diagrams/.

References

IvyPanda. (2022) 'Comparison Between Unified Modelling Language and Data Flow Diagrams'. 28 March.

Powered by CiteTotal, best referencing tool
More related papers