Abstract
Application development is a set of activities resulted in software product. There are many approaches to design software application. Our interest is focused on the software visualization using Unified Modeling Language (UML). We have shown as could be a program code developed from the graphical representation in UML language.
Keywords: Software visualization, UML language, Graphical representation of software
1 Introduction
Quality requirements for software increase constantly. Clients demand complex information systems that can manage warehouses, manufacturing processes, marketing and so on. The proposed programs are complicated, may be relatively up to millions of commands. There is also a need to manage the actual program code. Software is invisible, disappearing into files on disk. The invisible nature of software contributes to low programmer productivity, particularly for large team-oriented projects.
In the paper [1] was described innovative visual representations of software. As it was shown in the book [2], software visualization refers to the use of various visual means in software development. Software development live style involves many activities of project management. These software activities have various aspects of visualization, including visual modeling, program a data visualization. An overview of the software visualization research is published in [3].
In this paper we have focused of attention on the Unified Modeling Language (UML). The UML is a graphical language for visualizing, specifying, constructing, and documenting of a software. The UML gives you a standard way to write a conceptual things such as business processes, system functions, as well as concrete things such as classes etc. We have proposed a methodology how could be from a graphical represented of model to build a program code in language C#.
2 Graphical representation of processes
Feynman diagrams. Feynman diagrams are graphical representations of the mathematical expressions describing the processes of elementary particles. R. P. Feynman introduced his diagrams in 1948 [4, 5]. The Feynman diagrams allow a visualization complex and difficult to understand intuitively interactions of elementary particles. The diagrams are applied primarily to quantum field theory, they can also be used in other fields, such as solid-state theory.
Feynman introduced his novel diagrams in a private, invitation only meeting at the Pocono Manor Inn in Pennsylvania during the spring of 1948 for the Quantum Electrodynamics (QED). QED explains the force of electromagnetism-the physical force that cause like charges to repeal each other and opposite charges to attract. Feynman graphical diagrams are a powerful tool for making calculations in quantum theory. As in any quantum-mechanical calculation, the currency of interest is a complex number (a probability amplitude) whose absolute square yield a probability.
Later Dyson derived rules for the diagrams [6, 7]. Dyson articles offered a “how to” guide including step-by-step instructions how the diagrams should be drawn and how they were to be translated into their associated mathematical expressions. For example, Compton scattering is described by two diagrams:
Figure 1: The Feynman diagrams for the Compton scattering.
The solid line shown in the Figure 1 represents interaction of the electron with photon. The dashed line is a photon.
UML diagrams. The UML is one of the exciting tools in the world of system development [8]. The UML is a visual modeling language that enables that capture visions and provides a mechanism to share and communicate these visions with others. The UML consists of graphical elements that combine to form diagrams. Because the UML is a language, it has rules for combining these elements. The purpose of the diagrams is to present multiple views of systems. This set of multiples views is called a model. A UML model describes what a system is supposed to do. It doesn’t tell how to implement the system [9]. Modeling yields an understanding of a system [10].
Classes are basic elements of the class diagrams. Any application demands for the modeling of more classes. UML proposes solutions for the connection between classes. Class relations express the semantic or structural relations. The most frequently used relations are: association, aggregation, composition, dependency, inheritance, realization.
We now want to show how we can graphically represent software code in UML using the C # language. UML diagrams are not bound to the given programming language. For the implementation of the program may use different programming languages: C++, Java, PHP, C #, and so on. Language should, however, support the object-oriented concept.
Consider a simple program in C #:
using System;
class T {
private double x;
public T(double x) {
this.x = x;
}
public void MethodT() {
Console.WriteLine(“Square = {0}”, Math.PI * Math.Pow(x, 2));
}
static void Main() {
T t = new T(2);
t.MethodT();
Console.ReadKey();
}
}
The software could be has corresponding UML diagram:
Figure 2: The graphical representation of the program code.
If we accept certain rules [11] we can draw the UML diagram and assign it program code. This means that the first we draw graphical UML diagram for the proposed model of a system, and then, as it was in the case of Feynman diagrams, we assign a code to the UML diagram. This can be done if we create also certain rules by which we assign a graphic element sections of code [12]. The proposed method allows us to do from the graphical representation the program code.
However, for more complex cases would be constructed diagrams quite confusing, so usually the code that powered those methods is not shown in the diagrams. We need to introduce yet another conventions to simplify diagrams. Then it is possible to obtain sufficiently precise code (a structural program code) for software.
Let us consider the following example. Take two classes Person and Address. Typically, a person have the address (a permanent address), and thus “the person has the address”. However, the person is not the owner of the address, if you cancel the person object, the object address is not destroyed [13]. The relationship between the Person and the Address class is an aggregation. Then the diagram will have a graphical representation as follows:
Figure 3: The aggregation between Person and Address class.
The code corresponding to the diagram follows:
using System;
using System.Collections.Generic;
class Prg {
class Person {
string namePerson;
public List<Address> addresses = new List<Address>();
public void Attach(Address address) {
addresses.Add(address);
}
public void Notify(string s) {
namePerson = s;
foreach (var o in addresses)
Console.WriteLine(“Address and person: {0}, {1}”, o.Name,
namePerson);
}
}
class Address {
string name;
public Address(string s) {
name = s;
}
public string Name {
get { return name; }
set { name = value; }
}
}
static void Main() {
Address a;
a = new Address(“Low street 22”);
Person p1;
p1 = new Person();
p1.Attach(a);
p1.Notify(“John Cameron”);
Person p2;
a = new Address(“High street 13”);
p2 = new Person();
p2.Attach(a);
p2.Notify(“Charlie Golden”);
Console.ReadKey();
}
}
3 Conclusions
Development teams are confronted with a variety of challenges when developing software in today’s technology. Software systems are very large and hence techniques for visualization and abstraction are required to assist software development and maintance. We must understand the aspects of an individual technology that provides different methodology. The reason to want software visualization is to gain a better understanding of programs. People who need to understand a program usually studying the source code, or running the program to see what it does. These are impractical methods because usually the programs have many commands.
We have proposed how a program code could be represented by graphical representation using UML language and vice versa. We have used analogy with the Feynman diagrams which obtained a big popularity in science and in different fields of research.
References
[1] Ball T., and Eick S., Software Visualization in the Large, IEEE Computer,
Vol.29. No.4, April 1996, pp.33-43.
[2] Software Visualization: From Theory to Practice, edited by K. Zhang, Kluwer
Academic Publishers, 2003.
[3] Gračanin, D., Matković, and Eltoweissy M., Software Visualization, Innovations
Syst. Softw. Eng. 1 (2005), pp.221-230.
[4] Feynman R.P., Theory of Positrons, Phys. Rev. 76, 1949a, pp. 749-759.
[5] Feynman R.P., Space-time Approach to Quantum Electrodynamics, Phys Rev.
76, pp.769-789.
[6] Dyson F. J., The Validation Theories of Tomanaga, Schwinger and Feynman,
Phys. Rev. 75, 1949a, pp. 486-502.
[7] Dyson F. J., The S-Matrix in Quantum Electrodynamics, Phys. Rev. 75,
1949b, pp. 1736-1755.
[8] Booch G., Rumbaugh J., and Jacobson I., Unified Modeling Language User Guide,
Addison Wesley, 1998.
[9] Schmuller J., SAMS Teach Yourself UML in 24 hours, 3rd edition, Sam
Publishing, 2004.
[10] Kniežová, J., Modelling of Information System Requirements, In: E-Leader Vol. 8,
No. 1 (2013), URL: http://www.g-casa.com/PaperDatabase.htm.
[11] Rumbaugh J., Jacobson I., Booch G., The Unified Modeling Language,
Addison Wesley Longman, Inc., 1999.
[12] Malcher V., Exact Implementation of Design Patterns in C# Language, IJAT,
Vol.4, No.6, December 2014.
[13] Fowler M., UML Distilled, third ed., Addison Wesley, 2004.
Software Visualization using Unified Modeling Language
Autor: Viliam Malcher
Faculty of Management, Department of Information Systems, Comenius University,
820 05 Bratislava 25, Odbojárov 10, P.O. Box 95, Slovak Republic, Europe
viliam.malcher@fm.uniba.sk
Recenzenti:
Ing. Jaroslav Vojtechovský, PhD.
Pracovisko: Fakulta managementu UK, Odbojárov 10, Bratislava
prof. RNDr. Michal Greguš, PhD.
Pracovisko: Fakulta managementu UK, Odbojárov 10, Bratislava
Vydanie:
Digital Science Magazine, Číslo 1, Ročník IV.
