=Paper=
{{Paper
|id=Vol-2866/ceur_164-172_chebanuk16
|storemode=property
|title=Domain Engineering Approach of Software Requirements Analysis
|pdfUrl=https://ceur-ws.org/Vol-2866/ceur_164-172_chebanuk16.pdf
|volume=Vol-2866
|authors=Olena Chebanyuk,Oleksandr Palagin,Krassimir Markov
|dblpUrl=https://dblp.org/rec/conf/ukrprog/ChebanyukPM20
}}
==Domain Engineering Approach of Software Requirements Analysis==
https://ceur-ws.org/Vol-2866/ceur_164-172_chebanuk16.pdf
UDC 004.415.2.045 (076.5)
DOMAIN ENGINEERING APPROACH OF SOFTWARE
REQUIREMENT ANALYSIS
O.V. Chebanyuk a0000-0002-9873-6010], O.V. Palahin b[0000-0003-3223-1391], K.K. Markov c[0000-0001-5041-1498]
a
National Aviation University, 03058 ave. Lubomira Guzara 1,
b
V.M. Glushkov Institute of Cybernetics of the National Academy of Sciences of Ukraine, 40, Academician Glushkov
Avenue, Kyiv, 03187, Ukraine
c
Institute of Information Theories and Applications, Sofia, 1000, P.O. Box 775, Bulgaria.
Requirement analysis is one of the important processes in software development lifecycle management. In Agile approach
requirements software models are the basic of generating other software development artifacts. Improving requirements
approaches and techniques allows avoiding mistakes in other software development artifacts. Domain engineering fundamentals
is the basic for “template oriented” approaches of software development artifacts designing. Reusing domain models and
knowledge allows adding details in vertical “model to model” transformation operations, refine generated software development
artifacts, organize systematic software reuse and perform many other activities. Paper proposes an approach of requirement
analysis based on UML Use Case diagrams transformations into communication ones and the next refinements of them by means
of information from domain models. The advantages of the proposed approach is the next: proposed transformation method
involves ”many to many” transformation in order to save the semantic of initial model. Domain knowledge are used to complete
communication diagram by means of adding details after transformation to them. In order to perform Use case to communication
transformation graph representation of software models is chosen.
Key words: Domain Engineering, Domain Analysis, Requirement Analysis, Software Model Transformation, UML diagram.
Аналіз вимог є важливим процесом життєвого циклу розробки програмного забезпечення. У гнучких методологіях
розробки програмного забезпечення моделі вимог є такими артефактами розробки програмного забезпечення, що містять
вихідну інформацію для здійснення подальших завдань розробки. Удосконалення методик аналізу вимог дозволяє
уникнути ситуації, коли помилки артефактів, що проектуються при аналізі вимог, переносяться на інші артефакти
розробки програмного забезпечення. Доменна інженерія забезпечує фундаментальні основи для впровадження
«шаблонно-орієнтованих» методик проектування артефактів розробки програмного забезпечення. Повторне
використання доменних моделей та знань дозволяє доповнити інформацію про структуру моделі, що має більш детальну
нотацію після виконання вертикальної трансформації
«з моделі у модель», уточнити спроектований артефакт розробки програмного забезпечення, організувати систематичне
повторне використання програмних модулів та виконати багато інших завдань. У роботі представлено методику аналізу
вимог до програмного забезпечення, що базується на трансформації діаграм прецедентів у діаграми комунікацій з їх
подальшим уточненням за допомогою інформації, що міститься у доменних моделях. Перевагою представленої
методики по зрівнянню
з існуючими є те, що для трансформації використовуються всі складові вихідної моделі з метою перенести її семантику
на результуючу модель. Після трансформації виконується уточнення діаграм комунікацій із використанням накопичених
знань про домен. Вихідною інформацією для трансформації моделей програмного забезпечення їх аналітичне
представлення
у графовій формі.
Ключові слова: доменна інженерія, доменний аналіз, аналіз вимог, трансформація моделей програмного забезпечення, UML
діаграма.
Анализ требований является важным процессом жизненного цикла разработки программного обеспечения. В гибких
методологиях разработки программного обеспечения модели требований являются артефактами разработки
программного обеспечения, которые содержат исходную информацию для осуществления дальнейших задач разработки.
Совершенствование методик анализа требований позволяет избежать ситуации, когда ошибки артефактов, которые
проектируются при анализе требований, переносятся на другие артефакты разработки программного обеспечения.
Доменная инженерия обеспечивает фундаментальные основы для внедрения «шаблонно-ориентированных» методик
проектирования артефактов разработки программного обеспечения. Повторное использование доменных моделей и
знаний позволяет дополнить информацию о структуре модели, имеющей более подробную нотацию после выполнения
вертикальной трансформации «из модели в модель», уточнить спроектированный артефакт разработки программного
обеспечения, организовать систематическое повторное использование программных модулей и выполнить много других
задач. В работе представлена методика анализа требований к программному обеспечению, основанная на
трансформации диаграмм прецедентов в диаграммы коммуникаций с их последующим уточнением с помощью
информации, содержащейся в доменных моделях. Преимуществом представленной методики по сравнению с
существующими является то, что для трансформации используются все составляющие исходной модели с целью
перенести ее семантику на результирующую модель. После трансформации выполняется уточнение диаграмм
коммуникаций с использованием накопленных знаний про домен. Исходной информацией для трансформации моделей
программного обеспечения является их аналитическое представление в графовой форме.
Ключевые слова: доменная инженерия, доменный анализ, анализ требований, трансформация моделей программного
обеспечения, UML диаграмма.
Copyright © 2020 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0). 164
Introduction
In practice, domain engineering finds practical implementation in Software Product Line approach. There are
software engineering standards with recommendations to organize lifecycle processes in AGILE approach (ISO 12207,
ISO 15288, ISO 19770-1, ISO 29119-2, ISO 20000-4). General recommendations of software development lifecycle
process organization are complicated by specific operations aimed to organize an effective reuse of different software
development artifacts. As software models are central development artifacts in AGILE approach operations of their
reuse will allow to avoid designing and other mistakes. In order to organize effective software artifacts reuse scheme it
is necessary to answer on two research questions (RQ):
(RQ1) What should be reused? Other words: how to select proper domain knowledge for reuse?
(RQ2) How to merge domain model with software development artifacts?
Effective solving of these questions propose performing the next activities:
- forming request of searching in domain area through domain artifacts in repository;
- organizing search procedure and defining matching criterion;
- merging domain knowledge with software development artifacts.
Related papers and practical research
Involving Domain engineering into software artifacts reuse started in the end of the previous century. Reuse
researches performed in two directions. Research laboratories of big companies accumulated practical achievements in
this area. Scientific research directed to development of an analytical approaches.
As a result of research laboratories practices analysis shows that the next factors slowed the process of software
artifacts reuse:
Successful search of software development artifacts in Motorola practices was limited because it was some
difference rules using meta-information while preparing information about software artifacts and its further reuse during
search.
IBM focused on architectural solutions reuse. As a procedure of architectural solutions adoption for future
projects is quite complicated, architectural solutions may contain errors or rigid design characteristics.
Hewlett-Packard developer teams make some free procedure of adoption software development life
cycle process including extra processes for preparing high – quality software development artifacts ready for the
further reuse.
Table 1 Summarizing results of research laboratories IBM, Motorola and Hewlett-Packard companies.
Table 1. Level of coverage requirements of software artifacts reuse in application engineering
Application engineering requirements for effective reuse Hewlett
Motorola IBM
of software development artifacts Packard
Formal apparatus of software artifacts reuse + + –
Formal apparatus of software artifacts semantic similarity – + –
Providing maturity level of software development lifecycle processes – – +
Analysis of scientific papers devoted to domain engineering development pointed that there is a list of factors
that slow the development of software artifacts reuse in domain engineering:
1. Absence of the common concept and complex approach of software artifacts reuse information that is based
on gathering information while domain analysis and its further reuse in application engineering processes [1–4].
2. Existing approaches of software artifacts reuse estimation do not contain formal apparatus of choosing the
best software development artifact from the set of possible ones. [5–8].
3. Complex of tasks needed to be solved for software artifact reuse usually performed by means of different
software development tools that use different formats of data representation. Inaccurate data transition between formats
can be a cause of their partially lost or appearing some not expected elements [9–12].
4. Absence of formal methods allowing synchronizing domain models structure when initial information about
domain analysis is changed (text, audio, video, web-site etc.) [13–16].
5. Difficulty to collaborate results of software models processing in text and graphical representation [17–19].
6. Absence of formal approaches of preparation and reuse meta-information about software development
artifacts [20–22].
165
Proposed approach
Proposed approach is grounded on collaboration of knowledge about problem domain that were accumulated in
domain analysis procedure [23] and improvement of requirement analysis procedures. The aim of improvement
requirement analysis procedure is to spread information about Use Case Diagram and design communication diagram
that satisfy the requirements and store the semantics of requirement specification.
From domain analysis artifacts, controlled vocabulary is used. Requirement analysis of artifacts consists of
requirement specification and Use Case Diagram.
Proposed approach is based on performing transformation from Use Case to Communication Diagram,
transforming whole structure of Use Case. Graph representation of UML diagram is chosen. Initial information for
transformation is prepared composing all graph paths from textual representation (XMI) of UML diagram. The concept
of “text to model” transformation is proposed in paper [24].
Data flow of the proposed approach is represented in the figure 1.
Domain Application
Transformation
analysis engineering
Prepare
Desigh
requirement Design
controlled
specification transformation
vocabulary
rules using
Design Use graph
Desigh
Case representation
domain
diagram
models
obtain its
analytical
representation
Prepare
requirement
specification
obtain
communication
diagram
skeleton
[unoptimized
objects]
optimize
communication
diagram
structure
obtain
resulting
diagram
Figure 1. Data flow of the proposed approach
166
In order to solve this task propose the next denotations:
Graph representation of Use Case Diagram, that consider data streams
SM use _ case { path1 , path2 ,..., pathn }, n | SM use _ case |
path ( esg1 , esg 2 ,..., esg p ) ,
esg (ob1 , link , ob2 )
ob1 , ob2 { p, a , c}
link {l , l (include), l ( extends ), l (inh )}
where SM use _ case – denotation of whole Use Case Diagram,
path1 – path in the Use Case Diagram representing one data stream (path in graph),
esg – elementary sub-graph, describing two directly linked objects ob1 and ob2 by means of link.
Objects (ob) in notation of Use Case Diagram can be the next type a – actors; p – precedents; c – comments.
Links in Use Case diagram can be the next types – l(include) – include, l(extends) – extends, l(inh) – inheritance.
SM com { path1 , path2 ,..., pathn }, n | SM com |
path ( esg1 , esg 2 ,..., esg p ) ,
esg (ob1 , m, ob2 )
ob1 , ob2 {a , c, obj}
where SM com – Communication Diagram,
ob1 , ob2 – Communication Diagram objects,
m – Communication Diagram message.
Denote transformation operation from Use Case Diagram to Communication one as: SM ini у SM rez as:
SM use _ case SM com ,
TRANS
where is a set of transformations rules, which are applied when Use Case diagram is transformed into
TRANS
communication one.
A set of domain entities in controlled vocabulary (ConVoc)
ConVoc {c1 , c 2 ,..., c n }, n | ConVoc | .
A set of Use Case diagram precedents is:
Puse _ case { p1 , p2 ,..., pk }
.
p ( w1 , w2 ,..., wt ), p Puse _ case
Let define the transformation rules using proposed denotations.
In order to perform transformation from Use case to Communication diagrams.
Transformation rules represented in the paper [25] are used. Grounding on these rules, it is proposed rule for
transforming whole Use Case diagram into communication one.
Rules for obtaining skeleton of communication diagram
PATH use _ case
TRANS
PATH com
pathuse _ case
TRANS
pathcom
esguse _ case
TRANS
esg com
TRANS {trans1 , trans2 }
trans1 : (a , l , p ) (a, m, obj )
trans2 : ( p1 , l , p2 ) (obj1 , m, obj2 ) ,
where pathuse _ case – path in Use Case Diagram,
167
pathcom – path in Communication Diagram,
esguse _ case – elementary sub-graph in Use Case Diagram,
esgcom – elementary sub-graph in Communication Diagram,
obj – Communication Diagram object.
After performing such a transformation, the next task is to give a name for obtained objects. Denote named
objects as obj(name). The rule of naming object is written in the following way:
ConVoc p { w c | w p, c Convoc}
ConVoc p obj (name) ConVoc p . (1)
The last transformation task is to optimize Communication Diagram structure by means of applying
“self-message” rule. Self-message is the message that is outcomes and incomes to the same communication diagram
object.
if obj1 obj2 in (obj1 , m, obj2 )
.
then (obj1 , m, obj2 ) (obj , m( self ), obj )
Graphically such communication diagram fragment (figure 2,a) is changed to the next (figure 2,b).
m :obj
:obj :obj m(self)
a b
Figure 2. “Self-message” optimization rule: a – obtained communication diagram fragment;
b – optimized communication diagram fragment
Describe the steps of the proposed approach of communication diagram designing that based on Use Case
diagram (application engineering artifact) and controlled vocabulary (domain analysis artifact).
1. Compose of a problem domain controlled vocabulary.
2. Design Use case diagrams from requirement specification.
3. Obtain a skeleton of communication diagram from the Use Case using proposed transformation rules
SM use _ case
TRANS
SM com .
4. Fill communication diagram skeleton by means of objects names using.
5. Entities from controlled vocabulary in Use Case diagram using (1).
6. Optimize structure of communication diagram using self-message rule.
Case study
Consider example of Use case diagram for visualizing data of accounting reports. Report settings are stored in
profiles. Reports visualized in using graphics. Graphics are obtained considering time settings. Use Case Diagram is
represented in the figure 3.
168
setting of diagram time set ting
represent ation parametres p5
p2
<> l(include)2
<> l(include)1
changing profile
p3
l2
saving profile
l4
loading of old profile p7
graphics l6
l1 p1 l3
design p4
l8
Marking max, Export data
min and media l9 from Excel
p6 p8
Figure 3. Use case diagram of visualizing accounting reports
Analytical representation of this diagram is prepared using approach represented in [24]. A set of Path is
containing from six elements. Some part of paths are duplicated. Analytical representation of Use case diagram contains
the initial information for designing of communication diagram structure.
chain1 (a1 , l1 , p1 )
chain2 chain1 ( p1 , l3 , p4 ) chain3 chain1 ( p2 , l2 , p3 )
path1 chain3 ( p3 , l (include)1 , p2 )
path1 chain1 ( p3 , l (include) 2 , p5 )
chain4 chain3 ( p3 , l4 , p4 ) chain5 chain3 ( p3 , l5 , p7 )
chain6 chain1 ( p1 , l3 , p4 ) chain7 chain6 ( p4 , l7 , p6 )
chain8 chain3 ( p7 , l6 , p4 ) chain9 chain8 ( p7 , l4 , p4 )
path3 chain3 ( p7 , l6 , p8 )
path4 chain8 ( p , l , p8 )
path5 chain9 ( p4 , l8 , p8 )
path6 chain6 ( p6 , l8 , p8 )
Expression (2) represents example of transformation Use case diagram path into communication one.
path1(use _ case ) (a1 , l1 , p1 ), ( p1 , l2 , p3 ), ( p3 , l (include)1 , p2 )
path1( com ) (a1 , m1 , obj1 ), (obj1 , m2 , obj3 ), (obj3 , m3 , obj4 ) . (2)
obj1 profile, obj2 profile, obj3 " to define "
The note according to transformation rule names of different objects can be the same. It is pointed to the fact that
the diagram needs the further optimization. Name of object “to define” points, that in order to define the name of
communication diagram object the information from domain knowledge is used. After designing all paths of
communication diagram, its skeleton is composed (figure 4).
169
4 6
:Profile :Profile
2 7
:Profile
1
:Profile :Profile
3
:Graphic
5 8
:Graphic
:Excel
Figure 4. Unoptimized “skeleton” of the Communication Diagram
After performing sequence of Communication Diagram refinement (implementing self-object messaging rule)
obtain diagram that is represented in figure 5 and 6.
4 6
:Profile :Profile
2
7
:Profile
1 :Profile
7
2 :Profile
4
6
3 :Graphic
5 8
:Graphic
:Excel
Figure 5. First- step of communication diagram skeleton optimization (Object profile is optimized)
1 :Profile
7
2
4
6
8
:Graphic :Excel
5
Figure 6. Refined Communication Diagram
The next step is to complete diagram structure by problem domain entities and their properties (figure 7).
Performing this step it is defined, which data streams can be organized in parallel.
170
Profile
1
Visualization term 5 7
1
Diagram type :Graphic Excel
Data source
2.1 5 6
3 2.2 1
2.3 :Data
2.4
Figure 7. Communication Diagram that is complicated from domain knowledge
Conclusion
Known “model to model” transformation approaches do not use the whole structure of initial diagram. It may be
cause of losing some information or performing additional efforts of domain analytics to organize the structure of
resulting diagram. From the other hand, such approaches require additional time and efforts.
Proposed approach aimed to designing of Communication Diagram from Use Case one. It is grounded on usage
of whole Use Case diagram structure while transformation operation is performed. Such a fact allows saving Use Case
semantics after transformation. As proposed approach implements vertical transformation, resulting diagram
complicated by information about problem domain from domain knowledge.
Further research
It is planned to design formal approach allowing reuse domain knowledge while designing different types of
UML diagrams in Software Product Line.
References
1. Hooper J.W., & Chester R.O. (1991). Software reuse: guidelines and methods. Springer Science & Business Media.
2. Marshall J.J., & Downs R.R. (2008, July). Reuse readiness levels as a measure of software reusability. In IGARSS 2008-2008 IEEE
International Geoscience and Remote Sensing Symposium (Vol. 3, pp. III-1414). IEEE.
3. Smith M., & Sodhi J. (1994). Marching Towards a Software Reuse Future. ACM SIGAda Ada Letters, 14(6), 62–72.
4. Vieira M., Madeira H., Cruz S., Costa M., & Cunha J.C. (2011, June). Integrating GQM and Data Warehousing for the Definition of Software
Reuse Metrics. In 2011 IEEE 34th Software Engineering Workshop (P. 112–116). IEEE.
5. Maga C., & Jazdi N. (2009, June). Concept of a domain repository for industrial automation. In Proceedings of the First International Workshop
on Domain Engineering.
6. Komissarchik J., & Komissarchik E. (2008). U.S. Patent N 7,454,430. Washington, DC: U.S. Patent and Trademark Office.
7. Van der Meij L., Isaac A., & Zinn C. (2010, May). A web-based repository service for vocabularies and alignments in the cultural heritage
domain. In Extended Semantic Web Conference (P. 394–409). Springer, Berlin, Heidelberg.
8. Dwyer M.B., Hatcliff J., Robby R., Pasareanu C.S., & Visser W. (2007, May). Formal software analysis emerging trends in software model
checking. In 2007 Future of Software Engineering (P. 120–136). IEEE Computer Society.
9. Whalen M., Cofer D., Miller S., Krogh B.H., & Storm W. (2007, July). Integration of formal analysis into a model-based software development
process. In International Workshop on Formal Methods for Industrial Critical Systems (P. 68–84). Springer, Berlin, Heidelberg.
10. Qin W., Rajagopalan S., & Malik S. (2004, June). A formal concurrency model based architecture description language for synthesis of
software development tools. In ACM SIGPLAN Notices (Vol. 39, N 7, P. 47–56). ACM.
11. Fraser M.D., & Vaishnavi V.K. (1997). A formal specifications maturity model. Communications of the ACM, 40(12), 95–104.
12. Satyananda T.K., Lee D., Kang S., & Hashmi S.I. (2007, August). Identifying traceability between feature model and software architecture in
software product line using formal concept analysis. In 2007 International Conference on Computational Science and its Applications (ICCSA
2007) (P. 380–388). IEEE.
13. Markopoulos P. (2013). A compositional model for the formal specification of user interface software (Doctoral dissertation).
14. Bjorner D. (2019). Domain analysis and description principles, techniques, and modelling languages. ACM Transactions on Software
Engineering and Methodology (TOSEM), 28(2), 1-67.
15. Cao L., Liu J., Wang Q., Jiang C., & Zhang L. (2019). An efficient structural uncertainty propagation method based on evidence domain
analysis. Engineering Structures, 194, 26–35.
16. Rabiser R., Schmid K., Eichelberger H., Vierhauser M., Guinea S., & Grünbacher P. (2019). A domain analysis of resource and
requirements monitoring: Towards a comprehensive model of the software monitoring domain. Information and Software Technology, 111,
86–109.
17. D'silva V., Kroening D., & Weissenbacher G. (2008). A survey of automated techniques for formal software verification. IEEE Transactions on
Computer-Aided Design of Integrated Circuits and Systems, 27(7), 1165–1178.
18. Ouimet M., & Lundqvist K. (2007). Formal software verification: Model checking and theorem proving. Embedded Systems Laboratory
Technical Report ESL-TIK-00214, Cambridge USA.
19. Ammann P., & Black P. E. (1999, October). Abstracting formal specifications to generate software tests via model checking. In Gateway to the
New Millennium. 18th Digital Avionics Systems Conference. Proceedings (Cat. No. 99CH37033) (Vol. 2, P. 10-A). IEEE.
171
20. Bennion M., & Habli I. (2014, May). A candid industrial evaluation of formal software verification using model checking. In Companion
Proceedings of the 36th International Conference on Software Engineering (P. 175–184). ACM.
21. Jetley R., Iyer S.P., & Jones P. (2006). A formal methods approach to medical device review. Computer, 39(4), 61–67.
22. Broy M., Krüger I.H., & Meisinger M. (2007). A formal model of services. ACM Transactions on Software Engineering and Methodology
(TOSEM), 16(1), 5.
23. Chebanyuk O. & Palahin O. (2019) Domain Analysis Approach. International journal “Informational Content and Processing”. Volume 6,
Number 2, 2019, 3–20.
24. Chebanyuk О. (2018) An Approach of Text to Model Transformation of Software Models. In Proceedings of the 13th International Conference
on Evaluation of Novel Approaches to Software Engineering (ENASE 2018), 432–439 (видання індексується у SCOPUS)
25. Chebanyuk E. (2014) An approach to class diagram designing. Proceedings of the 2st International Conference on Model-Driven Engineering
and Software Development, 7–9 January 2014 y. Portugal, Lisbon. 579–583.
Література
1. Hooper J.W., & Chester R.O. (1991). Software reuse: guidelines and methods. Springer Science & Business Media.
2. Marshall J.J., & Downs R.R. (2008, July). Reuse readiness levels as a measure of software reusability. In IGARSS 2008-2008 IEEE
International Geoscience and Remote Sensing Symposium (Vol. 3, pp. III-1414). IEEE.
3. Smith M., & Sodhi J. (1994). Marching Towards a Software Reuse Future. ACM SIGAda Ada Letters, 14(6), 62–72.
4. Vieira M., Madeira H., Cruz S., Costa M., & Cunha J.C. (2011, June). Integrating GQM and Data Warehousing for the Definition of Software
Reuse Metrics. In 2011 IEEE 34th Software Engineering Workshop (P. 112–116). IEEE.
5. Maga C., & Jazdi N. (2009, June). Concept of a domain repository for industrial automation. In Proceedings of the First International Workshop
on Domain Engineering.
6. Komissarchik J., & Komissarchik E. (2008). U.S. Patent N 7,454,430. Washington, DC: U.S. Patent and Trademark Office.
7. Van der Meij L., Isaac A., & Zinn C. (2010, May). A web-based repository service for vocabularies and alignments in the cultural heritage
domain. In Extended Semantic Web Conference (P. 394–409). Springer, Berlin, Heidelberg.
8. Dwyer M.B., Hatcliff J., Robby R., Pasareanu C.S., & Visser W. (2007, May). Formal software analysis emerging trends in software model
checking. In 2007 Future of Software Engineering (P. 120–136). IEEE Computer Society.
9. Whalen M., Cofer D., Miller S., Krogh B.H., & Storm W. (2007, July). Integration of formal analysis into a model-based software development
process. In International Workshop on Formal Methods for Industrial Critical Systems (P. 68–84). Springer, Berlin, Heidelberg.
10. Qin W., Rajagopalan S., & Malik S. (2004, June). A formal concurrency model based architecture description language for synthesis of
software development tools. In ACM SIGPLAN Notices (Vol. 39, N 7, P. 47–56). ACM.
11. Fraser M.D., & Vaishnavi V.K. (1997). A formal specifications maturity model. Communications of the ACM, 40(12), 95–104.
12. Satyananda T.K., Lee D., Kang S., & Hashmi S.I. (2007, August). Identifying traceability between feature model and software architecture in
software product line using formal concept analysis. In 2007 International Conference on Computational Science and its Applications (ICCSA
2007) (P. 380–388). IEEE.
13. Markopoulos P. (2013). A compositional model for the formal specification of user interface software (Doctoral dissertation).
14. Bjorner D. (2019). Domain analysis and description principles, techniques, and modelling languages. ACM Transactions on Software
Engineering and Methodology (TOSEM), 28(2), 1-67.
15. Cao L., Liu J., Wang Q., Jiang C., & Zhang L. (2019). An efficient structural uncertainty propagation method based on evidence domain
analysis. Engineering Structures, 194, 26–35.
16. Rabiser R., Schmid K., Eichelberger H., Vierhauser M., Guinea S., & Grünbacher P. (2019). A domain analysis of resource and
requirements monitoring: Towards a comprehensive model of the software monitoring domain. Information and Software Technology, 111,
86–109.
17. D'silva V., Kroening D., & Weissenbacher G. (2008). A survey of automated techniques for formal software verification. IEEE Transactions on
Computer-Aided Design of Integrated Circuits and Systems, 27(7), 1165–1178.
18. Ouimet M., & Lundqvist K. (2007). Formal software verification: Model checking and theorem proving. Embedded Systems Laboratory
Technical Report ESL-TIK-00214, Cambridge USA.
19. Ammann P., & Black P. E. (1999, October). Abstracting formal specifications to generate software tests via model checking. In Gateway to the
New Millennium. 18th Digital Avionics Systems Conference. Proceedings (Cat. No. 99CH37033) (Vol. 2, P. 10-A). IEEE.
20. Bennion M., & Habli I. (2014, May). A candid industrial evaluation of formal software verification using model checking. In Companion
Proceedings of the 36th International Conference on Software Engineering (P. 175–184). ACM.
21. Jetley R., Iyer S.P., & Jones P. (2006). A formal methods approach to medical device review. Computer, 39(4), 61–67.
22. Broy M., Krüger I.H., & Meisinger M. (2007). A formal model of services. ACM Transactions on Software Engineering and Methodology
(TOSEM), 16(1), 5.
23. Chebanyuk O. & Palahin O. (2019) Domain Analysis Approach. International journal “Informational Content and Processing”. Volume 6,
Number 2, 2019, 3–20.
24. Chebanyuk О. (2018) An Approach of Text to Model Transformation of Software Models. In Proceedings of the 13th International Conference
on Evaluation of Novel Approaches to Software Engineering (ENASE 2018), 432–439 (видання індексується у SCOPUS)
25. Chebanyuk E. (2014) An approach to class diagram designing. Proceedings of the 2st International Conference on Model-Driven Engineering
and Software Development, 7–9 January 2014 y. Portugal, Lisbon. 579–583.
Received 02.03.2020
Information about the authors:
Chebanyuk Olena Viktorivna,
PhD, associate professor of software engineering department,
PhD, associate professor.
Number of publications – approximately 75.
Publications in Ukrainian journals – 35.
Publications in foreign journals – 35.
PP Hirsh index=4, Scopus – 1.
https://orcid.org/0000-0002-9873-6010 (ORCID name Elena Chebanyuk),
172
Palahin Olexander Vasyliovych,
Doctor of Sciences, Academician of National Academy of Sciences of Ukraine,
Deputy director of Glushkov Institute of Cybernetics, head of department 205.
Publications in Ukrainian journals – 290.
Publications in foreign journals – 45.
H-index: Google Scholar – 15, Scopus – 3.
http://orcid.org/0000-0003-3223-1391,
Markov Krassimir K.,
Professor Dr.
Number of publications: more than 135; 5 monographs.
PP Hirsh index – 11.
https://orcid.org/0000-0001-5041-1498 (ORCID name Krassimir Markov)
WoS ResearcherID L-6845-2018.
Authors’ place of work:
National Aviation University,
03058 ave. Lubomira Guzara 1,
Phone: 044-406-76-41,
E-mail: chebanyuk.elena@gmail.com (chebanyuk.elena@ithea.org)
V.M. Glushkov Institute of Cybernetics of the National Academy of Sciences of Ukraine
40, Academician Glushkov Avenue, Kyiv, 03187, Ukraine
Institute of Information Theories and Applications, Sofia, 1000, P.O. Box 775, Bulgaria.
E-mail: markov@ithea.org
173