An Approach to Build Consistent Software Architecture Diagrams Using Devops System Descriptors Jalves Nicacio

2025-04-30 0 0 1.17MB 13 页 10玖币

侵权投诉

An Approach to Build Consistent Software Architecture Diagrams Using Devops

System Descriptors

Jalves Nicacio

Universit´

e du Qu´

ebec `

a Chicoutimi

Chicoutimi - CA

jalves.mendonca-nicacio1@uqac.ca

Fabio Petrillo

Ecole de Technologie Sup´

erieure - ´

ETS

Montreal - CA

fabio.petrillo@etsmtl.ca

Abstract

System architecture diagrams play an essential role in

understanding system architecture. They encourage more

active discussion among participants and make it easier to

recall system details. However, system architecture dia-

grams often diverge from the software. As a result, they

can interfere with the understanding and maintenance of the

software. We propose an approach to build system architec-

ture diagrams using DevOps system descriptors to improve

the consistency of architecture diagrams. To produce our

approach, we survey problems with architecture diagrams

in the software industry, developing guidelines for creating

architecture diagrams. Next, we produce a taxonomy for

system descriptor concepts and a process to convert system

descriptors into architecture diagrams. We evaluate our ap-

proach through a case study. In this case study, we deﬁned

a Docker Compose descriptor for a newsfeed system and

transformed it into a system architectural diagram using the

proposed approach. Our results indicate that, currently, sys-

tem descriptors generally lead to consistent diagrams only

to a limited extent. However, the case study’s observa-

tions indicate that the proposed approach is promising and

demonstrates that system descriptors have the potential to

create more consistent architectural diagrams. Further eval-

uation in controlled and empirical experiments is necessary

to test our hypothesis in more detail.

Keywords: Architectural diagram consistency, System

architecture, System descriptors, Modelling process, Soft-

ware Systems, Software Architecture, Software Engineer-

ing.

1 Introduction

Nowadays, we see a growing demand for software devel-

opment that is increasingly complex and difﬁcult to main-

tain. Moreover, modern software tends to be more perfor-

mant and deals with quality issues such as scalability, secu-

rity, maintainability, and internationalization.

For this reason, according to Fairbanks [9], software sys-

tems are arguably the largest and most complex artifacts

ever built. To mitigate software’s scale and complexity is-

sues, developers adopt processes and tools, such as software

architectural modeling and, in this context, software archi-

tecture diagrams.

Software architecture diagrams are helpful for under-

standing and communicating about systems, as they encour-

age more active discussion among participants and make it

easier to remember system details [14]. In this sense, soft-

ware architecture diagrams play a signiﬁcant role in facili-

tating system architecture understanding.

However, software architecture diagrams (such as UML

deployment diagrams) often diverge from the software. As

a result, they can adversely affect the understanding and

maintenance of the software. It is a real challenge to vali-

date the consistency of diagrams for modeling software, and

several research papers have presented different approaches

to verifying the consistency of models. Some recurring ap-

proaches are: (1) validation of UML models using consis-

tency rules [11, 1], (2) algorithmic approaches [19], and (3)

the use of graphs [22]. These studies validate a UML model

against another UML model. For example: Checking con-

sistency between UML sequence and state diagrams [19],

between UML structural diagrams and behavioral diagrams

[11], between UML component and deployment diagrams

[22], and so on. Furthermore, even if the models are consis-

tent (one with each other), there is no guarantee that these

models will be consistent with the system in production. An

alternative to ensure consistency of architecture diagrams

with the system in production is to link them to key con-

cepts related to continuous delivery (DevOps).

In the DevOps context, companies model and automate

the high-level architecture of their systems through system

descriptors. System descriptors are infrastructure as code

scripts [23] to automate application conﬁguration manage-

arXiv:2210.11910v1 [cs.SE] 21 Oct 2022

ment and deployment [30]. For example, we can list AWS,

Chef, CloudFormation, Docker Compose, Kubernetes, Pup-

pet, and Terraform as system descriptors technologies.

Thus, software architecture and DevOps share some con-

cerns, such as security, scalability, and system monitoring

[3]. Additionally, adopting systems descriptors proved to

be a prominent approach to increasing the quality and pro-

ductivity of information systems.

In light of the above, we propose an approach to build

software architecture diagrams using DevOps system de-

scriptors to improve the consistency of architectural dia-

grams. The main research question to be addressed is: Does

creating software architecture diagrams using system de-

scriptors improve the consistency of architecture diagrams?

To answer our research question, we report a survey on

problems with architecture diagrams in the software indus-

try, developing a set of guidelines for creating architecture

diagrams. These guidelines were beneﬁcial in the context of

this work, as they helped in the qualitative assessment of the

diagram produced in our approach. Practitioners can also

beneﬁt from the guidelines by understanding what qualities

to expect in an architectural diagram.

Applying our guidelines, we proposed our approach and

developed a case study to evaluate it. In the case study, we

deﬁned a Docker Compose descriptor for a newsfeed sys-

tem and transformed it into a system architectural diagram

using our approach. Finally, we compare the original and

the generated diagram to evaluate the obtained results.

The contributions of the paper are the following. (i) A

meta-descriptor for transforming system descriptors into ar-

chitecture diagrams of distributed systems; (ii) An approach

to designing consistent architecture diagrams; (iii) A set

of guidelines to produce consistent architectural diagrams.

Hence, the novelty of this work is the fact that it uses de-

scriptors to generate architectural diagrams.

Our results indicate that, at the moment, system descrip-

tors generally lead to consistent diagrams only to a limited

extent. However, the case study’s observations indicate that

the proposed approach is promising and demonstrates that

system descriptors have the potential to create consistent ar-

chitectural diagrams.

We organized the remainder of this paper as follows:

Section 2 introduces the main concepts. Section 3 presents

the related work. Then, section 4 presents a survey on the

architectural diagrams problems. Next, the section 5 intro-

duces our approach. We describe in Section 6 a case study

on architectural diagrams generated from system descrip-

tors. We discuss the obtained results in section 7. Finally,

Section 8 concludes the article.

Figure 1: Ad hoc architectural diagram example. Figure

from [32]

2 Background

This session provides some information about the theo-

retical framework linked to this work and background infor-

mation about the tools and technologies used to implement

the proposed approach.

2.1 Architectural Diagrams

A software architecture diagram is a graphical represen-

tation that shows how the elements of a system interact in a

more extensive process. In particular, they help provide an

overview and context of the system.

The UML has two principal diagrams related to software

architecture: component diagram and deployment diagram.

In addition to UML, other efforts have been to advance soft-

ware architecture, such as SysML and ArchiMate. How-

ever, according to [5], many development teams have al-

ready abandoned these notations in favor of simple ”box

and line diagrams” (ad hoc diagrams). Figure 1 shows an

ad hoc architecture diagram of a system.

According to [14], a diagram is better than a text descrip-

tion of the software to promote active discussion among

developers about the details of the project. There are two

striking features in the diagrams: (1) Architectural diagrams

help to understand the system, and (2) Architectural dia-

grams improve communication and collaboration [14].

Inconsistency in architectural diagrams Litvak et al.

[19] states that a consistency problem can arise because

more than one diagram can describe the same aspects of

the model.

To illustrate an example of inconsistency in architectural

diagrams, consider the diagram in Figure 1. Analyzing this

diagram, we could formulate several questions. For ex-

ample, (1) how many services does this system have?; (2)

where is this system deployed?; (3) how much does this dia-

gram consistently communicate enough details to represent

the same system using other languages or graphical nota-

tions, such as UML?

Thus, it is challenging to derive information about the

system when certain visual elements are not present in the

diagram. The idea of consistency in this paper refers to the

understandability of the diagram. Thus, consistency is re-

alized by how helpful the diagram is in understanding the

system.

2.2 System Descriptors

System descriptors are scripts for automating, standard-

izing, and managing infrastructure in production environ-

ments. System descriptors arise in the context of Infras-

tructure as Code (IaC), which uses conﬁguration scripts to

specify the deﬁnition and conﬁguration of the software in-

frastructure required to run a system [2].

In practice, system descriptors are artifacts that describe

a system architecture. Tools such as Chef 1, Dockerﬁle2,

and Puppet3create system descriptions. Container orches-

trators such as Docker-Compose and Kubernetes [8, 16]

also generate system descriptors.

According to [12], system descriptors allow developers

to treat system infrastructure in the same way as code de-

velopment: choose the right tool and implement a solution

that effectively meets the requirements. System descriptors

are easily replicated, versioned, and computer-executable.

While these scripts are good at telling the computer ac-

curate information about the architecture and infrastructure

of the system, diagrams do a better job of communicating

data to humans [10].

2.2.1 System Descriptors Key Concepts

Each system descriptor in the software industry uses its own

terms and concepts to describe a system. The following sec-

tions presents the most important terms and concepts used

by the most common system descriptors.

Key concepts in Docker Compose The key concepts in

Docker Compose are services, volumes, network, image,

and depends-on.

According to the Docker Compose documentation [8],

services represent the containers to be created in the ap-

plication. In addition, the service contains the necessary

settings for the service to run, such as Docker image, en-

vironment variables, and depends-on directive. Depends-

on expresses the dependencies between services at startup

1Chef Infra: available at https://docs.chef.io/chef overview/

2Dockerﬁle: available at https://docs.docker.com/engine/reference/builder

3Puppet: available at https://puppet.com/docs/puppet

and shutdown, while the image directive speciﬁes the image

from which to start the container.

Key concepts in Kubernetes According [16], Kuber-

netes is a portable, extensible, open-source platform for

managing containerized workloads and services. Kuber-

netes also facilitates both declarative conﬁguration and au-

tomation. The main concepts in Kubernetes are pods, ser-

vices, deployments.

Pods are the most minor deployable compute units de-

velopers can create and manage in Kubernetes. It is pos-

sible to create and manage multiple pods in a Kubernetes

cluster through a workload controller such as Deployment.

In this way, the Deployment workload controller automat-

ically manages the number of pod replicas running on the

system.

Kubernetes deﬁnes another concept for centrally man-

aging access to pods: services. Thus, a service is an ab-

straction that deﬁnes a logical set of pods and a policy for

accessing them [16].

Key concepts in Terraform According to [18], the key

concepts in Terraform are provider, resource, resource mod-

ule, infrastructure module, composition, and data source.

Providers are Terraform plugins used to interact with

cloud providers, SaaS providers, and other APIs. Some ex-

amples of providers are: Amazon AWS, Google Cloud Plat-

form, and Microsoft Azure. The Terraform settings must

specify which providers are required for Terraform to in-

stall and use them.

Each provider adds a set of resource types or data

sources that Terraform can manage. A resource belongs to

a provider, accepts arguments, creates attributes, and has a

lifecycle. A resource can be created, retrieved, updated, and

deleted. Some examples of resources that belong to the aws

provider are aws vpc,aws db instance, etc.

3 Related Work

Concerning consistency veriﬁcation in models, several

research papers have presented different approaches to ver-

ifying the consistency of models. Some recurring ap-

proaches are: (1) validation of UML models using consis-

tency rules [11, 1], (2) algorithmic approaches [19], and (3)

the use of graphs [22]. However, they proposed approaches

to validate a UML model against another UML model. We

proposed an approach that applies a valid system descriptor

to generate architectural diagrams.

In addition, other related research focused on the trans-

formation of system descriptors into graphical representa-

tions, such as [25], [7], and [27]. One difference with our

work is that we focus on improving architectural diagrams’

consistency through system descriptors.

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

AnApproachtoBuildConsistentSoftwareArchitectureDiagramsUsingDevopsSystemDescriptorsJalvesNicacioUniversit´eduQu´ebecaChicoutimiChicoutimi-CAjalves.mendonca-nicacio1@uqac.caFabioPetrillo´EcoledeTechnologieSup´erieure-´ETSMontreal-CAfabio.petrillo@etsmtl.caAbstractSystemarchitecturediagramsplayanesse...

展开>> 收起<<

An Approach to Build Consistent Software Architecture Diagrams Using Devops System Descriptors Jalves Nicacio.pdf

共13页,预览3页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

An Approach to Build Consistent Software Architecture Diagrams Using Devops System Descriptors Jalves Nicacio

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: