Deriving UML Logic Architectures of Software Product based on a

Cloud Reference Architecture: An Experience Report

Francisco Morais

1 a

, Tiago F. Pereira

1 b

, Carlos Salgado

1 c

, Ana Lima

1 d

, Manuel Pereira

2 e

ao Oliveira

2 f

, Ant

onio Sousa

3 g

and Helena Rodrigues

4 h

CCG - Centro de Computac¸

ao Gr

aﬁca, Campus de Azur

em, Guimar

aes, Portugal

F3M Information systems S.A., Braga, Portugal

HASLab/INESC TEC, Universidade do Minho, Braga, Portugal

Centro ALGORITMI, Escola de Engenharia, Universidade do Minho, Guimar

aes, Portugal

Keywords:

Cloud Computing, Design Methods, Cloud Reference Architecture, Cloud Requirements, Logic Architecture.

Abstract:

Companies are nowadays looking for the development of solutions based on public and private clouds capable

of interoperating with information sources such as other systems, or devices in an IoT and CPS approach, and

subsequently using that information efﬁciently. However, applying appropriate techniques for requirements

engineering and designing logical architectures for that context can be complex. The cloud environments are

very dynamic and are difﬁcult to identify, clarify, and systematically manage cloud requirements. The lack

of requirements engineering methods for this domain carry risks related to incorrect or unjustiﬁed decisions,

which result in subjective project developments. This paper presents the use of NIST Cloud Computing Ref-

erence Architecture in the eliciting of requirements by employing a new approach (the 2P2S technique), that

enables the use of an existing Model-Driven Design method (the 4SRS technique), derive logic architectures

for cloud-based solutions, assuring that the system requirements are based on effective client needs.

1 INTRODUCTION

According to Reese (Reese, 2009), Cloud Comput-

ing (CC) is the evolution of a variety of technologies

that have come together to alter an organization’s ap-

proach to building out an IT infrastructure. Adopting

the cloud and its services brings fundamental changes

in how organizations think and engineer their require-

ments. Moreover, designing logical architectures for

that context can be knotted. One of the problems

is the natural discontinuity between functional and

structural models (Machado et al., 2005). Another

is the requirements modeling for CC, in the degree

to which requirements are correctly understood by

https://orcid.org/0000-0001-6579-8509

https://orcid.org/0000-0001-8155-4491

https://orcid.org/0000-0002-5436-0082

https://orcid.org/0000-0003-3077-6662

https://orcid.org/0000-0001-9470-2764

https://orcid.org/0000-0003-0629-4444

https://orcid.org/0000-0001-8639-5346

https://orcid.org/0000-0002-8978-8804

the cloud service providers and consumers. Unlike

classical requirements engineering, these processes

should cater for scale, decentralization, uncertainties,

and heterogeneity making traditional approaches lim-

ited in their applicability. Thus, matching between

the user requirements and features of the cloud is a

key asset for a correct evaluation of cloud services

and their adoption (Zardari and Bahsoon, 2011). To

accomplish the matching between the user require-

ments and features of the cloud, proper requirements

elicitation and logical architecture are required, to

help increase the comprehensibility of requirements

for cloud service consumers, and model a technical

architecture needed to place the application on the

cloud, exploring cloud computing concepts, architec-

tural references, and SaaS business models.

Since standards and reference models enable the

use of domain best practices, the cloud requirements

should be based on cloud computing models. The Na-

tional Institute of Standards and Technology (NIST)

has developed a logical extension of its cloud deﬁni-

tion by developing the NIST Cloud Computing Ref-

Morais, F., Pereira, T., Salgado, C., Lima, A., Pereira, M., Oliveira, J., Sousa, A. and Rodrigues, H.

Deriving UML Logic Architectures of Software Product based on a Cloud Reference Architecture: An Experience Report.

DOI: 10.5220/0011146700003266

In Proceedings of the 17th International Conference on Software Technologies (ICSOFT 2022), pages 399-409

ISBN: 978-989-758-588-3; ISSN: 2184-2833

399

erence Architecture (NIST CCRA) (Liu, F., Tong, J.;

Mao, J.; Bohn, R.; Messina, J.; Badger, M.; Leaf, D.,

2011). First, we discuss some related work in Sec-

tion 2 on CC requirements engineering approaches.

Section 3 shows the proposed approach for eliciting

requirements and deriving logic architectures for the

cloud. In Section 4, we present our case study. Sec-

tion 5 describes a brief discussion of the results, and

ﬁnally, Section 6 concludes the paper.

2 RELATED WORK

To create a software architecture model, one must un-

