Faculty of Computers, Informatics and Microelectronics

Technical University of Moldova

Course Work
On PSI

Autor: lector asistent:

Alexei Dariev Mihai Gavrilita

Chisinau 2017
Contents
Contents
1 Introduction 2
1.1 Domain Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Project Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Interfaces to external systems . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Document references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Technical Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 General characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Functional process requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 Recoverability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.4 System availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 IDEF Diagrams 6
2.1 Context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Level 1, 2 Decomposition Diagram (IDEF0) . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Integrated DEFinition for Process Description Capture Method(IDEF3) . . . . . . . 9
2.4 Data Flow Diagram (DFD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Integration DEFinition for information modeling (IDEF1x) . . . . . . . . . . . . . . 13

3 UML Diagrams 15
3.1 Use Case diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Activity diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Sequence diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Collaboration diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Statechart diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.7 Component diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8 Deployment diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 Conclusion 37

1
1 Introduction
1.1 Domain Description
The topic of this informational system is ”Interactive bibliography. The domain in which can
be integrated is ”Research”.
Research comprises ”creative and systematic work undertaken to increase the stock of knowl-
edge, including knowledge of humans, culture and society, and the use of this stock of knowledge
to devise new applications.” It is used to establish or confirm facts, reaffirm the results of previous
work, solve new or existing problems, support theorems, or develop new theories. A research project
may also be an expansion on past work in the field. Research projects can be used to develop further
knowledge on a topic, or in the example of a school research project, they can be used to further
a student’s research prowess to prepare them for future jobs or reports. To test the validity of
instruments, procedures, or experiments, research may replicate elements of prior projects or the
project as a whole. The primary purposes of basic research (as opposed to applied research) are
documentation, discovery, interpretation, or the research and development of methods and systems
for the advancement of human knowledge. Approaches to research depend on epistemologies, which
vary considerably both within and between humanities and sciences. There are several forms of re-
search: scientific, humanities, artistic, economic, social, business, marketing, practitioner research,
life, technological, etc.
The actual part of my reseach which I’m going to describe in an application is a bibliography.
A bibliography is a listing of the books, magazines, and Internet sources that you use in de-
signing, carrying out, and understanding your science fair project. But, you develop a bibliography
only after first preparing a background research plan a road map of the research questions you
need to answer. Before you compose your bibliography, you will need to develop your background
research plan.
With your background research plan in hand, you will find sources of information that will help
you with your science fair project. As you find this information it will be important for you to write
down where the sources are from. As you find a source, write in all of the necessary information.
This way, when you are typing your bibliography you won’t need to go back to the library and find
any missing information. The more information you write down about your source, the easier it
will be for you to find if you want to read it again.
When you are writing your report, you will use the sources in your bibliography to remind you
of different facts and background information you used for your science fair project. Each time you
use some information from a source, you will need to cite the source that it came from. To cite a
source, simply put the author’s name and the date of the publication in parentheses (Author, date)
in your text. If the person reading your report wants to find the information and read more about
it, they can look up the reference in your bibliography for more detail about the source. That is why
each source you use must be listed in a detailed bibliography with enough information for someone
to go and find it by themselves. In my case I want to simplify the bibliography designing process.

2
1.1.1 Project Description
The system is developed in order to help people which read the research report and help
them to understand on which sources the research-maker relied on. I hope that this system can
offer an improved experience while reading people’s reports. Interactive bibliography is a desktop
application which lets reader to open different links in the pop-up windows and see a part of a video
or a paragraph from a text. For a research maker it provides an application with which will create
a diagram-based bibliography. They will be placed in the bibliography part and will be represented
as rectangles where the link will be placed and they will be interconnected with lines.
After project compilation it may be opened with a PDF viewer and the pop-ups will be accessed
by pointing the mouse on the rectangle. The interface of this application will be represented as
a desktop application which may look like a IDEF or UML-diagram editors. But my application
contains a completely different point of usage.

1.1.2 Interfaces to external systems

This application will interact with the Internet, the File System, and has necessity for the basic
I/O devices such as mouse and keyboard of the machine.
The Internet will be used to gain access to the links from the application to be able to load
them.
The File System is necessary in order to load or save the actual PDFs.

1.1.3 Document references

Used documents are User guide, Information security policy, Countrys legislation. This system
will be developed starting from September 2017 till may 2018.

1.2 Technical Specifications

1.2.1 General characteristics
This desktop application can be easy to download, install and use. To use the application
the user should be ready to have an Internet connection and enough space in his File System. All
supported Operational Systems will be defined later.

1.2.2 Functional process requirements

System components will be discussed later in this work. The main subsystems are:

– PDF Editor, which contains business logic of the program

– User interface, which represents the UI of the application

– Link handler, which supports the interaction between the application and links.

3
1.2.2.1 Object automatzaion
The main objectives of this system are:

– Simplify bibliography reading experience.

– Simplify the access for the used resources.

– Create collections of used resources.

– Interconnect used resources.

– Interact with PDF itself

Here are the main notes which will be realized in this project. So our application makes
bibliography creation process simpler and more efficient. Besides creation process it provides an
easier understanding and accessing of the resources used in the research for the readers.

1.2.2.2 Quality requirements

The main requirements for the software application include:

– Functionality tests.

– Constant updates conforming deadlines and documenting them.

– Providing effective support for new versions deployments.

– Provide support for quality reports.

1.3 Non-functional requirements

1.3.1 Security
The security of this application will be mainly aimed to make recovery copies of the documents
which are being worked on. This will prevent document from unexpected changes. Then the changes
will be applied only on the documents which were saved. If user wants access previous instances of
PDFs he can just simply open previous versions, so as they are saved already as a recovery copy.
The Link access will be performed by already existing Internet protocols, such as HTTP and
HTTPS. Developers are not responsible for all damage user has got from links. All responsibilities
rely on a user.

1.3.2 Reliability
In cases of system failure all data will be lost and user has to make changes again. The system
will be reliable when all technical requirements are satisfied.

4
1.3.3 Recoverability
As was mentioned before the system will make recovery copies in order to prevent unexpected
changes. So now we can say that the initial files will be saved in any case, then can be accessed
again and are ready to perform necessary actions.

1.3.4 System availability

The system will be available anytime for use. This desktop application will be cross-platform
as for Linux distributives and as for Windows.

5
2 IDEF Diagrams
IDEF (Integrated Definition) is a graphical Process Modeling Methodology used to implement
systems and engineer software. These methods are used in data functional modeling, simulation,
object-oriented analysis, and knowledge acquisition.
IDEF is conceived and developed by the United States Air Force in the mid-1970s. It was devel-
oped as a standard method of documenting and analyzing business processes. Now this methodology
is used as a regimented approach to analyzing an enterprise, capturing ”as-is” process models, and
for modeling activities within a business group.
Even though IDEF was originally developed for the manufacturing environment, now this pro-
cess modeling methodology has been applied for wider uses and for software development in general.

2.1 Context diagram

The IDEF0 Context diagram is the starting node tree diagram. It describes the system you are
modeling in its most complete and abbreviated form.
By IDEF specifications, the Context (or A-0) diagram contains one Function/Activity symbol,
describing your model’s top level function (with statements of purpose and viewpoint), and Input,
Control, Output, and Mechanism (ICOM) arrows describing the system’s inputs, controls, outputs,
and mechanisms.
The IDEF0 Context diagram has two symbols available to the user - a symbol representing
the model (a simple rectangle), and a symbol for drawing the function/activity on the diagram.
The model symbol is automatically added to the diagram when it is created - if you denote it as
a context diagram. In Context diagram for process, which makes an abstracted view for a whole
Research process, presented in the Figure 2.1 are input arrows and output arrows. Which would be
described next.
Input arrows which represent required information:
– Research necessity - the actual purpose of the research
– Required information - the information which researchers can rely on
Control arrows, which make boundaries during the research process:
– Deadlines - time boundaries
– Research rules and procedures - certain restrictions or permissions
– Research report rules - restrictions or permissions for the documentation or research report
Mechanism arrows represent people and tools used in research process:
– Personnel - people who make the research
– Resources used in research
Output arrows represent the final result of the Research Process:
– Research results - the final output of the whole research
– Research report - the documentation of the research

6
 Figure 2.1: Context Diagram

2.2 Level 1, 2 Decomposition Diagram (IDEF0)

IDEF0 is a method designed to model the decisions, actions, and activities of an organization or
system. As an analysis tool, IDEF0 assists the modeler in identifying what functions are performed,
what is needed to perform those functions, what the current system does right, and what the current
system does wrong. Thus, IDEF0 models are often created as one of the first tasks of a system
development effort. One problem with IDEF0 is the tendency of IDEF0 models to be interpreted
as representing a sequence of activities.
While IDEF0 is not intended to be used for modeling activity sequences.The abstraction away
from timing, sequencing, and decision logic allows concision in an IDEF0 model. However, such
abstraction also contributes to comprehension difficulties among readers outside the domain. This
particular problem has been addressed by the IDEF3 method. To create IDEF0 diagram we
need to decompose Context diagram created previously.This is a workflow and each part can be
decomposed into smaller parts without going into details. This you can notice in the next diagram.
The main parts in Level 1 diagram are:
– Research preparations - collect data for research. Requires Research necessity, Required in-
formation and Personel to execute, gives prepared data.

7
– Research - the actuall research process, requires Deadlines, Research rules and procedures,
and Resouces used in research, after this part, personnel can collect all results.

– Research results approval - reviews collected results. May require rules to document re-
sults(Research report rules). After this step results a ready to be reported or documented.

– Documentation of research - transforming Ready results for report collected data into the
documentation. Requires Research report rules, Resources used in research are good to be
included. Gives Research results and Research report at the end.

Figure 2.2: Level 1 Decomposition Diagram (IDEF0)

The main parts in Level 2 for the Documentation of research diagram are:

– Research documents editing tool - the initial part of report creation. The actual PDF editor
such as TeXstudio, OverLeaf and etc. Includes Ready results for report, resources used in
research and research report rules. Gives ready report to be compiled.

8
 – Research document compilation tool - compiles PDF. PDF is ready for Interactive bibliogra-
phy to be added.

– Interactive bibliography editing tool - adds interactive bibliography. Includes Resources used
in research. Gives Research results and Research report at the end.May be reviewed.

– Research documents viewer - lets users to review whole research document. Uses Research
report.

Figure 2.3: Level 2 Decomposition Diagram (IDEF0): Documentation of research

2.3 Integrated DEFinition for Process Description Capture Method(IDEF3)

The IDEF3 Process Description Capture Method provides a mechanism for collecting and
documenting processes. IDEF3 captures precedence and causality relations between situations
and events in a form natural to domain experts by providing a structured method for expressing
knowledge about how a system, process, or organization works. IDEF3 descriptions can:

9
 • Record the raw data resulting from fact-finding interviews in systems analysis activities.

• Determine the impact of an organization’s information resource on the major operation sce-
narios of an enterprise.

• Document the decision procedures affecting the states and life-cycle of critical shared data,
particularly manufacturing, engineering, and maintenance product definition data.

• Make system design and design trade-off analysis.

• Manage data configuration and change control policy definition.

• Provide simulation model generation.

IDEF3 captures the behavioral aspects of an existing or proposed system. Captured process
knowledge is structured within the context of a scenario, making IDEF3 an intuitive knowledge
acquisition device for describing a system. IDEF3 captures all temporal information, including
precedence and causality relationships associated with enterprise processes. The resulting IDEF3
descriptions provide a structured knowledge base for constructing analytical and design models.
Unlike simulation languages (e.g., SIMAN, SLAM, GPSS, WITNESS) that build predictive math-
ematical models, IDEF3 builds structured descriptions. These descriptions capture information
about what a system actually does or will do and also provide for the organization and expression
of different user views of the system.
In IDEF3 diagram presented in Figure 2.4 are represented connections between processes and
activities and process flow. The basic building blocks of IDEF3 Process Flow diagram descriptions
are: Units of Behavior, junctions, links, referents, and decompositions.
The main parts of IDEF3 decomposition diagram for Iteractive bibliography editing tool are:
– Open PDF - opens the Research report. Goes to the select Initial point step

– Select initial point - The first step of the interactive bibliography. Creates first reference
rectangle from which we start creating. Includes link from Prepare users data which contains
necessary information. Then allow user to select next tool.

– Prepare users data - Provides a link for the initial point. Borrows data from Resources used
in research.
Then goes XOR operation which allow to user to select tool.

– Select line - User selects connecting line in order to connect Rectangle references.

– Select rectangle - User selects Rectangle reference.

XOR operation closes giving us created objects

– Place objects - places objects on the canvas. Fills with specifications(such as link, type and
name). Transfers objects to the Pop-ups creation.

– Create pop-ups - creates pop-up windows where the reference is being placed. Uses objects
with added specifications. Gives finished bibliography.

10
 Figure 2.4: Decomposition Diagram IDEF3 for Interactive bibliography editing tool

– View PDF - Go through entire PDF with Interactive bibliography in it. Then can go to the
final step.

– Save file - saves the PDF and it can be ready to be exported.

2.4 Data Flow Diagram (DFD)

A data flow diagram (DFD) maps out the flow of information for any process or system. It
uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs,
outputs, storage points and the routes between each destination. Data flowcharts can range from
simple, even hand-drawn process overviews, to in-depth, multi-level DFDs that dig progressively
deeper into how the data is handled. They can be used to analyze an existing system or model a
new one. Like all the best diagrams and charts, a DFD can often visually say things that would
be hard to explain in words, and they work for both technical and nontechnical audiences, from
developer to CEO. Thats why DFDs remain so popular after all these years. While they work well
for data flow software and systems, they are less applicable nowadays to visualizing interactive,
real-time or database-oriented software or systems.
It is usually beginning with a context diagram as the level 0 of DFD diagram, a simple repre-
sentation of the whole system. To elaborate further from that, we drill down to a level 1 diagram

11
with lower level functions decomposed from the major functions of the system. This could continue
to evolve to become a level 2 diagram when further analysis is required. Progression to level 3, 4
and so on is possible but anything beyond level 3 is not very common. Please bear in mind that
the level of details for decomposing particular function really depending on the complexity that
function.
There are the two categories of a data flow diagram. A Logical DFD visualizes the data flow that
is essential for a business to operate. It focuses on the business and the information needed, not on
how the system works or is proposed to work. However, a Physical DFD shows how the system is
actually implemented now, or how it will be. For example, in a Logical DFD, the processes would
be business activities, while in a Physical DFD, the processes would be programs and manual
procedures.

Figure 2.5: Data flow diagram for Research documents editing tool

Figure 2.5 represents Data flow diagram for Research documents editing tool. It contains next data
stores:

– Results documents - contains Ready results for report and provides necessary data to import
to the PDF creation process.

– Prerared users data - Contains Resources used in the report and provides ready resources to
be used.

12
And also Figure 2.5 represents next processes which manipulate the data:

– Create PDF - Creates the actual PDF with required Research report rules and creates Design
specifications for Interactive bibliography to be added.

– Add interactive bibliography - Adds interactive bibliography using ready resources. Then,
after all preparations are done user can Design interactive bibliography.

– Design interactive bibliography - Creation process of interactive bibliography objects. Then

the report can be viewed.

– View report - Opens PDF viewer where user can review whole report after this report can be
compiled.

2.5 Integration DEFinition for information modeling (IDEF1x)

IDEF1X is a method for designing relational databases with a syntax designed to support
the semantic constructs necessary in developing a conceptual schema. A conceptual schema is a
single integrated definition of the enterprise data that is unbiased toward any single application
and independent of its access and physical storage. Because it is a design method, IDEF1X is not
particularly suited to serve as an AS-IS analysis tool, although it is often used in that capacity as
an alternative to IDEF1. IDEF1X is most useful for logical database design after the information
requirements are known and the decision to implement a relational database has been made. Hence,
the IDEF1X system perspective is focused on the actual data elements in a relational database. If
the target system is not a relational system, for example, an object-oriented system, IDEF1X is not
the best method.
There are several reasons why IDEF1X is not well-suited for non-relational system implemen-
tations. IDEF1X requires, for example, that the modeler designate a key class to distinguish one
entity from another, whereas object-oriented systems do not require keys to individuate one object
from another. Further, in those situations where more than one attribute or set of attributes will
serve equally well for individuating IDEF1X entities, the modeler must designate one as the pri-
mary key and list all others as alternate keys. Explicit foreign key labeling is also required. The
resulting logical design IDEF1X models are intended to be used by the programmers who take the
blueprint for the logical database design and implement that design. However, the IDEF1X model-
ing language is sufficiently similar to IDEF1 in that models generated from the IDEF1 information
requirements can be reviewed and understood by the ultimate users of the proposed system.
Although the terminology between IDEF1 and IDEF1X is very similar, there are fundamental
differences in the theoretical foundations and concepts of the two methods. An entity in IDEF1X
refers to a collection or set of similar data instances that can be individually distinguished from
one another. Individual members of the set are called entity instances. Thus, a box in IDEF1X
represents a set of data items in the real-world realm. An attribute is a slot value associated with
each individual member of the set. The relationship that exists between individual members of
these sets is given a name. In this case, this relation establishes a referential integrity constraint.
A powerful feature of IDEF1X is its support for modeling logical data types through the
use of a classification structure or generalization/specialization construct. This construct is an
attempt to overlay models of the natural kinds of things that the data represents whereas the boxes,

13
or entities, attempt to model types of data things. These categorization relationships represent
mutually exclusive subsets of a generic entity or set. Subsets of the superset cannot have common
instances. The unique identifier attribute for each subset is the same attribute as that for a generic
entity instance.
As Interactive Bibliography application will not have physical database, I’ve tried to implement
it in a logical way. You can see it in Figure 2.6.

Figure 2.6: Data model diagram IDEF1x

This IDEF1X seems like tables and relationships used in databases. Using this diagram can
help on feature development of database for the system.
Here is an explanation for the tables represented in the Figure 2.6.

– PDF - Represent the actual PDF file with PDFname as a primary key. Field size - the size
of the file, field color scheme - the color pallet used to create initial pdf, field resolution -
represents the image quality of the PDF.

– REFERENCE - represents the Reference rectangle instance. Uses connected link as a primary
key and PDFname as foreign key.Field type - contains the type of the reference, it may be
video or text.

– VIDEO - represents a video instance of a Reference rectangle. Uses link as a foreign key.

– Field length - the length of a video, field resolution - the image quality of a video, field pop-up
dimensions - the size of a pop-up window dimensions.

– TEXT - represents a text instance of a Reference rectangle. Uses link as a foreign key. Field
paragraph - contains the concrete information for a paragraph of the informaion, field pop-up
dimesions - represents the size of the pop-up window, field font - represents the font used to
print the text.

14
3 UML Diagrams
The Unified Modeling Language(UML) is a standard visual modeling language intended to be
used for modeling business and similar processes, analysis, design, and implementation of software-
based systems. UML is a common language for business analysts, software architects and developers
used to describe, specify, design, and document existing or new business processes, structure and
behavior of artifacts of software systems. UML can be applied to diverse application domains (e.g.,
banking, finance, internet, aerospace, healthcare, etc.). It can be used with all major object and
component software development methods and for various implementation platforms.[5] In the ag-
gregate, UML diagrams describe the boundary, structure, and the behavior of the system and the
objects within it. So, in this chapter will be described Memory book system with UML diagrams.

3.1 Use Case diagrams

A use case diagram is a graphic depiction of the interactions among the elements of a system.
A use case is a methodology used in system analysis to identify, clarify, and organize system re-
quirements. In this context, the term ”system” refers to something being developed or operated,
such as a mail-order product sales and service Web site. Use case diagrams are employed in UML
(Unified Modeling Language), a standard notation for the modeling of real-world objects and sys-
tems. System objectives can include planning overall requirements, validating a hardware design,
testing and debugging a software product under development, creating an online help reference, or
performing a consumer-service-oriented task. For example, use cases in a product sales environment
would include item ordering, catalog updating, payment processing, and customer relations. A use
case diagram contains four components.

• The boundary, which defines the system of interest in relation to the world around it.

• The actors, usually individuals involved with the system defined according to their roles.

• The use cases, which are the specific roles played by the actors within and around the system.

• The relationships between and among the actors and the use cases.

Here are represented 3 Use-case diagrams to show which actions user or system can perform in
Interactive Bibliography application.
Figure 3.1 represents use-cases for initializing Interactive bibliography tool. This is initial repre-
sentation of all features which user can use. Here are described things like Open the Interactive
bibliography tool-to start the program, Select a PDF to choose a PDF file to work on, Open PDF
- to load the actual PDF, View PDF - to make a review of the PDF file, and of course to start the
Design of the Interactive bibliography.

15
 Figure 3.1:

Figure 3.2 represents use-cases of all possible users interactions with Interactive Bibliography. You
can notice that one use-case depends on another, this means that you can’t use one without another.
Figure 3.3 represents all use-cases of system’s actions in the application.

16
Figure 3.2: Use-cases for drawing interactive bibliography

Figure 3.3: Use-case diagram for a system

17
3.2 Activity diagrams
Activity diagrams, which are related to program flow plans (flowcharts), are used to illustrate
activities. In the external view, we use activity diagrams for the description of those business pro-
cesses that describe the functionality of the business system. Contrary to use case diagrams, in
activity diagrams it is obvious whether actors can perform business use cases together or indepen-
dently from one another.
Activity diagrams allow you to think functionally. Purists of the object-oriented approach
probably dislike this fact. We, on the other hand, regard this fact as a great advantage, since users
of object-oriented methods, as well as users of functional thinking patterns, find a common and
familiar display format, which is a significant aid for business-process modeling.
The basic purposes of activity diagrams is similar to other four diagrams. It captures the
dynamic behavior of the system. Other four diagrams are used to show the message flow from one
object to another but activity diagram is used to show message flow from one activity to another.
Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing the dynamic nature of a system, but they are also used to construct the executable
system by using forward and reverse engineering techniques. The only missing thing in the activity
diagram is the message part.
It does not show any message flow from one activity to another. Activity diagram is sometimes
considered as the flowchart. Although the diagrams look like a flowchart, they are not. It shows
different flows such as parallel, branched, concurrent, and single.
Activity diagrams are mainly used as a flowchart that consists of activities performed by the
system. Activity diagrams are not exactly flowcharts as they have some additional capabilities.
These additional capabilities include branching, parallel flow, swimlane, etc.
Before drawing an activity diagram, we must have a clear understanding about the elements
used in activity diagram. The main element of an activity diagram is the activity itself. An activity
is a function performed by the system. After identifying the activities, we need to understand how
they are associated with constraints and conditions.
Activity diagram is suitable for modeling the activity flow of the system. An application can
have multiple systems. Activity diagram also captures these systems and describes the flow from
one system to another. This specific usage is not available in other diagrams. These systems can
be database, external queues, or any other system.
For Interactive Bibliography system will be illustrated three Activity diagrams, which will
describe the functionality of this system. In Figure 3.4 is illustrated first Activity diagram. This
diagram illustrates General user activity. It contains Start Node, Activities which are divided
between informational system and user, Activity Final node, decision nodes. The activities present
steps through which goes a user. After accessing Interactive bibliography, the user has an option:
to choose a PDF. After he chooses, he is able to draw interactive bibliography, there he can execute
the same steps again. After PDF is finished , the user may save the PDF or to view it. This decision
node gives possibility to the user to go to another activity.

18
Figure 3.4: Users general activity to start using Interactive bibliography tool

19
Figure 3.5 represents an activity for the user to draw the interactive bibliography. There he starts
with selecting initial point, then adds specifications to the reference and then he can select everything
with connecting lines.

Figure 3.5: Users activities to draw Interactive bibliography

20
Figure 3.6 represents System activities which allow to launch and process the PDF files. First he
calls PDF from a file system, then he calls tools and canvas to perform required actions(they are
both synchronous). Then system displays objects, connects specifications and etc.

Figure 3.6: Activities performed by the system

21
3.3 Sequence diagrams
UML provides two types of diagrams for the representation of interactions: the sequence
diagram and the communication diagram. Both diagrams visualize the exchange of information.
However, the emphasis is different: communication diagrams emphasize the relationships of individ-
ual objects and their topology; sequence diagrams emphasize the chronological course of exchanged
information.
The sequence diagram is used primarily to show the interactions between objects in the se-
quential order that those interactions occur. One of the primary uses of sequence diagrams is in the
transition from requirements expressed as use cases to the next and more formal level of refinement.
Use cases are often refined into one or more sequence diagrams. In addition to their use in designing
new systems, sequence diagrams can be used to document how objects in an existing system cur-
rently interact. This documentation is very useful when transitioning a system to another person
or organization.
When drawing a sequence diagram, lifeline notation elements are placed across the top of the
diagram. Lifelines represent either roles or object instances that participate in the sequence being
modeled.
UML sequence diagrams model the flow of logic within your system in a visual manner, enabling
you both to document and validate your logic, and are commonly used for both analysis and design
purposes. Sequence diagrams are the most popular UML artifact for dynamic modeling, which
focuses on identifying the behavior within your system. Other dynamic modeling techniques include
activity diagramming, communication diagramming, timing diagramming, and interaction overview
diagramming. Sequence diagrams, along with class diagrams and physical data models are in my
opinion the most important design-level models for modern business application development.
When drawing a sequence diagram, lifeline notation elements are placed across the top of the
diagram. Lifelines represent either roles or object instances that participate in the sequence being
modeled.
Objects calling methods on themselves use messages and add new activation boxes on top
of any others to indicate a further level of processing. If an object is destroyed (removed from
memory), an X is drawn on bottom of the lifeline, and the dashed line ceases to be drawn below it.
It should be the result of a message, either from the object itself, or another.
For Interactive bibliography application will be illustrated three Sequence diagrams, to show
the interactions between objects in the sequential order that those interactions occur.

22
 In first diagram presented in Figure 3.7 is illustrated User’s Interactive bibliography initializa-
tion. It contains objects, messages and time time lines. In this diagram User object communicates
with File system, Tools and Canvas.

Figure 3.7: Sequence diagram for general users actions.

23
Figure 3.8 represents well defined users actions in the Interactive Bibliography application, such as
draw necessary objects and add specifications to them(like link, type and name).

Figure 3.8:

24
Figure 3.9 represents System’s interaction with Internet, Canvas and File system. Interaction with
internet represents the exchange with the link messages from the system. Interaction with File
system saves the file. Interaction with Canvas - paces selected objects on drawable area.

Figure 3.9:

3.4 Collaboration diagrams

A collaboration diagram, also called a communication diagram or interaction diagram, is an
illustration of the relationships and interactions among software objects. A collaboration diagram
shows the objects and relationships involved in an interaction, and the sequence of messages ex-
changed among the objects during the interaction. UML collaboration/communication diagrams
like UML sequence diagrams are used to explore the dynamic nature of your software. Collaboration
diagrams show the message flow between objects in an OO application, and also imply the basic
associations (relationships) between classes.
As we have already discussed, the purpose of interaction diagrams is to capture the dynamic
aspect of a system. So to capture the dynamic aspect, we need to understand what a dynamic
aspect is and how it is visualized. Dynamic aspect can be defined as the snapshot of the running
system at a particular moment

25
 For Interactive bibliography tool will be illustrated three Collaboration diagrams. In diagram
presented in Figure3.10 is presented first Collaboration diagram illustrates the interaction between
a set of Objects involved into general user actions. Those Objects are User, File system , Tools,
Canvas. In this Collaboration could be observed links between those objects, how they interact and
communicate.

Figure 3.10: Communication diagram for general user’s actions

NOTE: Reply messages look like asynchronous messages, but they are still reply messages.

26
Figure 3.11 represents users main actions used in Interactive bibliography. The interactions between
User, Tool and Canvas are supported with communications represented in the Figure 3.11. Every
message is noted with a number and reply messages are noted with asynchronous arrows.

Figure 3.11: Communication diagram for users main actions

NOTE: Reply messages look like asynchronous messages, but they are still reply messages.

Figure 3.12 represents the systems communication with Internet, File system and Canvas. They
all are communicating with supported messages.Interaction with internet represents the exchange
with the link messages from the system. Interaction with File system saves the file. Interaction
with Canvas - paces selected objects on drawable area.

27
 Figure 3.12: Communication diagram for system’s actions

NOTE: Reply messages look like asynchronous messages, but they are still reply messages.

3.5 Class diagram

Class diagram is a static diagram. It represents the static view of an application. Class diagram
is not only used for visualizing, describing, and documenting different aspects of a system but also
for constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints imposed
on the system. The class diagrams are widely used in the modeling of objectoriented systems because
they are the only UML diagrams, which can be mapped directly with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and con-
straints. It is also known as a structural diagram.
The purpose of class diagram is to model the static view of an application. Class diagrams are
the only diagrams which can be directly mapped with object-oriented languages and thus widely
used at the time of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence flow of
the application, however class diagram is a bit different. It is the most popular UML diagram in
the coder community. Class diagrams have a lot of properties to consider while drawing but
here the diagram will be considered from a top level view. Class diagram is basically a graphical
representation of the static view of the system and represents different aspects of the application.
A collection of class diagrams represent the whole system.

28
 For Interactive Bibliography system will be illustrated one Class Diagram. In diagram presented
inFigure 3.12 is presented first Class diagram which is general one. Here are presented classes and
interfaces :

• Interactive bibliography class, which contains a basic class which represents basic functions to
launch an applications and uses 2 interfaces View and Drawable and appears to be a parent
class for a menu.

• Menu a parent class for Save, Open and About classes which displays menu items which can
be accessed.

• Save -saves document

• About - opens information document for Interactive bibliography

• Open - opens a file

• Interface Drawable - is an interface for Tools class which is a parent class for Select colorm
Rectangle and Connection line.

• Tools - lets user to select tool

• ConnectionLine - provides a connection line

• Rectangle - creates a rectangle with necessary specifications

• Select Color - User selects color

• View - interface for Canvas class which represents an area where our Tools can be placed.

• Canvas - creates drawable area

29
Figure 3.13: Class diagram for Interactive bibliography tool

30
3.6 Statechart diagrams
Statechart diagram is a behavior diagram which shows the discrete behavior of a part of the
designed system through finite state transitions. State machine diagrams can also be used to express
the usage protocol of part of a system.
Statechart diagram is one of the five UML diagrams used to model dynamic nature of a system.
They define different states of an object during its lifetime. And these states are changed by events.
So, Statechart diagrams are useful to model reactive systems. Reactive systems can be defined as
a system that responds to external or internal events. Statechart diagram describes the flow of
control from one state to another state. States are defined as a condition in which an object exists
and it changes when some event is triggered. So the most important purpose of Statechart diagram
is to model lifetime of an object from creation to termination.
Statechart diagram is used to describe the states of different objects in its life cycle. Emphasis
is placed on the state changes upon some internal or external events. These states of objects are
important to analyze and implement them accurately.
Statechart diagrams are very important for describing the states. States can be identified as
the condition of objects when a particular event occurs.
Before drawing a Statechart diagram we should clarify the following points:

• Identify the important objects to be analyzed.

• Identify the states.

• Identify the events.

For Interactive bibliography system will be illustrated three Statechart Diagrams, based on
some class. In Figure 3.14 is presented first State Chart diagram for general Interactive bibliography
class. The Object can pass through different states. In initial state object is created, after that,
he passes through some states as Open PDF, creating Empty Canvas , Initial point set, Type set,
Link Set, Name set, All references are drawn which can access previous states for specifications
and iterate through it, Connected with line, Entire PDF viewed and saved. And the final state
represents the end of an objects existence.

31
 Figure 3.14: Statechart diagram for general workflow

In Figure 3.15 is represented the creation of the Canvas and Reference rectangle tool on it. After
rectangle is placed on canvas, the type link and name can be specified. You can place multiple
rectangle on canvas.

Figure 3.15: State chart diagram for creating reference rectangle

32
In figure 3.16 is represented the process of connecting rectangle. After all reference rectangles are
created we can connect them using connecting line tool. Rectangles connection can iterate multiple
times.

Figure 3.16:

3.7 Component diagrams

Component Diagrams are used to model physical aspects of a system. Physical aspects are the
elements like executables, libraries, files, documents etc which resides in a node. So, component
diagrams are used to visualize the organization and relationships among components in a system.
These diagrams are also used to make executable systems.
Component diagrams can also be described as a static implementation view of a system. Static
implementation represents the organization of the components at a particular moment. A single
component diagram cannot represent the entire system but a collection of diagrams are used to
represent the whole.
So the purpose of the component diagram can be summarized as:

– Visualize the components of a system.

– Construct executables by using forward and reverse engineering.

– Describe the organization and relationships of the components.

This diagram is very important because without it the application cannot be implemented efficiently.
A well-prepared component diagram is also important for other aspects of application performance,
maintenance etc.
Before drawing a component diagram the following artifacts are to be identified clearly:

– Files used in the system.

33
 – Libraries and other artifacts relevant to the application.

– Relationships among the artifacts.

Now after identifying the artifacts, the following points need to be followed:

– Use a meaningful name to identify the component for which the diagram is to be drawn

– Prepare a mental layout before producing using tools.

– Use notes for clarifying important points

For Interactive bibliography system were made three diagrams. First one is presented in Figure
3.17. This Component diagram shows system general components from a visual perspective. There
are presented some component like User Interface which interacts with PDF Editor through one
interface. Also, PDF editor uses a link handler for processing links.

Figure 3.17: Component diagram for Overall view

In Figure 3.18 is represented interaction between components in the PDF Editor. PDF viewer
loads Canvas processor which can draw line tool or draw the rectangle. Rectangle tool attaches link
through Link mediator.

34
 Figure 3.18: Component diagram for PDF editor

In figure 3.19 is represented User interface and it’s interaction between the components. Main menu
calls Canvas view and then Canvas view calls tools view and initializes Popup windows for reference
rectangles.

Figure 3.19: Component diagram for User interface

35
3.8 Deployment diagrams
The name Deployment itself describes the purpose of the diagram. Deployment diagrams are
used for describing the hardware components where software components are deployed. Component
diagrams and deployment diagrams are closely related. Component diagrams are used to describe
the components and deployment diagrams shows how they are deployed in hardware. UML is
mainly designed to focus on software artifacts of a system. But these two diagrams are special
diagrams used to focus on software components and hardware components.
So most of the UML diagrams are used to handle logical components but deployment diagrams
are made to focus on hardware topology of a system. Deployment diagrams are used by the system
engineers.
The purpose of deployment diagrams can be described as:
• Visualize hardware topology of a system
• Describe the hardware components used to deploy software components.
• Describe the hardware components used to deploy software components
Deployment diagram represents the deployment view of a system. It is related to the component
diagram. Because the components are deployed using the deployment diagrams. A deployment
diagram consists of nodes. Nodes are nothing but physical hardware used to deploy the application.
For Interactive bibliography system was illustrated one deployment diagram, presented in
Figure 3.20. In this diagram are presented connections between different software and hardware
components, as:
– Device and its operating system where Interactive bibliography tool is located and File system
where PDFs are stored
– Internet resources which provide links to be used in the Interactive bibliography tool.

Figure 3.20: Deployment diagram for Interactive bibliography

36
4 Conclusion
This course work was based on research, modeling and designing some informational system.
This course work will represent theoretical part of bachelor project.
Work began with documentation, research based on the domain of this system. Chosen do-
mainis Research. This domain is vast and this work is oriented more on the visual area, describing
bibliography in a new way. Was made a research, for finding similar applications and principles of
their working and problems which they solve. Was founded some softwares, developed by different
countries and companies.
The first steps, which are described in the first chapter are domain analysis. In this chapter is
described project as general, its objectives, features, purposes, external systems which interact with
this system, document references. Also are describes functional requirements, technical specifica-
tions and non-functional requirements as security, reliability, recoverability and system availability.
The first chapter was based more on research and documentation, the second chapter is more
practical one. In the second chapter and third chapter are described diagrams. In the second
diagram is described IDEF diagrams.
For creating IDEF diagrams were used BPwin and ERwin. In BPwin were created Context dia-
gram, Decomposition diagrams IDEF0, Integration DEFinition for information modeling IDEF1X,
Integrated DEFinition for Process Description Capture Method IDEF3 and Data Flow Diagram
DFD.
Context diagram is used to analyze the functions the system performs and to record the
mechanisms by which these are done. Context diagram contains one Function/Activity symbol,
describing your models top-level function (with statements of purpose and viewpoint), and Input,
Control, Output, and Mechanism (ICOM) arrows describing the systems inputs, controls, outputs,
and mechanisms.
Decomposition diagrams IDEF0 is a method designed to model the decisions, actions, and
activities of an organization or system. Integrated DEFinition for Process Description Capture
Method IDEF3 captures precedence and causality relations between situations and events in a form
natural to domain experts by providing a structured method for expressing knowledge about how
a system, process, or organization works.
A data flow diagram (DFD) is a graphical representation of the flow of data through an
information system, modeling its process aspects. Integration DEFinition for information modeling
IDEF1X is used to produce a graphical information model which represents the structure and
semantics of information within an environment or system.
In the third chapter is analyzed and designed UML diagrams: Use Case, Activity, Sequence,
Statechart, Collaboration, Class, Component and Deployment Diagrams. Each of those diagrams
is described and illustrated for Memory book system.

37
Refences
References
[1] IDEF0, official page,
http://www.idef.com/idefo-functionm odelingm ethod/

[2] IDEF3, official page,

https://www.ibm.com/support/knowledgecenter/SS8PJ79 .5.0/com.ibm.xtools.modeler.doc/t

[3] IDEF1X, official page,

https://en.wikipedia.org/wiki/IDEF1X

[4] UML diagrams, official page,

https://www.uml-diagrams.org/

38