An Approach to Class Diagram Design
Chebanyuk Elena
Software Engineering Department, National Aviation University, Ave Komarova 1, Kyiv, Ukraine
Keywords: Model-Driven Architecture (MDA), Transformation Rules, Behavioural Software Model, Collaboration
Diagram, Set Theory Tool.
Abstract: An approach to class diagram design is suggested in this paper. The approach is based on the analysis of
behavioral software models represented by collaboration diagrams. An analytical form of collaboration
diagrams representation is suggested. Rules that define relations between class diagram constituents by
analyzing the analytical representation of collaboration diagrams are presented. An approach to defining the
relations between class diagram constituents that is based on these rules is suggested. An example of class
diagram design by analyzing collaboration diagrams according to the suggested approach is presented.
1 INTRODUCTION
Using models in software development processes
increases productivity of various development
activities, such as domain analysis, automated code
generation, designing domain specific languages,
representation of a software system with necessary
details, testing, requirement analysis, software
documentation, code reuse and other tasks. It is a
background for development of special technics and
approaches for software models transformation.
Often software models are represented as UML
diagrams. Most of the models that are used in
software development process can be divided into
static and dynamic (behavioral).
Classification of software models according to
principle of division them into static and dynamic
was proposed in paper (Gupta, 2012).
Today Agile methodology is widely used to
create software projects (Gandomani, 2013). Main
feature of Agile is possibility to change software
requirements, algorithms and other artifacts after
every development iteration. It result to changing of
behavioral software models.
That is why the task to design languages,
technics, rules and other tools for transformation of
behavioral (dynamic) software models into static
ones is vital problem of Model-Driven Architecture
(MDA).
The paper is organized by the following way.
Section 2 represents the rewiev of papers that solve
tasks that are devoded to transformation of models
in MDA area. The tasks of recearch is formulated in
Section 3. An analytical representation of
collaboration diagrams is described in Section 4.
Section 5 represents rules of defining relations
between class diagram constituents, that are based
on analytical representation of collaboration
diagrams. Section 6 represents stages of realization
of the proposed approach. Section 7 contains an
exmple of class diagram designing. Section 8
describes an application of the proposed approach in
software development process. Section 9 containes
conclusions.
2 RELATED PAPERS
Actuality of the task to design transformation
approaches and technics is a background of
appearing series of papers that are devoted to
different aspects of MDA, namely creating of
analytical tools, generating new artefacts from
behavioural software models (Gupta, 2012),
estimation of code reuse effectiveness, tools for an
analytical description of software static models
(Chebanyuk, 2013) and other aspects that are based
on software models represented in a form of UML
diagrams (Acretoaie, 2013), (Whittle, 2009).
Paper (Gupta, 2012) represents an approach of
generating test cases based on use case models that
are refined by state diagrams. But an operation
(Gupta, 2012) of representation UML activity
diagram as state table and writing it into in to some
448
Elena C..
An Approach to Class Diagram Design.
DOI: 10.5220/0004763504480453
In Proceedings of the 2nd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2014), pages 448-453
ISBN: 978-989-758-007-9
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
file is rather consuming when activity diagram is
large. Also mechanical errors are possible when test
cases are generated.
Recently, several approaches adopting model
transformation technics to software development
processes have been proposed in paper (Whittle,
2009). These approaches use the concrete syntax of
the source and target models to define
transformation rules, and thus propose a change to
the overall model transformation mechanism.
Paper (Acretoaie, 2013) is devoted to definition
and implementation of a model transformation
language that is focused on usability. But
transformation templates of this language that are
proposed in paper (Acretoaie, 2013) relate only to
class diagram. Usage of an information from
behavioural models allows clarifying patterns,
designing new templates, and increasing an
effectiveness of models refactoring procedure.
3 TASK
Task: to propose an approach to class diagram
designing using collaboration diagrams.
Collaboration diagrams must meet to the following
requirements: completeness, information content,
accuracy and not contradictory. For this purpose we
have to do the following:
to propose an analytical representation of
collaboration diagrams allowing to trace a process
of objects creation;
to formulate rules that define relations between
class diagram constituents by analyzing the
analytical representation of collaboration
diagrams.
4 AN ANALYTICAL FORM OF
COLLABORATION DIAGRAMS
REPRESENTATION
4.1 Denotations for Representations
of Messages and Objects
A set of collaboration diagram objects is denoted as
.
A set of collaboration diagram messages is
denoted as
.
Consider any collaboration diagram object
.
Consider a set of messages that are linked
directly with the object
as
(
). In
graphical notation such messages are represented by
arrows that are directed to this object.
The note: an upper index in denotation (for
instance
) shows that component in question
belongs to definite whole (for instance
-is a set
of messages that are connected with the object
). A lower index in denotation defines a
number of an element in a set.
Consider a set of collaboration diagram objects
that are connected directly with the object
by
messages from the set
as
(
). A
number of elements in the sets
and
is denoted
as
N
. (Each object
is linked with
considering object by means of one message from
the set
.)
4.2 Input Stream of a Collaboration
Diagram Object
Input stream of an object
defines one of the
variant of this object creation.
In graphical notation the input stream of the
object
corresponds to fragment of
collaboration diagram, that consist from three
components namely: this object, a
message
and an object
that is
linked with the object
by message
.
Denote the number of input streams of the object
as
N
.
A set of input streams of an object
is
represented as a subset of the Cartesian product of
the following sets: objects
and messages
and
is denoted as follows:
,,...,,,,{
},...,,{
},...,,{
NN
N
N
eeexE
eeeE
2211
21
21
(1)
, where
Ni ,..,1 .0
A border object of a collaboration diagram is an
object
which corresponds to the
condition
.
4.3 Method of Forming Complete
Input Streams for an Object
A complete input stream for the object
is a
AnApproachtoClassDiagramDesign
449
tuple. A tuple is formed by concatenating of input
streams of different objects from the set
Complete
input stream for the object
is denoted as
and defined as follows:
},{
,
ii
N
xE
i 1
(2)
where
E
- is a tuple of input streams which
form complete input stream for the object
.
N
- is a number of elements in the tuple
.
The first component of the tuple
is an input
stream of the object
. The last component is an
input stream of a border object.
Introduce the method of forming complete input
stream for an object
.
1. A tuple of input streams
E
is formed
using (1). This tuple consists from
N
elements.
2.
N
tuples
i
,
Ni ,...,1
are formed. A
component of a tuple
i
is one element from the
tuple
x
E
. These tuples are denoted as follows:
},{
iii
(3)
Denote object
i
as
i
**
,
.
3. Consider
*
.
3.1 If
*
is a border object then the tuple
i
is
added to a set containing all complete input streams
of the object
. Denote this set as
},...,,{
N
21
, where
N - is the
number of elements in this set.
3.2 If
*
is not a border object then expression
(3) is complimented by concatenating of the
following components: expression (3) and an input
stream of the object
*
. The concatenation is made
according to the next rules:
3.2.1 If
1
*
N
then expression (3) is
complimented by an input stream of the object
*
using concatenation operation. The expression (3)
will look like:
},{)(
*
*
*
ii
(4)
where
**
,
**
.
3.2.2 If
1
*
N
then
*
N
new tuples are formed
by the following way:
},{
*
*
*
jji
Nj
(5)
where
*
,...,
Nj 1 ,
**
j
,
**
j
,
An object of the last input stream in the tuple (4)
or (5) is considered as
*
.
4. Actions that are described in point 3 are
repeated. Doing this tuple (4) or (5) is complimented
by an input stream of the object
*
, namely the last
component of the considered tuple.
5 RULES OF DEFINING
RELATIONS
BETWEEN CLASS DIAGRAM
CONSTITUENTS
Consider a collaboration diagram that meets the
following requirements: completeness, information
content, accuracy and not contradictory Denote this
collaboration diagram as Complete Diagram.
Consider an collaboration diagram object
.
This object has an attribute d. This attribute matches
with the name of another object in the same
collaboration diagram. Denote a class C of a class
diagram named – “name” as
)(nameC
. Consider
class diagram containing classes with names
)(
C
and
)(dC
. In order to define relations between
these classes we have to do the following:
1 A set
of the complete input streams for the
object
is formed.
2. The tuple
dd
x
E
of input streams of the
object
d is formed using (1).
3. Common components of tuples from all the
tuples
and the tuple
dd
x
E
are defined. In
order to do this a following set is formed:
N
i
i
dd
i
xE
1
(6)
3.1 If
NN
d
and
H
x
E
dd
then classes
)(
C
and
)(dC
are linked by a composition relation.
Explain this:
a) Presence of the attribute d in the object
proves the fact that at least one operation of
MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
450
the object
is executed using object
d or
some of its properties.
b) Expression
H
x
E
dd
and condition that
collaboration diagram is complete shows that
relation between classes
)(
C
and
)(dC
corresponds to whole-part relation.
c) Expression
0
d
NN
and condition that
collaboration diagram is complete show that the
lifetime of the object
d depends upon the
lifetime of the object
.
According to definition [Byrne, 2013] such a
relation corresponds to composition relation between
classes.
3.2. If
NN
d
and
H
x
E
dd
then
classes
)(
C
and
)(dC
are linked by an
aggregation relation. Explain this:
a) The first and the second points of this
explanation match with the previous explanation
(p. 3.1.).
b) Expression
0
d
NN
and condition that
collaboration diagram is complete show that the
object
d participates in operations that are
executed by other collaboration diagram objects and
the lifetime of the object
d does not depend
upon the lifetime of the object
.
According to definition [Byrne, 2013] such a
relation corresponds to aggregation relation between
classes.
3.3. If
H
x
E
dd
then classes
)(
C
and
)(dC
are linked by an association relation.
Explain this: expression
H
x
E
dd
proves the
fact that to create the object
it is not
necessary to involve the object
d and these
objects are not in a whole-part relation. From the
other hand presence of the attribute d in the
object
proves the fact that to execute at least
one operation it is necessary to involve the
object
d . According to definition [Byrne, 2013]
such a relation corresponds to association relation
between classes.
6 APPROACH TO CLASS
DIAGRAM DESIGNING
Introduce of the approach to class diagrams
designing using rules of defining relations between
its constituents. The source information for class
diagram designing is an analytical representation of
collaboration diagram.
Approach to Class Diagram designing
1. A collaboration diagram which represents all
problem domain processes is designed. It should
meet the following requirements: completeness,
information content, accuracy and not contradictory.
The correctness of a collaboration diagram is
checked by a domain expert.
2. Names of class diagram classes are defined by
means of matching with names of the objects in the
collaboration diagram. It is denoted as follows:
)(C
(7)
3. An analytical description of input streams for
each
are formed using (1). Input streams are
not formed for border objects.
4. Defining of an association relations between
all pairs of classes when one class is
)(
C
and
another one is a class
)(
C
,
. All
collaboration diagram objects are considered.
5. Complete input streams for each object of the
collaboration diagram are formed using (2).
6. Class diagram is complimented by
composition aggregation and association relations.
These relations are defined between class
)(
C
and
)(
|
C where
|
matches with the name of an
attribute that belongs to the object
.
The rules of defining relations between class
diagram constituents are represented in the previous
section.
7. Actions that are described in p.6 are made for
every collaboration diagram object.
8. Verifying relations between classes. if
between some classes association relation was set
and after that aggregation or composition relation
was defined then more strong relation remains. An
association relation changes to composition or
aggregation. Aggregation relation can be changed
only to composition relation.
7 EXAMPLE OF DESIGNING
A CLASS DIAGRAM
ACCORDING TO THE
SUGGESTED APPROACH
Consider an example to class diagram design using
collaboration diagram
1. A collaboration diagram is designed (fig. 1).
AnApproachtoClassDiagramDesign
451
Figure 1: Collaboration diagram.
2. Names of the classes in the class diagram are
defined. Thus classes are named by the following
way:
)(aC
,
)(bC
,
)(cC
,
)(dC
,
)(eC
.
3. Form an analytical representation of input
streams for each collaboration diagram object using
(1).
},{
}{
}{
axE
E
a
bb
b
b
1
1
(8)
},,,{
},{
},{
cbxE
E
cb
dd
d
d
54
54
(9)
},,,{
},{
},{
adxE
E
da
ee
e
e
36
63
(10)
4. An association relations are set between the
next pairs of classes:
)(aC
and
)(bC
,
)(aC
and
)(cC
,
)(bC
and
)(dC
,
)(cC
and
)(dC
,
)(dC
and
)(eC
,
)(aC
and
)(eC
.
5. Form the complete input stream for the object
e using (2) and analyzing (8), (9) and (10).
5.1
2
e
N
,thus:
},{},,{ ad
ee
36
21
5.2
2
d
N
, thus:
},{},,{ cb
eeee
54
1413
5.3
1
b
N
, thus:
},{
*
a
ee
1
33
(11)
The object a is the border object. The forming of
complete input stream is stopped.
5.4 Other input streams of the object e are formed
similarly:
5.4.1 Input stream
e
4
},,{ ac
ee
25
14
(12)
5.4.2 Input stream
e
5
}{ a
e
3
5
(13)
},,{
* eee
e
543
thus
3
e
N
.
6. Compliment the class diagram by composition
aggregation and association relations.
Consider the object e containing the attribute d.
Define relations between classes
)(eC
and
)(dC
.
6.1 The set of the input streams for the object d is
formed (10).
6.2 The set
e
H
is formed using (6). Thus,
consider the expression
dd
x
E
and (11), (12) and
(13). Thus:
},{ cbH
e
54 .
As
e
NN
d
and
ed
H
, then between
classes
)(eC
and
)(dC
aggregation relation is set.
According to the p.8 the association relation
between classes
)(eC
and
)(dC
is changed to the
aggregation one.
Class diagram that was designed according to
this approach is represented in fig. 2.
Figure 2: Class diagram, designed according to the
proposed approach.
8 APPLICATION OF THE
PROPOSED APPROACH
The schema of development iterations organization
according to the proposed approach is represented in
fig.3.
Changing aspects in software development
iterations, namely algorithms, software functional
requirements, business needs and processes correct
behavioral software models in every iteration. It
initiates correction of class diagrams (adding,
replacement or removement some components). Due
to possibility of providing automatic transformation
the proposed approach allows stakeholders to
concentrate on software behavioral aspects, instead
verification, checking and making correction to class
diagram.
MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
452
Figure 3: the schema of iteration organization according to
the proposed approach.
9 CONCLUSIONS
The survey of papers on software model
transformation and investigation of other MDA
problems shows that researchers usually present
transformation technics for software models of the
same type (for example, from static into static or
from dynamic into dynamic).
But the task of designing approaches to
transformation of dynamic software models into
static ones is a vital task of MDA.
The use of the approach to class diagram design
and of the rules of defining relations between its
constituents that are suggested in this paper will
allow:
designing new and specifying the existing source
software models for refactoring in paper
(Acretoaie, 2013);
generating test cases in the approach suggested
in paper (Gupta, 2012), at the same time using
information contained in several dynamic
software models based on analytical
representations of dynamic software models;
extending the syntax suggested in paper (Whittle,
2009) for representing source software models.
Using the approach for transformation of
behavioral software models into static ones will
allow efficiency improvement of solving problems
concerning further processing of changed software
static models.
The rules of defining relations between class
diagram constituents suggested in this paper can be
used in methods and techniques employed for
solving software model transformation problems.
The use of such methods and techniques is helpful in
solving many vital problems of MDA.
REFERENCES
Gupta, S., Singla, J., 2012. A component-based approach
for test case generation. International Journal of
Information Technology 5.2,Pages 239-243, 2012.
Gandomani, T. J., Zulzalil, H., Ghani, A. A. A., & Sultan,
A. B. M., 2013. Towards Comprehensive and
Disciplined Change Management Strategy in Agile
Transformation Process. http://www.maxwellsci.com/
print/rjaset/v6-2345-2351.pdf.
Chebanyuk, E., Algebra describing software static models.
International journal “Information technologies &
knowledge” 7.1, Pages 83-93, 2013.
Acretoaie, V., Delivering the Next Generation of Model
Transformation Languages and Tools. Europian
conference of object oriented programming, Pages 2-
10, 2013.
Whittle, J., Jayaraman, P., Elkhodary, A., Moreira, A.,
Ara_ujo, J., MATA: A United Approach for
Composing UML Aspect Models Based on Graph
Transformation. In: Transactions on Aspect-Oriented
Software Development VI - Special Issue on Aspects
and Model-Driven Engineering, Pages 191-237,
Springer, 2009.
Byrne, B., M., and Yasser S., Q., The use of uml class
diagrams to teach database modelling and database
design. Friday 5th July 2013 University of
Sunderland, 2013.
AnApproachtoClassDiagramDesign
453