derstand the problem, ﬁnd a solution, and evaluate the

ﬁnal result, according to (Souza et al., 2019). Finding

a solution is related to deriving a software architecture

from the requirements speciﬁcation.

Existing software architecture methods offer ways

to derive architectural models from requirements

speciﬁcations. But creating an architectural model

is difﬁcult, especially because requires a balance

between the different forces imposed by different

application domains and quality attributes. Also,

(Souza et al., 2019) refers that the current architec-

tural derivation methods rely heavily on the archi-

tect’s tacit knowledge (experience and intuition), do

not offer sufﬁcient support for inexperienced archi-

tects, and lack explicit evaluation mechanisms. This

leads to poor requirements understanding process, un-

detailed decision-making process, inconsistency be-

tween artifacts, semantic loss, and lack of traceability

between models. (Souza et al., 2019) highlights the

lack of standardized terms, reducing understandabil-

ity, making the communication between stakeholders

inefﬁcient and error-prone. While the standardization

of terms contributes to an established body of lan-

guage, beneﬁcial to software architecture researchers

and practitioners, also could contribute to the adop-

tion of Architecture Description Languages - ADL

(UML, sysML, other). ADLs poor adoption is mainly

because they need to capture design decisions judged

fundamental to satisfy different stakeholder concerns

and also because it is difﬁcult to capture all the differ-

ent concerns with a unique language. Standardization

of terms would facilitate the adoption of ADLs.

The cloud environments are stochastic and dy-

namic, so it is complex to identify, clarify and man-

age cloud requirements in a systematic way (Zardari

and Bahsoon, 2011), (Iankoulova, 2012). According

to (Zalazar A.S., 2017), the CC requirements engi-

neering approaches are mostly concentrated in object-

oriented artifacts and tools. And existing require-

ments engineering processes for CC are generally

about nonfunctional requirements, usually focused on

particular characteristics, as security, privacy, avail-

ability, and other performance aspects. CC is com-

plex to administrate because of dynamism imposed

by the context of having elastic resources (scaling, re-

sizing, on/off), requirements depending on business

changes (peak and non-peak times), consumers being

heterogeneous from different geographic places and

jurisdictions, and distributed systems being managed

remotely.

Authors like (Schrodl and Wind, 2011) conclude

that none of the common models (V-model, Volere,

Extreme programming, and Rational Uniﬁed Process)

is suitable to cover the needs of requirements un-

der cloud computing. Also, there is little informa-

tion about frameworks and methods for supporting

projects for this domain (Klems et al., 2009). Or-

ganizations try to adapt existing techniques or create

new ones for supporting cloud projects, but missing

a systematic guidance (Zardari and Bahsoon, 2011),

(Koitz et al., 2013). The lack of engineering methods

for this domain carried risks related to incorrect or un-

justiﬁed decisions, which result in subjective project

developments. Thus, (Rimal, 2011), states that a big

challenge for CC is the lack of a standard that helps

meet the objectives covering many different aspects

of cloud services.

(Zalazar A.S., 2017) refers that the recent contri-

butions to the requirements engineering approaches,

proposes frameworks to evaluate and to handle re-

quirements for CC projects. However, there are no

well-known tools and automatic techniques support-

ing that CC adoption.

Some approaches pursue the idea of cloud com-

puting as a multidimensional paradigm, related with

cloud services and SLA, and used to identify cloud

requirements and constraints in natural language, and

being the bases for models, and ontologies.

For example, (Repschlaeger et al., 2012) presents

six target dimensions based on general objectives

(service and cloud management, IT security and com-

pliance, reliability and trustworthiness, scope and per-

formance, costs, and ﬂexibility). (Pichan et al., 2015)

consider only three dimensions (technical, organiza-

tional, and legal). Also, (Zalazar A.S., 2017) proposes

ﬁve dimensions (service cloud dimensions of contrac-

tual, ﬁnancial, compliance, operational and techni-

cal), considering CC as a multidimensional paradigm

where different activities, roles, and service dimen-

sions are integrated. Also, because requirements

change frequently, the author states that a stream-

line is needed, to monitor and trace requirements us-

ing traceability mechanisms, but without specifying

them.

ICSOFT 2022 - 17th International Conference on Software Technologies

400

(Souza et al., 2019) refers to the current practice

of deriving architectural models from requirements

speciﬁcation that indicates they have been based on

the architect’s tacit knowledge, without enough sys-

tematization and tool support, lack of standardized

terms in the deﬁnition of software architecture con-

cepts, and lack of existing architecture evaluation

