functional models usually are visualized using UML
(Unified Modeling Language) use case descriptions
and use case diagrams. Hence, the UML use case
diagrams should arise as a substitution of data flow
diagrams from conceptual to branch-level manner of
presentation according to the "parent-child" flow
diagrams. Because of the created use case diagrams,
activity diagrams should come out as part of the
functional model. Afterwards, the sequence,
communication and behavior state machine (BSM)
diagrams have to be created as a part of the dynamic
behavioral models (Hart, 2015). Classes, objects and
class responsibility collaborators (CRC) diagrams
creation is a next step of the project development and
refining the created diagrams according to users’
requirements.
UML, as a graphic language for OOAD, is used
as standard of writing software development plan
using use case scenarios with use case diagrams. As a
case study, this can lead to creating a functional
model of information system (IS) for company for
Information Technology (IT) education. Using use
case diagrams and scenarios, we create conceptual
model of the intended IS, detecting its subsystems and
then, and we describe the complex relationships in
such system among entities, as well as the constraints
of the system.
We need to define the following three components
of the conceptual model: the basic building blocks,
the rules and the common mechanisms of the
software system (Ripon et al., 2012).
In this paper, we present the creation of a
functional model that has to result in the final
software solution-web application for a company for
IT education management. During the specification
phase, we considered the requirements of educative
center’s employees, in order to highlight specific
demands enabling suitable communication among the
collaborators and support successful workflow in the
above-mentioned company.
The rest of the paper is organized as follows. In
Section 2, some uses of functional modelling
software engineering tools are described. In addition,
we made an overview of the development of the
OOAD tools and related works were depicted.
Section 3 highlights the need of OOAD and here we
propose some directions about creating functional
models. In the subsequent section, we perform an
analysis of the system, using the use case diagrams
that describe users’ scenarios and information flow as
well as activities that can be undertaken. In the next
section, we create the user scenarios for each of the
planned activities and for each role. According to
these use case scenarios, a conceptual use case
diagram arises as well as activity diagrams for each
of the defined roles. The concluding remarks of the
model are shown in Section 6.
2 RELATED WORKS
With the advantage of object oriented programming
(OOP) from the mid-seventies and early eighties of
the 20
th
century and the rise of object-oriented
programming languages, there was a need for a
different, alternative way of analyzing and designing
object oriented software applications (OOA)
(Weilkiens, 2011). From 1989 to 1994, the number of
such OO methods increased to approximately 50, but
none of them satisfied all user needs that occurred for
method unification and standardization (Booch G,
2005). At that time, three methods were emphasized:
Object-Oriented Analysis and Design (Booch, G.),
Object Modeling Technique (Rumbaugh) and Object-
Oriented Software Engineering (Jacobson)
(Hoffmann, 2011).
In the mid-1990s, Booch, G., Raumbaugh and
Jacobson exchanged their ideas and began to consider
using of a single method. In the late 1990s a UML
consortium was found, in which several big
companies participated (Hoffman, 2011). UML 1.0
was adopted as a standard for object-oriented
modelling. The UML notation includes multiple
diagrams to model implemented systems (Larman,
2012). According to this concept, a diagram is a
graphic presentation composed of a set of elements
that are parts of a view of particular part of the model.
Although the diagram does not deliver the semantics
of the system, it represents an overview of the entities
of the model (Maguire, 2017). The elements of the
model are grouped into packages. A package contains
the elements, some of which may contain other nested
packages. In this way, the model is organized into a
hierarchical structure containing diagrams that show
the elements of that and other packages, too. The
UML includes many diagrams that are part of the
three aspects of the model: functional, structural and
dynamic (or behavioral) model (Larman, 2012).
UML notation allows combining different types
of diagrams aiming at better understanding of users’
demands and obtaining a better representation of the
real word modelled using use case diagrams
(Weilkiens, 2011). Besides that, UML notation
defines the actors and the external viewpoint of the
system, the roles and scenarios that describe the
system functionalities. The next step is to give
detailed views that underline the activities and lists of
functions that are provided, to define classes with
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
366