Toward software artifacts ecosystem
In the process of developing and maintaining a software product, many things are created and used that are called software artefacts. Software artifacts are created, changed, reused, and change relationships in the development and maintenance processes of a software product. The complexity and varie...
Збережено в:
| Дата: | 2021 |
|---|---|
| Автор: | |
| Формат: | Стаття |
| Мова: | English |
| Опубліковано: |
Інститут програмних систем НАН України
2021
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/444 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Репозитарії
Problems in programming| id |
pp_isofts_kiev_ua-article-444 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/6d/985f7f71437727db4779fba86709746d.pdf |
| spelling |
pp_isofts_kiev_ua-article-4442024-04-26T22:46:31Z Toward software artifacts ecosystem Відносно екосистеми артефактів програмного забезпечення Sydorov, N.A. software engineering; software artifact; software ecosystem; programming; programming style; ontology UDC 004.415.2. (043.3) інженерія програмного забезпечення; артефакт програмного забезпечення; екосистема програмного забезпечення; програмування; стиль програмування; онтологія УДК 004.415.2. (043.3) In the process of developing and maintaining a software product, many things are created and used that are called software artefacts. Software artifacts are created, changed, reused, and change relationships in the development and maintenance processes of a software product. The complexity and variety of software artifact relationships require adequate means of description and management. They may be a software artifacts ecosystem. In the article, for the first time, a concept of a software artifact ecosystem is proposed. The concept describes a generic model of the software artifacts ecosystem, which is the Cornerstone ecosystem type and consists of three actors — the platform, the software, and the artifact. Based on the generic model, the SD model of the software artifacts ecosystem is described. The roles of actors in the ecosystem are indicated, the relationships between actors are described. The developer's activities will be more efficient, the software is understandable, and the development and maintenance is cheaper when the styles (standards) are used. As case study, based on the generic model of the software artifacts ecosystem, a declarative model of the programming style ecosystem has been developed. Three-level model of programming style artifact is proposed. The tools and processes for creating and using a programming style artifact are developed and described.Problems in programming 2020; 4: 110-120 У процесі розробки та супроводження програмного продукту створюється і використовується багато речей, які називаються артефактами програмного забезпечення. Артефакти програмного забезпечення створюються, змінюються, повторно використовуються та змінюють взаємозв'язки у процесах розробки та супроводження програмного продукту. Складність та різноманітність взаємозв’язків артефактів програмного забезпечення вимагають адекватних засобів опису та керування. Вони можуть бути екосистемою артефактів програмного забезпечення. У статті вперше запропоновано концепцію екосистеми артефактів програмного забезпечення. Концепція описує загальну модель екосистеми артефактів програмного забезпечення, яка є типом екосистеми Cornerstone і складається з трьох суб'єктів – платформи, програмного забезпечення та артефакту. На основі загальної моделі описана SD модель екосистеми артефактів програмного забезпечення. Вказуються ролі суб'єктів у екосистемі, описуються взаємозв'язки між акторами. Діяльність розробника буде ефективнішою, програмне забезпечення зрозумілим, а розробка та обслуговування дешевше, коли використовуються стилі (стандарти). Як тематичне дослідження, на основі загальної моделі екосистеми артефактів програмного забезпечення була розроблена декларативна модель екосистеми стилю програмування. Запропоновано трирівнева модель артефакту стилю програмування. Розроблено та описано інструменти та процеси для створення та використання артефакту стилю програмування.Problems in programming 2020;4: 110-120 Інститут програмних систем НАН України 2021-01-25 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/444 10.15407/pp2020.04.110 PROBLEMS IN PROGRAMMING; No 4 (2020); 110-120 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2020); 110-120 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2020); 110-120 1727-4907 10.15407/pp2020.04 en https://pp.isofts.kiev.ua/index.php/ojs1/article/view/444/448 Copyright (c) 2021 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2024-04-26T22:46:31Z |
| collection |
OJS |
| language |
English |
| topic |
software engineering software artifact software ecosystem programming programming style ontology UDC 004.415.2. (043.3) |
| spellingShingle |
software engineering software artifact software ecosystem programming programming style ontology UDC 004.415.2. (043.3) Sydorov, N.A. Toward software artifacts ecosystem |
| topic_facet |
software engineering software artifact software ecosystem programming programming style ontology UDC 004.415.2. (043.3) інженерія програмного забезпечення артефакт програмного забезпечення екосистема програмного забезпечення програмування стиль програмування онтологія УДК 004.415.2. (043.3) |
| format |
Article |
| author |
Sydorov, N.A. |
| author_facet |
Sydorov, N.A. |
| author_sort |
Sydorov, N.A. |
| title |
Toward software artifacts ecosystem |
| title_short |
Toward software artifacts ecosystem |
| title_full |
Toward software artifacts ecosystem |
| title_fullStr |
Toward software artifacts ecosystem |
| title_full_unstemmed |
Toward software artifacts ecosystem |
| title_sort |
toward software artifacts ecosystem |
| title_alt |
Відносно екосистеми артефактів програмного забезпечення |
| description |
In the process of developing and maintaining a software product, many things are created and used that are called software artefacts. Software artifacts are created, changed, reused, and change relationships in the development and maintenance processes of a software product. The complexity and variety of software artifact relationships require adequate means of description and management. They may be a software artifacts ecosystem. In the article, for the first time, a concept of a software artifact ecosystem is proposed. The concept describes a generic model of the software artifacts ecosystem, which is the Cornerstone ecosystem type and consists of three actors — the platform, the software, and the artifact. Based on the generic model, the SD model of the software artifacts ecosystem is described. The roles of actors in the ecosystem are indicated, the relationships between actors are described. The developer's activities will be more efficient, the software is understandable, and the development and maintenance is cheaper when the styles (standards) are used. As case study, based on the generic model of the software artifacts ecosystem, a declarative model of the programming style ecosystem has been developed. Three-level model of programming style artifact is proposed. The tools and processes for creating and using a programming style artifact are developed and described.Problems in programming 2020; 4: 110-120 |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2021 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/444 |
| work_keys_str_mv |
AT sydorovna towardsoftwareartifactsecosystem AT sydorovna vídnosnoekosistemiartefaktívprogramnogozabezpečennâ |
| first_indexed |
2024-09-16T04:08:00Z |
| last_indexed |
2024-09-16T04:08:00Z |
| _version_ |
1818568478609637376 |
| fulltext |
Теоретичні і методологічні основи програмування
© N. Sydorov, 2020
110 ISSN 1727-4907. Проблеми програмування. 2020. № 4
UDC 004.415.2. (043.3) https://doi.org/10.15407/pp2020.04.110
N. Sydorov
TOWARD SOFTWARE ARTIFACTS ECOSYSTEM
In the process of developing and maintaining a software product, many things are created and used that are
called software artefacts. Software artifacts are changed, reused, and change relationships in the development
and maintenance processes of a software product. The complexity and variety of software artifact relationships
require adequate means of description and management. They may be a software artifacts ecosystem. In the ar-
ticle, for the first time, a concept of a software artifact ecosystem is proposed. The concept describes a generic
model of the software artifacts ecosystem, which is the Cornerstone ecosystem type and consists of three actors
– the platform, the software, and the artifact. Based on the generic model, the SD model of the software arti-
facts ecosystem is described. The roles of actors in the ecosystem are indicated, the relationships between ac-
tors are described. The developer's activities will be more efficient, the software is understandable, and the de-
velopment and maintenance is cheaper when the styles (standards) are used. As case study, based on the gener-
ic model of the software artifacts ecosystem, a declarative model of the programming style ecosystem has been
developed. Three-level model of programming style artifact is proposed. The tools and processes for creating
and using a programming style artifact are developed and described.
Key words: software engineering, software artifact, software ecosystem, programming, programming style,
ontology.
1. Introduction
In the processes of developing and
maintaining software products, many things
are created and used, which are called arti-
facts. Artifacts can be different in form and
presentation. They can be part of a software
product or provide processes for its develop-
ment and maintenance, be intermediate results
of processes, or be part of other artifacts.
Thus, there is a huge variety of software arti-
facts, including design plans, work products
(specifications, architectural and detailed de-
signs, code, and documentation), user stories,
bug reports, tools, including for processing
artifacts, but not limited to this. Various and
often complex connections are established
between artifacts. Artifacts change, reuse, and
change links in the development and mainte-
nance of a software product. Therefore, arti-
facts play an important role in the software
life cycle whatever of its model and require
the attention of all interested parties.
The software industry is constantly
evolving and changing. Not only products and
technologies are developing. Many software
companies are experimenting with new busi-
ness models, leading to fundamental changes
in the structures of both the company and its
client. Recently, many companies have been
using the concept of “software ecosystem” to
describe development, creating them around
themselves or their products, taking into
account customer connections. Ecosystems
have shown themselves to be a promising man-
agement tool, an evolving software product.
The complexity and diversity of soft-
ware artifact relationships require adequate
description and management tools. This could
be a software artifacts ecosystem. Such an
ecosystem points to more detailed level than a
software ecosystem, but at this level most of
the approaches, methods and tools that are
used in a software ecosystem can be used.
In the article, for the first time, a mod-
el of a software artifacts ecosystem is pro-
posed. Its application is shown on the case of
a programming style ecosystem. Within the
conception framework, a generalized model
of the software artifacts ecosystem is de-
scribed. The ecosystem belongs to the
Cornstoun ecosystem type and consists of
three actors – platform, software and artifact.
The roles of actors in the ecosystem are indi-
cated, connections between actors are de-
scribed. The types, rules, and attributes of
actors, relationships, and actions can be re-
fined for specific software artifacts ecosystem
models. The same applies to analyzing eco-
system properties.
Based on the generic model of the
software artifacts ecosystem, a declarative
model of the programming style ecosystem
has been developed. The programming style
Теоретичні і методологічні основи програмування
111
is an artifact that plays an important role in
the development and maintenance of soft-
ware. The description of the processes of cre-
ation and the use of the programming style is
made by using the ontology.
2. Related works
Software artifacts. In the software life
cycle to support the processes of creating and
maintaining a software product, many differ-
ent artifacts are created and used. Wide rang-
es of components are considered as artifacts,
from documentation, work products and their
parts, to auxiliary tools. Interacting, artifacts
ensure the efficient execution of software life
cycle processes.
In [1], artifacts are analyzed in the
context of reuse as equipment in the sense of
work [2]. At the same time, three goals (writ-
ing, processing and transferring artifacts) and
three aspects of equipment (the in-order-to of
equipment, readiness-to-hand, presence-and-
hand) are considered. In addition, since arti-
facts are analyzed as reusable components
that are embedded in the created software
product, their characteristics are taken into
account: holism, commonality, reusability and
maturity. Considering an artifact as hardware
– a thing built into the context of a software
product, the interaction of the specified char-
acteristics of software artifacts is investigated.
In [3], artifacts are considered in the context
of a software product line and are divided into
three types – architecture, shared components,
and components made from shared ones. For
each type of artifacts, three levels of maturity
are identified, depending on the degree of
integration of the artifact of the corresponding
type into the software product line. In [4],
artifacts are considered as information parts
that are created, modified and used in the
RUP processes. Artifacts can be of different
types and take different forms, from UML
models to executable code, and can be used in
the creation and maintenance of a software
product. Artifacts are the input and output of
actions in RUP processes. In [5], software
documentation as an artifact is considered.
Artifact as a means of representing infor-
mation about software is defined. A mainte-
nance model of documentation as a software
artifact is introduced.
Artifact modeling. In the following
works, attempts are made to build a model of
the artifact.
The paper [6] presents a metamodel
for software artifacts aiming at providing a
new and structured way to represent artifact
content, other than current sections hierarchy.
This work defines an extension to UML/MOF
and SPEM meta-models by means of layers.
The paper [7] discusses the theoretical foun-
dations for the representation and interpreta-
tion of software artifacts. Based on different
levels of perception of artifacts by a person –
the user of artifacts introduces three levels of
representation of artifacts – physical (physical
representation), structural (syntactic structure)
and semantic (semantic content). In addition,
two steps for processing artifacts - parsing the
physical representation, and analyzing the
syntactic structure – the result of the first step
(interpretation) are introduced. A meta model
of artifacts is built on the basis of presentation
levels and processing steps. The work [8]
considers the architecture of tools that provide
the creation and maintenance of metadata
about software artifacts, which form an envi-
ronment consisting of resources – develop-
ment artifacts. Tools to manage the artifact
environment are used.
Artifacts in software development.
The experience of using artifacts in life cycle
processes in several works is considered.
In [9], artifact-oriented development
of embedded systems is considered. A con-
ceptual model of artifact-oriented develop-
ment is proposed, examples of its use are giv-
en. In [10], artifact-oriented model-driven
development is considered. Details a better
understanding on how explicating artifacts
and their relations facilitates traceability of
artifacts, change impact analysis, and interop-
erability of software tools are considered. The
paper [11] concentrates on the paradigm arte-
fact-orientation in requirements engineering
and presents a meta model. This meta model
is inferred from two concrete domain specific
requirements engineering models: one for the
application domain of embedded systems and
one for the application domain of business
information systems. In [12] shown, that сcol-
laborative development of software products
across organizational boundaries in software
Теоретичні і методологічні основи програмування
112
ecosystems adds new challenges to existing
software engineering processes. A new ap-
proach offered for handling the diverse soft-
ware artefacts in ecosystems by adapting fea-
tures from social network sites. In paper [13],
an industrial survey to create an Activity-
Based Artifact Quality Model to define what
this means from a stakeholder’s viewpoint is
proposed. Specifically was conducted. Quali-
ty factors of test artifacts that have a positive
or negative impact on the activities of Agile
testers are explored. Quality model contains
16 quality factors for six test artifacts that are
reportedly relevant to at least five stakehold-
ers in the process. In paper [14] reference
model and a metamodel for traceability are
proposed. The reference model, defined by
the conceptual basis, may be used in the crea-
tion of traceability approaches. The reference
model was used to develop a metamodel. In
paper [15], a generic artifact model based on an
empirical investigation is proposed. The results
of a mapping study in combination with a sys-
tematic literature review to analyze the usage of
artifacts in agile methods are presented.
Towards a software artifacts ecosys-
tem. We are not aware of any work directly
devoted to the consideration of problems as-
sociated with the study of software artifacts
ecosystems. However, there are works, the
results of which can be used to solve these
problems. In [16], attention is rightly drawn
to the fact that in software ecosystems, atten-
tion is now paid to the participants only at the
top level - these are organizations and teams
that create, implement and maintain software
products. However, there is a lower level –
artifacts, the role of which in the life cycle
processes can hardly be overestimated. In
[17], there are requirements for describing
and analyzing software ecosystems, which in
our paper to model software artifacts ecosys-
tems are used.
3. The generic model of software ar-
tefacts ecosystem
This section discusses a generic model
of the software artifact ecosystem. Several
methods are now used to model software eco-
systems [18]. The application of a particular
method depends on the type of ecosystem and
the goals of the modeling. To represent the
software artifacts ecosystem, this work uses
the i* modeling approach [19]. In contrast to
the most commonly used SSN method, which
focuses on describing the software ecosystem
at the top level (product, developer, vendor,
user), the i* approach provides a description
of the ecosystem of a more detailed software
presentation layer that corresponds to the lev-
el software artifacts. Fig. 1 presents generic
model of the software artifacts ecosystem.
When designing an ecosystem, two groups of
requirements are used [17]: descriptive and
analytical.
The first group includes the require-
ments for the definition of actors, connections
between them and their actions. In addition,
the requirements for determining the types,
rules and attributes of actors, connections and
actions are formulated, as well as the re-
quirements for determining the specific char-
acteristics of both the ecosystem as a whole
and its elements, for example, productivity,
efficiency, security.
Fig. 1. The generic model of the software artifacts ecosystem
Теоретичні і методологічні основи програмування
113
The second group includes require-
ments for defining characteristics that provide
analysis of the ecosystem from incentives and
motivation to sustainability and productivity.
Table the actors and roles in the soft-
ware artifacts ecosystem are given (Tabl 1).
The software artifacts ecosystem belongs to
the Cornerstone type, since the basis of the
ecosystem is a technological platform for the
development and maintenance of software,
the functionality of which is extended by us-
ing artifacts [20]. Thus, the actors of the eco-
system are a platform with a management
role, software with a software product role, an
artifact with a support service provider role.
Common connections between actors can be
indicated (Fig. 2). The platform, in the con-
text of which such components as the life
cycle model, organizational and technical
support for development and maintenance are
considered, defines and uses the artifact as an
auxiliary means of implementing processes
and filling the structure of a software product.
The software depends on the platform, which
is the main mean for the implementation of
development and maintenance processes. The
platform uses the artifact directly as a compo-
nent in the software structure or indirectly as
a means of improving the efficiency of the
platform's processes.
The types, rules, and attributes of ac-
tors, relationships, and actions can be refined
for specific ecosystem models of a software
artifact. The same applies to meeting the re-
quirements for the analysis of ecosystem
properties [17].
Table 1. Actors and roles in the software artifacts ecosystem
Ecosystem type Actors The role of the actor in the ecosystem
Cornstoun
ecosystem
Platform Orchestration
Software Product
Artefact Support service provider
Fig. 2. The SD model of the software artefact ecosystem
Теоретичні і методологічні основи програмування
114
4. Case study. The programming
style ecosystem
Today, methods and tools that are
based on reuse have become widespread for
the development and maintenance of software
products. The application of these methods
and tools requires the developer to read, ana-
lyze and understand a significant number of
representations of work products from differ-
ent phases of the software life cycle. Reuse is
now widespread from requirements specifica-
tions to source code and documentation.
Therefore, one of the main requirements for
software is understandability. The developer's
activities will be more efficient, the software
is understandable, and the development and
maintenance is cheaper when the styles
(standards) are use. They will ensure that the
work products of different phases of the life
cycle are understandable [21].
Fig. 3 shows the model of a program-
ming style ecosystem, which is built based on
a generic model of a software artifact ecosys-
tem (Fig. 1).
The artifact in this model is the pro-
gramming style, and the actor, the software, is
represented by that part of it – the source code
for which the programming style is applied.
Artifact – the programming style is platform-
specific, as the style rules depend on a num-
ber of platform conditions, such as the pro-
gramming language, management goals, sche-
dule, risks, and project budget. The program-
ming style is used in the source code con-
struction (the phase of software live cycle)
and affects the efficiency of the construction
and maintenance processes.
Based on the artefact model from
work [7], described the programming style
artefact by the three levels of perception and
the two processing steps (Fig. 4).
Level 1 – Semantic content. The con-
tent represents the meaning of an artefact. The
content is interpreted in the context of the
individual knowledge of the stakeholder (pro-
grammer) or the interpreter of the machine (in
this case – Protégé The content is based on
the rules of the programming style, which are
described by the ontology.
Level 2 – Syntactic Structure. The
structure of an artifact represents the syntactic
expression of its content. The structure of the
artifact is described in Web Ontology Lan-
guage (OWL).
Level 3 – Physical Representation.
The artefact is represented in the file of OWL
text format.
There are two the processing steps.
Processing Step 1 – Parsing. The out-
come of the parsing process is the syntax
structure of the artefact. This process is per-
formed by the OWL parser implemented us-
ing the OWL API [22].
Processing Step 2 – Interpretation. In-
terpretation is the process of extracting the
content (i.e. the meaning) from the structure.
This process is performed by Protégé system.
Fig. 3. The SD model of programming style ecosystem
Теоретичні і методологічні основи програмування
115
Semantics
(Content)
Syntax
(Structure)
Physical
Representation
Protégé
Parsing
Interpretation
Include
Composite structure
Content structure
Meaning
Fig. 4. The levels of perception of programming style artefact
The characteristics of the domain in
which the style is applied are given in tab. 2.
[21]. The activities of a programmer in a do-
main are shown in Fig. 5. The use of the pro-
gramming style as an artifact involves the
implementation of three processes [23]: the
creation of an artifact, as a result of which the
programming language style is built, the use
of the style when programs are writing and
the process changed of the artifact.
Table 2. Characteristics of the style of the program domain
Epoch
Characteristic
Property Factors Means
Period Idea
Principle
of im-
portance
Historical Social Style Elements
Application
of
standards
in coding
2000
Readability,
quality,
safety
Productivity,
maintenance
Standar-
dization
Programming
team, re-
quirements
Modular,
mega pro-
gramming
Composition,
classification
in program-
ming
languages
Теоретичні і методологічні основи програмування
116
Programmer Programming
language style
Program
Studies style
Gets style
Writes the text of
the program
Gets style
Fig. 5. Domain sequence diagram
In fig. 6. The ontology of creating a
programming style is presented. The ontology
describes in detail the participants and actions
taking place in this regard in the programming
style ecosystem. All ontology concepts are
categorized as resources in i* terminology,
with the exception of the <<event>> concept,
which represents a goal. At the same time, the
concepts Coding phase, Party, Programming
language refer to the Platform actor, and the
concepts Creating work product style, Style
party create guide, Style and Programming
language style to the Programming style
actor.
Has-Knowledge-in
<<kind>>
Coding phase
<<category>>
Party
<<event>>
Creating work
products style
<<associative>>
Style party create guide
1
1
11
Is-part-of
<<kind>>
Team
<<kind>>
Person
uses
Is- created-according-to
1
**
Governs
<<kind>>
Programming
language style
*
*
Is-part-of
1
*
<<kind>>
Programming
language
<<category>>
Style
1
1
Fig. 6. Ontology of programming style creation
Теоретичні і методологічні основи програмування
117
Fig. 7. The ontology of using the pro-
gramming style is presented. An ontology
describes the relevant actors and activities in a
programming style ecosystem. The Party,
Coding phase concepts belong to the Platform
actor, the Program, Program style concepts to
the Software actor, and the Using work prod-
uct style, Style party using guide, Program
language style concepts to the Programming
style actor.
To implement the processes of creat-
ing and using a programming style, tools are
created that can be considered, on the one
hand, as resources of the Programming style
artifact, and on the other hand, as artifacts as
part of the Platform artifact. These include the
programming style knowledge base and the
Reasoner. Thus, the programmer, while cod-
ing the program, applies the ontology of the
programming style, both for learning the style
and for checking the observance of the style
in the program. Therefore, two tools are need-
ed - one to create an ontology and support the
programmer in the coding process, and the
second, to control the application of the pro-
gramming style in the source code of the pro-
gram (Fig. 8) [23].
Has-Knowledge-in
<<kind>>
Coding phase
<<category>>
Party
<<kind>>
Program
<<kind>>
Programming
language style
<<event>>
Using work product
style
<<associative>>
Style party using guide
1
1
1
1
Is-part-of
Use
<<kind>>
Team
<<kind>>
Person
1
*
uses
Is- created-according-to
1
**
Governs
aquire
<<kind>>
Program style
1
1
aquire
<<kind>>
Party style
aquire
1
*
Fig. 7. Ontology of using programming style
Fig. 8. Tools usage diagram
Теоретичні і методологічні основи програмування
118
The style analyst, using the first tool -
Protégé, setting up the ontology to the appro-
priate programming style, creating a TBox
(Fig. 6). After setting up, the programmer is
introduced to the programming style with the
help of Protégé. The second tool is functional-
ly similar to the reasoner, but adds a function
for identifying style errors. In terms of de-
scriptive logic, the reasoner verifies the con-
sistency of the ontology (Fig. 9).
Fig. 9. Knowledge base of programming style
Protégé is used to create TBox. It is
part of an ontology with terms describing a
programming style. Assertions about the
source code (ABox) written by the
programmer are created by the corresponding
part of the reasoner. It provides the
appropriate service using the knowledge base
(TBox and ABox). The service includes,
firstly, the verification of the consistency of
the ontology (a direct function of the
reasoner), and secondly, the search for
stylistic errors in the source code of the
program.
5. Results Analysis and Discussion
The results are a development of the
solutions obtained in the works of the author
[21–24]. For the first time, the concept of the
software artifact ecosystem is proposed.
Within the framework of the concept, the ge-
neric model of the software artifact ecosystem
is described. Model belongs to the Cornstoun
ecosystem type and consists of three actors –
platform, software, and artifact. The roles of
actors in the ecosystem are indicated, connec-
tions between actors are described. Based on
the generic model of the software artifact eco-
system, a declarative model of the program-
ming style ecosystem has been developed.
The programming style is an artifact that
plays an important role in the development
and maintenance of software. Using [7], a
three-level artifact model of - programming
style is proposed. The description of the pro-
cesses of creating and using a programming
style is made by applying the ontology. In
continuation of research of the software arti-
fact ecosystem, the description of the actors
of the ecosystem will be expanded and the
types, rules and attributes of actors, links and
actions will be developed. In addition, the
metric provision of the ecosystem in relation
to determining the effectiveness, sustainabil-
ity and reliability of the ecosystem of soft-
ware artifacts will consider.
The work done in research “Research
on software artifacts ecosystems”,
№ 0120U104329.
References
1. Nuwangi S.M., Darshana S. Software arte-
facts as equipment: a new conception to soft-
ware development using reusable software ar-
tefacts. Thirty-Sixth International Conference
on Information Systems. 2015. Texas, USA.
2. Heidegger M. (1927/1962) Being and Time,
Translated by John Macquarrie & Edward
Robinson. USA: Harper & Row.
3. Bosch J. Maturity and Evolution in Software
Product Lines: Approaches, Artefacts and Or-
ganization, Software Product Lines, Second
International Conference, SPLC 2, San Diego,
CA, USA, August 19–22, 2002,
4. Rational Unified Process: Best Practices for
Software development Teams, Rational Soft-
ware White Paper TP026B, Rev. 11/01. 1998.
18 p.
5. Glass R. Software maintenance documenta-
tion, SIGDOC '89, Pittsburg, Pennsylvania,
USA, ACM Press. 1989. Р. 18 – 23.
6. Silva M., Oliveira T., Bastos R., Software
Artifact Metamodel, XXIII Brazilian Sympo-
sium on Software Engineering, 2009.
P. 176 – 186.
7. Fernandez D M., Bohm W., Broy M. Arte-
facts in Software Engineering: A Fundamental
Positioning, International Journal on Software
and Systems Modeling. 2018. 26. 9 p.
https://www.researchgate.net/publication/242502052_Software_Product_Lines_Second_International_Conference_SPLC_2_San_Diego_CA_USA_August_19-22_2002_Proceedings
https://www.researchgate.net/publication/242502052_Software_Product_Lines_Second_International_Conference_SPLC_2_San_Diego_CA_USA_August_19-22_2002_Proceedings
https://www.researchgate.net/publication/242502052_Software_Product_Lines_Second_International_Conference_SPLC_2_San_Diego_CA_USA_August_19-22_2002_Proceedings
Теоретичні і методологічні основи програмування
119
8. Dewar R.G. Managing Software Engineering
Artefact Metadata, Department of Computer
Science, Heriot-Watt University, Edinburgh,
UK. (2005)
9. Bohm W., Vogelsang A. An Artifact-oriented
Framework for the Seamless Development of
Embedded Systems, Model-Based Engineer-
ing of Embedded Systems. Springer Berlin
Heidelberg. 2012. P. 225–234.
10. Butting, A., Greifenberg T, Rumpe B. Wort-
mann: A. On the Need for Artifact Models in
Model-Driven Systems Engineering Projects.
In: Software Technologies: Applications and
Foundations, LNCS 10748. Springer. 2018.
P. 146–153.
11. Fernández D.M., Penzenstadler B., Kuhrmann
M., Broy M., A Meta Model for Artefact-
Orientation:Fundamentals and Lessons
Learned in Requirements Engineering, Lec-
ture Notes in Computer Science. October
2010.
12. Seichter D., Dhungana D., Pleuss A., Haupt-
mann B. Knowledge Management in Software
Ecosystems: Software Artefacts as First-class
Citizens. ECSA 2010. August 23–26, 2010.
Copenhagen. Denmark. P. 119–126.
13. Fischbach J., Mendez D. What Makes Agile
Test Artifacts Useful? An Activity-Based
Quality Model from a Practitioners’ Perspec-
tive, ESEM ’20, October 8–9, 2020, Bari,
Italy.
14. Azevedo B., Jino M., Modeling Traceability
in Software Development: A Metamodel and
a Reference Model for Traceability, ENASE,
School of Electrical and Computer Engineer-
ing. University of Campinas, Brazil, 8 p.
15. Kuhrmann M., Fernández D., Towards Arti-
fact Models as Process Interfaces in Distribut-
ed Software Projects, IEEE workshop pro-
ceedings, 10 p.
16. Seichter D., Dhungana D., Pleuss A., Haupt-
mann B. Knowledge Management in Software
Ecosystems: Software Artefacts as First-class
Citizens, ECSA 2010 August 23–26, 2010.
Copenhagen. Denmark. P. 119–126.
17. Sadi M., Yu E. Designing Software Ecosys-
tems: How Can Modeling Techniques Help?
Springer-Verlag, Berlin Heidelberg. 2015.
15 p.
18. Sydorov N. Software Ecology. Software En-
gineering. 2010. Р. 53–61.
19. Yu E. Modelling Strategic Relationships for
Business Process Reengineering. Ph.D., the-
sis. Dept. of Computer Science, University of
Toronto. 1995.
20. Knodel J., Manikas K. Towards a typification
of software ecosystems. In Fernandes et al.
Software Business – 6th International Confer-
ence. ICSOB 2015. Braga, Portugal. June 10–
12, 2015. Proceedings 2015. vol. 210 of Lec-
ture Notes in Business Information Pro-
cessing. Springer. Р. 60–65.
21. Sydorov N.A. Software Stylistics. Problems
of Programming. 2005. 2,3. P. 245–254.
22. Sidorov N., Sidorova N., Pirog A. Ontology-
driven tool for utilizing programming styles.
Вісник НАУ. 2017. Том 71. № 2. С. 84–93.
23. Sydorov N., Sydorova N., Sydorov E.,
Cholyshkina O., Batsurovska I. Development
of the approach to using a style in software
engineering. Eastern-European Journal of
Enterprise Technologies. 2019. 4/2 (100).
P. 41–51.
24. Sydorov N.A., Sydorova N.N., Sydorov E.N.
Description model of programming style
ecosystem. Problems in programming, special
issue. Proceeding of the UkrProg'2020.
N 2–3. P. 74–81.
Література
1. Nuwangi S.M., Darshana S. Software arte-
facts as equipment: a new conception to soft-
ware development using reusable software ar-
tefacts. Thirty-Sixth International Conference
on Information Systems. 2015. Texas, USA.
2. Heidegger M. (1927/1962) Being and Time,
Translated by John Macquarrie & Edward
Robinson. USA: Harper & Row.
3. Bosch J. Maturity and Evolution in Software
Product Lines: Approaches, Artefacts and Or-
ganization, Software Product Lines, Second
International Conference, SPLC 2, San Diego,
CA, USA, August 19–22, 2002,
4. Rational Unified Process: Best Practices for
Software development Teams, Rational Soft-
ware White Paper TP026B, Rev. 11/01. 1998.
18 p.
5. Glass R. Software maintenance documenta-
tion, SIGDOC '89, Pittsburg, Pennsylvania,
USA, ACM Press. 1989. Р. 18 – 23.
6. Silva M., Oliveira T., Bastos R., Software
Artifact Metamodel, XXIII Brazilian Sympo-
sium on Software Engineering, 2009.
P.176–186
7. Fernandez D M., Bohm W., Broy M. Arte-
facts in Software Engineering: A Fundamental
Positioning, International Journal on Software
and Systems Modeling. 2018. 26. 9 p.
8. Dewar R.G. Managing Software Engineering
Artefact Metadata, Department of Computer
https://www.researchgate.net/publication/242502052_Software_Product_Lines_Second_International_Conference_SPLC_2_San_Diego_CA_USA_August_19-22_2002_Proceedings
https://www.researchgate.net/publication/242502052_Software_Product_Lines_Second_International_Conference_SPLC_2_San_Diego_CA_USA_August_19-22_2002_Proceedings
https://www.researchgate.net/publication/242502052_Software_Product_Lines_Second_International_Conference_SPLC_2_San_Diego_CA_USA_August_19-22_2002_Proceedings
Теоретичні і методологічні основи програмування
120
Science, Heriot-Watt University, Edinburgh,
UK. (2005)
9. Bohm W., Vogelsang A. An Artifact-oriented
Framework for the Seamless Development of
Embedded Systems, Model-Based Engineer-
ing of Embedded Systems. Springer Berlin
Heidelberg. 2012. P. 225–234.
10. Butting, A., Greifenberg T, Rumpe B. Wort-
mann: A. On the Need for Artifact Models in
Model-Driven Systems Engineering Projects.
In: Software Technologies: Applications and
Foundations, LNCS 10748. Springer. 2018.
P.146–153.
11. Fernández D.M., Penzenstadler B., Kuhrmann
M., Broy M., A Meta Model for Artefact-
Orientation:Fundamentals and Lessons
Learned in Requirements Engineering, Lec-
ture Notes in Computer Science. October
2010.
12. Seichter D., Dhungana D., Pleuss A., Haupt-
mann B. Knowledge Management in Software
Ecosystems: Software Artefacts as First-class
Citizens. ECSA 2010. August 23–26, 2010.
Copenhagen. Denmark. P.119–126.
13. Fischbach J., Mendez D. What Makes Agile
Test Artifacts Useful? An Activity-Based
Quality Model from a Practitioners’ Perspec-
tive, ESEM ’20, October 8–9, 2020, Bari,
Italy.
14. Azevedo B., Jino M., Modeling Traceability
in Software Development: A Metamodel and
a Reference Model for Traceability, ENASE,
School of Electrical and Computer Engineer-
ing. University of Campinas, Brazil, 8 p.
15. Kuhrmann M., Fernández D., Towards Arti-
fact Models as Process Interfaces in Distribut-
ed Software Projects, IEEE workshop pro-
ceedings, 10 p.
16. Seichter D., Dhungana D., Pleuss A., Haupt-
mann B. Knowledge Management in Software
Ecosystems: Software Artefacts as First-class
Citizens, ECSA 2010 August 23–26, 2010.
Copenhagen. Denmark. P. 119–126.
17. Sadi M., Yu E. Designing Software Ecosys-
tems: How Can Modeling Techniques Help?
Springer-Verlag, Berlin Heidelberg. 2015.
15 p.
18. Сидоров Н.А. Экология программного
обеспечения. Інженерія програмного за-
безпечення. 2010. № 1. C. 53–61.
19. .Yu E. Modelling Strategic Relationships for
Business Process Reengineering. Ph.D., the-
sis. Dept. of Computer Science, University of
Toronto. 1995.
20. Knodel J., Manikas K. Towards a typification
of software ecosystems. In Fernandes et al.
Software Business – 6th International Confer-
ence. ICSOB 2015. Braga, Portugal. June 10–
12, 2015. Proceedings 2015. vol. 210 of Lec-
ture Notes in Business Information Pro-
cessing. Springer. Р. 60–65.
21. Сидоров Н.А. Стилистика программного
обеспечения. Проблеми програмування.
2018. 2, 3. С. 245–254.
22. Sidorov N., Sidorova N., Pirog A. Ontology-
driven tool for utilizing programming styles.
Вісник НАУ. 2017. Том 71. № 2. С. 84–93.
23. Sydorov N., Sydorova N., Sydorov E.,
Cholyshkina O., Batsurovska I. Development
of the approach to using a style in software
engineering. Eastern-European Journal of
Enterprise Technologies. 2019. 4/2 (100).
P. 41–51.
24. Сидоров Н.А., Сидорова Н.Н., Сидоров
Е.Н. (2020) Дескриптивная модель
экосистемы стиля программирования,
Проблеми програмування, Спеціальний
випуск, Матеріали конференції, УкрПрог.
2020. № 2-3. С. 74–81.
Received 04.11.2020
About author:
Sydorov Nikolay,
Doctor of Technical Sciences, Professor,
Number of scientific publications in
Ukrainian publishing houses – 105.
Number of scientific publications in
foreign publishing houses – 35.
https://orcid.org/0000-0002-3794-780X.
Affiliation:
National Technical University of Ukraine
Igor Sikorsky Kyiv Polytechnic Institute,
Department of Automated Information Pro-
cessing and Control Systems,
03056, Kiev - 56, Prosp. Peremohy, 37.
E-mail: nyksydorov@gmail.com
https://orcid.org/0000-0002-3794-780X
mailto:nyksydorov@gmail.com
|