methods. This indicates there is much interest in doc-

umenting architectural decisions to reduce the ”archi-

tectural vaporization knowledge” during the evolu-

tion of architecture. Also mention a variety of strate-

gies for speciﬁc types of development environments,

like cyber foraging, model-driven design, automotive

open software architecture, component-based archi-

tecture, service-based architecture, decision support

for clinical systems, computer game architecture, ref-

erence architectures, architectural patterns, architec-

ture erosion. But concludes that reusing knowledge

about decision-making and evaluation is still a topic

worthy of further research. The current practice of de-

riving architectural models from requirements speci-

ﬁcations still has some gaps.

3 PROPOSED APPROACH

Our approach uses the Use Case and Logical views

deﬁned by The Rational Uniﬁed Process (RUP)

(Reed, 2002). We use the use case view model to

gather the cloud requirements, which are used as in-

put to derive a logic architecture as the ﬁrst view of a

cloud architecture.

3.1 Requirements Elicitation for the

Cloud

Our approach is aligned with the NIST CCRA frame-

work, through the mapping of the NIST layers com-

ponents with the product use cases, and it takes into

account architectural decisions considering a particu-

lar CC deployment model. These decisions are taken

by the software product owner, considering the de-

gree of technological dependency he requires from

the cloud provider for the service model (from more

independent IaaS to more dependent SaaS cloud com-

ponents), and also the degree of dependency from

the cloud infrastructure for the deployment model

(from more dependent public cloud, to more inde-

pendent private cloud infrastructures). NIST CCRA

also identiﬁes the Cloud Carrier (communications op-

erator that provides connectivity and transport of ser-

vices from cloud providers to the cloud consumers),

but this is not considered in our requirements elicita-

tion.

The requirements elicitation for the cloud is ex-

ecuted in two phases, each of them comprising two

steps (2P2S), as depicted in ﬁgure 1. In the ﬁrst phase,

we consider the degree of dependency from the cloud

infrastructure provider. In the second phase, we con-

sider the degree of technological dependency from the

cloud provider.

Figure 1: 2P2S concept diagram.

Phase 1 Step 1: Domain Application Deployment

Model. The aim of the ﬁrst step is to build segmented

views of the application use case model (domain ap-

plication). The use cases are grouped and classiﬁed

as public, private, or community, producing one seg-

mented view per each of these classiﬁcations, named

as Public Domain Application use cases (UC), Pri-

vate Domain Application UCs, and Community Do-

main UCs. This classiﬁcation is based on the product-

owner decisions on the deployment model for the ap-

plication functionality. The result of this step is de-

picted in ﬁgure 2 (left side part), which considers a sit-

uation where domain application functionality is split

Deriving UML Logic Architectures of Software Product based on a Cloud Reference Architecture: An Experience Report

401

across the three deployment models. The preﬁx let-

ter of the UC numbering is only used here for read-

ability, distinguishing between the several segmented

views. The UC numbering should follow known tech-

niques as the Volere Template (Robertson and Robert-

son, 2000).

Phase 1 Step 2: Cloud Management Deployment

Model. In the second step, the designer adds to

the UC model the cloud management functionality

(conﬁguration and administration) as described by

the NIST CCRA. These Cloud Management UCs in-

clude all functions related to services necessary for

the management and operations of the services re-

quested or proposed to customers, according to the

service model of the provider and the consumers. In

the same way as above, if we consider a situation

where domain application functionality is split across

the three deployment models, we will have the cor-

responding cloud management functionality for each

deployment model of the domain application. The re-

sult of this step is depicted in ﬁgure 2 (right side part).

Graphically, the Use-Case reﬁnement can be repre-

sented as a tree structure. In the level 0 (root level), it

is represented the most abstract requirements that are

related to a lower level of reﬁnement. As template for

describing the cloud management use cases we pro-

pose the following descriptions for level 0 use cases:

• {dU.C.1}, {eU.C.1}, {fU.C.1} Cloud account

support management: involves the set of services

supporting the contract between cloud provider

and cloud consumer in the public cloud. It in-

cludes the components used to perform these

business operations, such as account manage-

ment, contract management, catalog manage-

ment, billing management. These use cases are

detailed in Account management, Contract Man-

agement, Service catalog management, and in-

voicing management level 1 use cases.

• {dU.C.2}, {eU.C.2}, {fU.C.2} Cloud services

provisioning and conﬁguration management: in-

cludes the set of services for provisioning, mon-

itoring, and reporting on cloud services, measur-

ing resource usage and service level management,

such as Quality of Service (QoS) parameters for

the Service Level Agreements (SLA). These use

cases are detailed in Application management,

Platform monitoring, Resource utilization mea-

surement, and SLA management level 1 use cases.

• {dU.C.3}, {eU.C.3}, {fU.C.3} Portability and in-

teroperability management of the cloud: includes

the mechanisms to support data portability, ser-

vice interoperability, and system portability. From

the cloud consumers’ perspective, the activities

of data portability and service interoperability be-

tween public cloud data and external information

systems are performed. These use cases are de-

scribed in Systems Integration and Data Synchro-

nization level 1 use cases.

• {dU.C.4}, {eU.C.4}, {fU.C.4} Cloud security

and privacy management: perform a set of func-

tionalities that allow the platform administrator to

manage backups, monitor activities, and conﬁg-

ure access controls. In a logic of shared respon-

sibilities between the Cloud Provider and Cloud

Consumers, these components are provided by

the Provider for privileged access to resource ser-

vices. The management of application user ac-

counts is the responsibility of the Cloud Con-

sumer. These use cases are detailed in Backup

management, Conﬁguration of data access con-

trol, and Activity monitoring level 1 use cases.

Phase 2 Step 1: Domain Application Service

Model. In this step the objective is to classify the

Domain Application resources and actors according

to the product-owner decisions on the delivery model

(SaaS, IaaS, or PaaS). The classiﬁcation of the actors

promotes the discussion with stakeholders in order to

validate roles and raise functional requirements. The

classiﬁcation of the resources appears in the descrip-

tion of the use cases to be used as non-functional re-

quirements or design decisions later on as modeling

decisions on the Logic Architecture Design. The re-

sult of this step is depicted in ﬁgure 2 (actors on the

left side).

Phase 2 Step 2: Cloud Management Service

Model. The purpose of this last step is to classify

the Cloud Management resources and actors accord-

ing to the product-owner decisions on the delivery

model (SaaS, IaaS, or PaaS). As in the previous step,

this classiﬁcation promotes the discussion with stake-

holders, in order to validate roles and modeling de-

cisions considering the technology dependency from

the cloud providers. The classiﬁcation of the re-

sources appears in the description of the use cases to

be used as non-functional requirements or design de-

cisions later on the Logic Architecture Design. The

result of this step is depicted in ﬁgure 2 (actors on the

right side).

3.2 Logic Architectural Model for the

Cloud

The 4SRS technique, in its original version (Machado

et al., 2005), allows the transformation of the user re-

quirements model into the ﬁrst logical system archi-

tecture, based on mapping of UML use-case diagrams

ICSOFT 2022 - 17th International Conference on Software Technologies

402

Figure 2: Segmented Views of the Use Case UML Diagram.

for UML object diagrams. Our approach is based on

the 4SRS method and takes as input a set of use cases

describing the requirements for the cloud manage-

ment services and domain application services, repre-

senting both the intended application and cloud con-

cerns based on NIST CCRA, of the involved business

and technological stakeholders. This technique is or-

ganized in four steps, to transform use cases into ob-

jects, being this transformation supported by tabular

representations, constituting the main mechanism to

automate the decisions assisted by these four steps.

Each column of the tabular representation, depicted

in the ﬁgure 3, corresponds to a step (or micro-step)

in the execution of the 4SRS method, and shows an

example of this transformation. Next, each of these

four steps is described, applied to the use case dia-

Deriving UML Logic Architectures of Software Product based on a Cloud Reference Architecture: An Experience Report

403

grams mapped to the NIST CCRA reference archi-

tecture, generating a speciﬁcation for a cloud service-

oriented platform (SOA).

Step 1: Creating Objects. In the ﬁrst step each use

case is transformed into three objects, an interface ob-

ject, a data object, and a control object. Each object

receives the reference or numbering of the use case

preceded by the letter ”O”, and a sufﬁx i, d, or c, in-

dicating the category of the object. From this step

onwards there are only objects as modeling entities,

although use cases are still used to introduce require-

ments in the object model.

Step 2: Eliminating Objects. In this step, a deci-

sion is made on which of the three objects should be

kept, to computationally represent each use case, tak-

ing into account its textual description, and the system

as a whole. In addition to this decision to keep ob-

jects from step 1, decisions are also made to eliminate

redundant user requirements, and decisions to dis-

cover new requirements, and in this step, the deﬁnitive

system-level entities are deﬁned. To reduce complex-

ity, this step is composed of seven micro-steps:

• Micro step 2i, classiﬁcation of use cases: each use

case can generate one of eight patterns, if ignoring

the link between objects, by the different combi-

nation of its category (φ, i, c, d, ic, di, cd, icd). The

goal is to transform use cases into objects, giving

clues as to which categories of objects to use and

how to link them together through associations;

• Micro step 2ii, elimination of objects: in this step,

the objects assigned in step 1 are eliminated, since

the assignment of categories i, c, d does not con-

sider the problem domain. It takes into account

the classiﬁcation assigned in micro-step 2i, and

the description of the use case in the context of

the problem domain to be solved;

• Micro step 2iii, naming of objects: the objects not

previously eliminated are named, reﬂecting the

use case and the speciﬁc role of the object in the

main object;

• Micro step 2iv, description of the objects: each

object resulting from the previous micro-step 2iii

is described so that the requirements represent-

ing these objects are included in the object model.

These descriptions should be based on the original

use case descriptions, except if they are classiﬁed

as non-functional requirements (NFR) or design

decisions (DD);

• Micro step 2v, object representation: a decision

is made to eliminate redundancies of user require-

ments as well as discover new requirements. It

constitutes an internal validation that ensures se-

mantic consistency of the object model and dis-

covers anomalies in the use case model;

• Micro step 2vi, global elimination: it is based on

the result of the previous micro-step. Objects that

have come to be represented by others are elim-

inated since their system requirements no longer

belong to them. In this way a coherent object

model is maintained from the requirements point

of view;

• Micro step 2vii, object renaming: the purpose

of this last micro-step of step two, is to rename

the objects that were not deleted in the previous

micro-step, and that represent additional objects.

These new names must fully describe the system

requirements they represent.

Step 3: Packaging and Aggregation. Packaging is

a technique that introduces a (tenuous) semantic co-

hesion between objects, which can be easily reversed

in the modeling phase. In other words, it is used in a

ﬂexible way to obtain a temporary (or deﬁnitive) un-

derstanding of the object model. Aggregation, on the

other hand, imposes a strong semantic cohesion be-

tween objects and is more difﬁcult to be reversed in

the following modeling phases. In other words, ag-

gregation should be used based on modeling options

that are aware of their impact on the considered ob-

jects. Aggregation is typically used when there is a

part of the system that is part of a pre-existing sub-

system, or when modeling takes into account an ar-

chitectural reference model that constrains the object

model. In this way, and this step, the objects main-

tained from the previous step and which offer advan-

tages in being considered together, give rise to aggre-

gations or packages of objects with semantic consis-

tency (stronger or weaker respectively. Thus obtain-

ing the construction of a coherent object model, since

it introduces a semantic layer at an abstraction level

that works as a functional link between the objects.

Step 4: Association of Objects. The last step of the

4SRS technique introduces associations in the object

model, based on the existing information in the use

cases, and on the information generated in the micro-

step 2i. In case the textual description of the use cases

provides clues about the sequence of actions, this

information is used to generate associations between

objects. At the same time, the use case diagram in

UML can itself include associations between use

cases and be used for the object model. In the case

of the micro-step 2i of object classiﬁcation, this

generated information should be used to include

associations between the objects originally obtained

from the same use case.

ICSOFT 2022 - 17th International Conference on Software Technologies

404

Figure 3: Steps of the 4SRS method.

The execution of the 4SRS method ends with the

construction of a logical diagram, which represents

the logical architecture of the functionalities of the

software system. This logical architecture arises as

a result of the application of the 4SRS method to the

user requirements of the cloud management services

and domain application services, and that expresses

the system requirements. The user requirements gave

rise to textual descriptions of each object in the model

and to non-functional intentions classiﬁed as NFR and

DD modeling decisions, if applicable, in micro-step

2iv [4], as bounded contexts, namely: intra-service

behavior; interfaces; data models separation; inter-

service communication; and messaging requirements.

4 CASE STUDY

4.1 The Problem

To face some business challenges in the Textile

and Clothing Industry, the development of Interop-

erability and Digital Thread for a More Competitive

Textile Industry domain (IDT4CTI) project, will be

supported on a platform based on the Industry 4.0

paradigm, mainly adopting cloud computing models,

adopting SOA approaches and interoperability solu-

tions. In this context, the different steps of the gar-

ment manufacturing process leading to numerous iter-

ations and dependencies were designed, with conse-

quent communication and interoperability needs be-

tween the textile company and its subcontractors.

To address the difﬁculties encountered in the current

process and meet the interoperability needs between

the different actors of the Company ecosystem, the

main interactions, and respective sub-processes have

been identiﬁed. The Business processes were char-

acterized, as well as the domain functional and non-

functional requirements. The requirements for this

system were acquired using requirements engineer-

ing techniques, and the result was a collection of arti-

facts, including UML Use Case diagrams. To address

the challenge of deriving a cloud architecture from the

modeled requirements, we describe the application of

the proposed approach in this paper, ﬁrst mapping the

use case diagram to NIST CCRA and obtaining cloud

requirements, and then applying the 4SRS method to

derive a ﬁrst logical architecture for the cloud.

4.2 Cloud Requirements

The cloud requirements result from the application

of the two-phase two-step method (2P2S) described

in section 3.1. In the ﬁrst phase, we discussed with

the software product owner the dependency on the

cloud infrastructure. In the ﬁrst step, the software

product owner decided to deploy its software prod-

uct in a cloud infrastructure with computing resources

available to the general public over the public internet

network, and owned and managed by a Public Cloud

Provider organization. We grouped the domain appli-

cation use cases in one segmented view and classiﬁed

it as a Public Domain Application UC. In a second

step, we added a segmented view classiﬁed as Public

Cloud Management, containing the functions related

to services offered by the public cloud provider, used

by the Domain Application, to be conﬁgured and ad-

ministrated in the Cloud Provider Infrastructure.

In the second phase, we discussed with the soft-

Deriving UML Logic Architectures of Software Product based on a Cloud Reference Architecture: An Experience Report

405

Figure 4: IDT4CTI Platform Level 0 Use Cases UML Diagram.

ware product owner the degree of technological de-

pendency from the cloud provider. In the ﬁrst step, the

decision was to deliver the software product as a SaaS

application. In this case, SaaS Consumers should be

billed based on the number of end-users, time of use,

network bandwidth consumed, the amount of data

stored, and the duration of data stored. We clas-

siﬁed the actors using the Public Domain Applica-

tion as Public Cloud SaaS Consumers. In a second

step, the decision was to deploy the SaaS applica-

tion directly into the Cloud PaaS resources of the

cloud provider. In this case, the cloud provider is

responsible to manage the computing infrastructure,

i.e., managing the runtime software execution stack,

databases, and other middleware components. Ad-

ditionally, the cloud provider is responsible to sup-

port the development, installation, and management,

by providing tools such as integrated development en-

vironments (IDEs), cloud software development ver-

sions, software development kits (SDKs), installation

and management tools.

On the other hand, the product owner has decided

for the control over the domain application and also

for the conﬁguration of the hosting environment, ex-

cepting for the conﬁguration of the underlying infras-

tructure of the platform, such as network, servers, op-

erating systems (OS) or storage. In this case, prod-

uct owners may use the tools and execution resources

provided by Cloud Providers to develop, test, install

and manage applications hosted in a cloud environ-

ment. Following this decision, we classiﬁed actors of

the Public Cloud Management View as Public Cloud

PaaS Consumers and Public PaaS Cloud Provider.

Figure 4 presents the use case diagram for the

highest level of abstraction, level 0, as a result of the

requirements elicitation. This top-level UC diagram

was further reﬁned into a total of thirty-three level-

one UCs. The description of these UCs was omitted

due to space limits. In Figure 5, we present the match-

ing between the thirty-three use cases, that capture the

elicited user requirements (Public Domain Applica-

tion UC and Public Cloud Management UC), and the

features of the NIST CCRA layers components, for

a correct evaluation of cloud services and their adop-

tion. The UC model describes the main functionali-

ties of the platform and their various interactions with

different actors, promoting the association of PaaS

providers, and PaaS and SaaS consumers. The Public

Domain Application UCs refers to the functions that

support the business needs of the Cloud SaaS Con-

sumers actors. The Public Cloud Management View

includes all the functions related to the management

and operations requested or proposed to customers

(Cloud SaaS Consumers actors). It refers to resources

related to the management of user accounts, monitor-

ing cloud resources, portability and interoperability,

and reliability of a public cloud.

4.3 Cloud Architecture

The IDT4CTI Logic Architecture is the result of

the 4SRS applied to the use case model (level-one)

ICSOFT 2022 - 17th International Conference on Software Technologies

406

Figure 5: Mapping NIST layers components with IDT4CTI

UC.

elicited in section 4.2. The IDT4CTI architecture, de-

picted in Figure 6 is constituted by forty components.

The logical architecture, represented as an object di-

agram, identiﬁes the system entities, their responsi-

bilities, and the relationships between the objects. Its

purpose is to show the decomposition of the overall

system without going into detail, and which repre-

sents the logical architecture of the functions of the

IDT4CTI system.

The objects derived from the cloud administration

use case were aggregated into a single ”black box”

package since it will be implemented by native cloud

components from Public Cloud Provider, relating to

account administration in the cloud provider, account

management, contract, billing, service catalog provi-

sioning, backup management, and data access permis-

sions and the tracking of user and service activity in

the use of cloud resources. The cloud conﬁguration

use case objects were aggregated in another package

and included the conﬁguration of cloud services and

resources provisioned from the Public Cloud Provider

component catalog. These objects include the appli-

cation management services and the SLA QoS param-

eters of the provisioned services, the measurement

and usage of cloud resources, monitoring of cloud no-

tiﬁcations and events, and report generation, and the

integration of external systems and data into the plat-

form. This Package is implemented by a native cloud

component from Public Cloud Provider and therefore

presented as a ”black box” package.

In order to group the different architectural com-

ponents we divide the architecture into packages that

represent the main processes of IDT4CTI. This pack-

aging deﬁnes decomposition regions, which contain

semantically cohesive objects, being grouped in the

following 9 packages: P1 Cloud Administration; P2

Cloud Conﬁguration; P3 Message Delivery Manage-

ment; P4 Entity management; P5 Semantic Man-

ager; P6 Notiﬁcation management; P7 Information

model management; P8 Authentication Management;

P9 Message Query Management.

5 DISCUSSION

In this work, we based the elicitation of cloud re-

quirements in the NIST CCRA framework and sys-

tematized a method (2P2S) to be executed in the re-

quirements elicitation phase when building the Use

Case Diagram. The Use Case model allows rep-

resenting the process visualization of a system and

can be considered as a suitable requirement gathering

method for the cloud. The method 2P2S adds seg-

mented views to the domain application’s use case di-

agram, allowing the deployment model for the appli-

cation functionality to be classiﬁed. In the case of the

IDT4CTI case study, we have introduced the cloud re-

quirements in the use case model following the prod-

uct owner perspective of a public cloud deployment

model and compliant with the NIST CCRA frame-

work. Following this, the 2P2S method provided a

segmented view with the associated cloud manage-

ment capability as deﬁned by NIST CCRA, which en-

compasses all functions related to services required

for the domain application’s management and oper-

ations. In the case of the IDT4CTI case study, this

has resulted in a public cloud platform management

view, containing the use cases functionality to conﬁg-

ure and administrate the public cloud provider which

have later given origin, in the logical architecture, to

black box packages (P1 and P2 in ﬁgure 6). It only re-

mained to the product owner the discussion of the ac-

tors required to operate, conﬁgure, or administer these

software packages, such as administrators, program-

Deriving UML Logic Architectures of Software Product based on a Cloud Reference Architecture: An Experience Report

407

Figure 6: IDT4CTI Raw Object UML Diagram.

mers, testers or deployers.

In the following phase, the method classiﬁes the

domain application and the cloud management re-

sources and actors based on the delivery model to val-

idate roles, raise more functional requirements, and

model judgments about cloud provider technology

dependency. In our case study, the application was

classiﬁed as a SaaS delivery model, and the cloud

management was classiﬁed as a PaaS delivery model.

This allowed identifying the actors and correspondent

functionality which have later given origin, in the log-

ical architecture, to the identiﬁcation of design deci-

sions concerning the data objects, packaged as ser-

vices and picked from the provider’s service catalog

(database services).

This approach simpliﬁes the procedure for obtain-

ing cloud requirements while also enriching the con-

text of use case diagrams, containing descriptions of

the deployment model and service delivery model,

which can then be utilized as input to an MDD tech-

nique to build a cloud architecture that is consis-

tent with the product owner’s decisions and com-

prehensibility of requirements for cloud service con-

sumers. The used MDD technique (the 4SRS method)

ensures that models of user requirements are trans-

formed into models of system requirements while al-

tering the relevant speciﬁcations. The adoption of

the SOA paradigm enables the managed system to

respond ﬂexibly to changes in the business process

through reconﬁguration and the addition of new func-

tionalities. It also organizes the various objects into

services, which can lead to differing perspectives on

the ﬁnal product. The logical architecture’s object

diagram thus ensures the speciﬁcation of the system

platform, which is based on a service-oriented plat-

form (SOA) and cloud computing.

ICSOFT 2022 - 17th International Conference on Software Technologies

408

6 CONCLUSIONS

In this paper, we use NIST Cloud Computing Ref-

erence Architecture in eliciting requirements by em-

ploying a new approach (the 2P2S technique), which

enables the use of an existing Model-Driven Design

method (the 4SRS method) to derive logic architec-

tures for cloud-based solutions.

The result is to deﬁne the requirements in such

a way that they are understood by the cloud service

consumers (the owner of the product ) because it un-

covers more information as if using only the use case

model of the application domain. The discussion of

the deployment model uncovers functional require-

ments for cloud management and helps distribute the

domain application functional requirements up to a

multi-cloud concept. Moreover, the service model

discussion uncovers more role actors for the provider

and the consumers and enriches use cases with more

descriptions that may lead to new design decisions or

non-functional requirements. The requirements elici-

tation involved a detailed analysis of the NIST CCRA,

where a set of key use cases that capture the func-

tional requirements of cloud services were presented.

The use of this reference architecture was useful in the

requirements elicitation phase, since it allows proper

functional reﬁnement of the domain application and

the cloud services, being a conceptual model that con-

stitutes an effective tool to discuss the requirements,

structure, and operation of the cloud. The 4SRS had

never been used for this particular context. However,

it has proved very useful since it formalized and ori-

ented the development of the architecture.

Some subjectivity may result from the application

of the 4SRS, so to minimize it, the model is iter-

ated and revised until a sufﬁcient model is obtained

to serve as the basis for the technical modeling of the

architecture, allowing a linkage between the semantic

component, the logical architecture and the cloud ar-

chitecture. The correct derivation of system require-

ments from user requirements is an important topic

in requirements engineering research, where our ap-

proach contributes to the adoption of emerging cloud

paradigms in this early requirements phase, assuring

that the system requirements are based on effective

client needs.

REFERENCES

Iankoulova, I., D. M. (2012). Cloud computing security

requirements: A systematic review. In 2012 Sixth In-

ternational Conference on Research Challenges in In-

formation Science (RCIS) (pp. 1–7). IEEE.

Klems, M., Nimis, J., and Tai, S. (2009). Do clouds com-

pute? a framework for estimating the value of cloud

computing. volume 22, pages 110–123.

Koitz, I. T., Seyff, N., and Glinz, M. (2013). How

cloud providers elicit consumer requirements: An ex-

ploratory study of nineteen companies. 2013 21st

IEEE International Requirements Engineering Con-

ference (RE), pages 105–114.

Liu, F., Tong, J.; Mao, J.; Bohn, R.; Messina, J.; Badger, M.;

Leaf, D. (2011). NIST Cloud Computing Reference

Architecture. NIST Special Publication 500-292.

Machado, R.-J., Fernandes, J., Monteiro, P., and Rodrigues,

H. (2005). Transformation of uml models for service-

oriented software architectures. In 12th IEEE Interna-

tional Conference and Workshops on the Engineering

of Computer-Based Systems (ECBS 05), pages 173–

182.

Pichan, A., Lazarescu, M., and Soh, S. T. (2015). Cloud

forensics: Technical challenges, solutions and com-

parative analysis. Digital Investigation, 13:38–57.

Reed, P. (2002). Reference architecture: The best of best

practices. The Rational Edge.

Reese, G. (2009). Cloud Application Architectures: Build-

ing Applications and Infrastructure in the Cloud. The-

ory in Practice (O’Reilly). O’Reilly Media.

Repschlaeger, J., Wind, S., Zarnekow, R., and Turowski, K.

(2012). A reference guide to cloud computing dimen-

sions: Infrastructure as a service classiﬁcation frame-

work. In 2012 45th Hawaii International Conference

on System Sciences, pages 2178–2188.

Rimal, B. P., J. A. K. D. G. Y. (2011). Architectural re-

quirements for cloud computing systems: An enter-

prise cloud approach. volume 9, pages 3–26.

Robertson, J. and Robertson, S. (2000). Volere require-

ments speciﬁcation template.

Schrodl, H. and Wind, S. (2011). Requirements engineer-

ing for cloud computing. Journal of Computer and

Communication, 8:707–715.

Souza, E., Moreira, A., and Goul

ao, M. (2019). Deriving ar-

chitectural models from requirements speciﬁcations: a

systematic mapping study. Information and Software

Technology, 109.

Zalazar A.S., Ballejos L., R. S. (2017). Analyzing Require-

ments Engineering for Cloud Computing. Ramachan-

dran M., Mahmood Z. (eds) Requirements Engineer-

ing for Service and Cloud Computing. Springer.

Zardari, S. and Bahsoon, R. (2011). Cloud adoption:

A goal-oriented requirements engineering approach.

Proceedings - International Conference on Software

Engineering.

Deriving UML Logic Architectures of Software Product based on a Cloud Reference Architecture: An Experience Report

409