On the importance of functions in data modeling

In this paper we argue that representing entity properties by tuple attributes, as evangelized in most set-oriented data models, is a controversial method conflicting with the principle of tuple immutability. As a principled solution to this problem of tuple immutability on one hand and the need to modify tuple attributes on the other hand, we propose to use mathematical functions for representing entity properties. In this approach, immutable tuples are intended for representing the existence of entities while mutable functions (mappings between sets) are used for representing entity properties. In this model, called the concept-oriented model (COM), functions are made first-class elements along with sets, and both functions and sets are used to represent and process data in a simpler and more natural way in comparison to purely set-oriented models.

Introduction
The main purpose of a data model is to provide a formal definition of what we mean by data at some level of abstraction, how we represent data and how we process data. In other words, if somebody asks what is data then a data model should give clear answers to these questions. Typically, a data model includes a definition of data elements (data representation), their organization by describing how they relate to each other (data structure) as well as how the elements and the relations are interpreted in terms of real-world entities (data semantics).
There exist many generic approaches to data modeling and numerous variations depending on how data elements are defined, how they are structured, how they are processed and how they are semantically interpreted. However, most of them assume that the minimum unit of data is a value as it is understood in computer science, that is, something unique, immutable and what can be passed only by copying its whole content (hence the term copying by-value).
Formally, values can be modelled by mathematical tuples which are interpreted as combinations of other values. This basic structure of tuple membership probably exists in all data models as well as other branches of computer science. The idea is that given two or more tuples, we can create a new tuple which combines them into one construct. Note again that such combinations are created by copying the member values and a tuple is a (structured) value.
Although tuples and tuple membership are at the core of most existing data models, they are not enough for a complete data model. The second basic structure widely used in data modeling is intended to describe collections of values. Such collections are formally represented by mathematical sets the members of which are tuples. Data manipulations in this case are reduced to adding tuples to a set or removing them from a set. Note that tuples (data values) are not sets and hence this model does not allow us to represent nested set membership. Theoretically, it is possible to assume that sets may include other sets as its members but for certain reasons this approach did not find wide acceptance.
Having tuples (structured values) and sets (collections of tuples) is already enough for creating a full featured data model. We refer to this large category of models as set-oriented models because they rely on manipulating tuples in sets. In particular, the relational model (RM) of data [2] belongs to this category but also less formalized approaches to data representation and processing like no-SQL databases or map-reduce assume that data is represented by collections of elements and processed by producing new collections from existing collections.
One important property of this generic set-oriented setting is the usage of tuple attributes for representing entity properties. The currently dominating assumption is that entity properties are mapped to tuple attributes, that is, tuples have as many attributes as the represented entity has properties. For example, if a product item is characterized by name and price then it is represented by a tuple with at least two attributes.
However, this assumption is quite controversial and essentially contradicts to some basic principles of set-orientation. The main issue with this assumption is that tuples are by definition immutable and hence it is impossible to modify entity properties without a conflict with set theory. The issue could be resolved by adding some stipulations, assumptions or additional mechanisms like primary keys but they will only hide the problem and not eliminate it. Essentially, such additional mechanisms as primary keys are a workaround which makes the model more complicated without the resolution of the problem at basic level.
In this paper, we describe a solution to this problem which is an alternative view on how data can be modelled at fundamental level. More specifically, instead of using tuple attributes, we propose to use mathematical functions to represent mutable entity properties. For example, if a product item is characterized by name and price, then we do not define tuple attributes for their representation. Instead, we define two functions: the first function maps product items to names and the second function maps product items to prices. Note that functions are fundamentally different from tuple attributes because they are mutable and support two basic operations: setting (assigning) a property value and getting (reading) a property value.
The goal of the paper is to show that functions are better for modeling (mutable) entity properties than tuple attributes. This solution makes data modeling simpler and more natural due to having much less semantic load on tuples and sets. In general, we assume that entity identifiers are not entity properties and hence they have to be modelled using different constructs: sets and functions, respectively. The usage of functions for data modeling is of course not new [4,10] but previously they have been used as an additional layer over sets and set operations, or for conceptual modeling. In these cases, the whole model still heavily relied on set theory, particularly, by expressing all data manipulations in terms of set operations. The model we describe, called the concept-oriented model (COM) [5], makes functions equal to sets by moving many mechanisms from sets to functions. In particular, tuples are not used for representing entity properties. Inference in COM relies not only on set operations but also on operations with functions (deriving new functions from existing functions). This changes the way data is processed and this approach was implemented in several systems such as Prosto 1 , Lambdo 2 , Bistro 3 for general purpose data processing and DataCommandr [6] and ConceptMix [8] for data wrangling.
In Section 2, we introduce some basic notions and describe how data is modeled in set-oriented models. In Section 3, we describe the problem of modeling entity properties using tuple attributes. Section 4 describes how the mechanism of primary keys is used to solve this problem. Section 5 introduces functions for data modeling and demonstrates how they can be used to solve the problem of modeling entity properties. Section 6 describes main properties of the concept-oriented model (COM) which relies on both sets and functions for data modeling. Section 8 provides concluding remarks.

Representing entity properties by tuple attributes
One of the main assumptions of set-oriented models including the relational model (RM) is that entities of the real world are formally represented by mathematical tuples. This means that if we want to represent a new entity then we create a tuple in some set. If we do not need to manage this entity anymore then this tuple is removed from the set. Adding and removing tuples from a set are basic operations of any set-oriented model, that is, all possible data manipulations are reduced to these two operations. Since tuples are (structured) values, this approach means that one entity is represented by one value. Now let us consider how the structure of entities is represented by elements of the model. Here we use a general informal observation that entities have properties which allow us to characterize an entity.
The question is then how entity properties are represented in a set-oriented model which provides only tuples in sets for data representation. The dominating pattern here is that entity properties are represented by tuple attributes, that is, entity structure is mapped to tuple attribute structure. For each new entity, we need to analyze its internal structure and then create one tuple attribute for each property which is supposed to contain the value characterizing this entity. Tuples and tuple attributes are viewed as a "natural way of representing properties of an entity" [1] also in other models frequently just because there are no other constructs except for sets, tuples and tuple attributes.
The principle of representing entities and their properties by tuples and their attributes, respectively, is at the core of set-oriented data modeling as well as many other approaches. For example, let us assume that a product is characterized by its name and price. In order to represent such an entity, we define two attributes: name attribute and price attribute (Fig. 1). We would need also some kind of identifying property which is also represented as a tuple attribute. In Section 5, we will describe an alternative approach where neither entity properties nor entity identifiers are tuple attributes.

Problem: Changing the unchangeable
In this section we show that the usage of tuples and tuple attributes for representing entities has one serious flaw. Assume that some property of an entity has changed and we want to update its representation to reflect this change. In our case, if properties are represented by tuple attributes, we need to accordingly modify the attribute corresponding to this changed property.
It seems that the problem does not exist because we can simply modify the corresponding attribute in the tuple. In particular, the relational model provides UPDATE operation for that purpose (in addition to INSERT and DELETE set operations) which allows us to change tuple attributes. Note that although RM recognizes and frequently explicitly stipulates that values cannot be updated, the mechanism at logical level works exactly as if attributes were mutable, and the existence of the UPDATE operation manifests such a possibility.
Although practically it is possible to modify tuples to reflect changes in entities, formally it is a workaround or even formal hack. Indeed, if we remember that tuples are by definition immutable then we get a conflict with one of the main assumptions. It is simply not allowed to modify tuples in any model which respects the principles of set theory. It is only possible to add a new (unique) tuple and remove an existing tuple -nothing else. Thus, strictly speaking, there is even no question how good the mechanism of using tuple attributes for representing entity properties is -all of them will have immutable entities (if they want to be referred to as set-oriented approaches). Such a model with immutable entities can hardly be useful and hence some solution is needed.
One simple workaround (accepted in RM) consists in removing a tuple and then adding a new modified tuple. For example (Fig. 2), if a product changes its price, then we need to delete the tuple <"My Product", 12.34> and add a new tuple <"My Product", 23.45, >. Note that this approach means removing a whole entity along with its identifier and all properties, and then adding a new entity with the same identifier and modified attributes.
Removing and adding a whole tuple instead of modifying individual attributes is a kind of a hack similar to justifying the use of non-unique tuples in sets. Another workaround is described in the next section.

Id
Entity properties are stored in tuple attributes Tuples represent entities and are stored in a set Name Price Products Fig. 2 Tuples are immutable and one way to modify them is to remove and add a new tuple

Workaround: Declaring immutable as mutable
An alternative wide spread solution to the problem of modifying tuple attributes representing entity properties consists in splitting a tuple into two parts by thus introducing two attribute roles. The first part of a tuple is supposed to be immutable because its main purpose is to identify the entity. The second part of the tuple consists of attributes representing entity properties which are supposed to be mutable. The idea is to somehow reflect the existence of two aspects: (i) entity existence and identification where we only create and delete tuples, and (ii) entity state described by its properties which can change. This approach became integral part of the relational model where "one domain (or combination of domains) of a given relation has values which uniquely identify each element (n-tuple) of that relation and … is called a primary key" [2].
For example, a product item can be represented as a tuple with product id as the only PK attribute while name and price will be non-PK attributes (Fig. 3). If we need to add or remove an entity then we create or delete a whole tuple, respectively. If we need to modify the entity properties, then we update its non-PK attributes (name or price in this example) while PK attributes retain the connection with the entity these properties belong to.

Fig. 3 A tuple has attributes with two roles: mutable and immutable
Although this approach is widely used in practice, it has some quite serious problems. Essentially, it retains the original problem but wraps it into a different (conceptual) context and formulations. This original problem -inability to change tuple attributes with the purpose to reflect changing entity properties -now is expressed in different terms.
Probably the best way to formulate this problem is to ask what is a true mathematical tuple in this approach -a whole tuple or only its PK part? Indeed, we introduced two sorts of attributes and hence the question is completely correct. There are at least two possible answers. First, we can assume that a whole tuple with all the original attributes is viewed as a true mathematical tuple, which is a member of the set. Obviously, this assumption does not work because we are not able to modify attributes of true tuples while our non-PK attributes are supposed to be mutable. Second, we can assume that only PK attributes constitute a true mathematical tuple. It is a valid assumption because this part is assumed to be immutable. Yet, now we need to answer the question what are the non-PK attributes? Indeed, if only tuples with PK attributes are members of the set then non-PK part has no (mathematical) status. Non-PK attributes do not have any formal definition and are viewed as some kind of useful Products PK attributesimmutable non-PK attributesmutable "attachments". Having such a payload in non-PK attributes is very convenient and is actually works very well in practice at least at conceptual level. However, without a clear answer to the question about the formal treatment of non-PK attributes, we lose support of set theory.
Since it is not clear how to interpret the separation on PK and non-PK attributes, we view this mechanism as a workaround or additional conceptual level of description. This trick allows us to switch between practical usefulness and formal correctness by changing our treatment of these parts on the fly depending on what we need. If we need formal mathematical correctness then we say that the whole tuple is a member of the set. If we need practical usefulness then we say that only PK part is a tuple and non-PK part contains mutable properties. All the necessary mathematical formalities are satisfied at the level of full tuples with all the attributes and the PK and non-PK roles is some kind of higher level semantic abstraction. This of course does not solve the problem because it does not change the nature of tuples as immutable values but can be accepted as a justification for many practical use cases and implementations.
A principled solution to this problem which does not conflict with set theory is described in the next section.

Solution: Representing entity properties by functions
In fact, the semantics of PK attributes correctly reflects one aspect: life cycle of entities and manifestation of the entity existence by supporting only add and remove operations. What is inacceptable in PK-based models is the usage of non-PK attributes: on one hand, they are still tuple attributes and hence are immutable but on the other hand, they are declared mutable. These two requirements are not compatible -we cannot combine mutability with the representation by tuples.
The central idea of our approach is that we completely abandon the usage of tuple attributes, in particular, non-PK attributes, for representing entity (mutable) properties. Instead of artificially attaching non-PK attributes to the true mathematical tuple (or using any other role of attributes), we use mathematical functions as an additional construct of the model. A function is interpreted in their original mathematical sense as a mapping from one set to another set: : → is said to be a function from set X to set Y, if and only if f is an operation that assigns to each element ∈ , a single element = ( ) ∈ . Functions are then used to represent mutable properties of entities. The main benefit is that functions provide a principled solution to the problem formulated in Section 3 and also significantly simplify the whole model. Now we have only tuples as they are defined in set theory for representing the existence of entities and functions for representing their properties, which can be modified without influencing their existence (and the corresponding tuples).
In our example, product items are represented by tuples with one attribute storing item id (Fig. 4). These tuples are added if a new product item is created and removed if an item is deleted. In terms of RM, relations contain only PKs the attributes of which cannot be modified. In order to represent properties of product items, two functions are created. The first function maps product items to names and the second function maps product items to prices. The main difference of functions in the context of data modeling is that they are supposed to be modified. In contrast to sets which support two basic operations of addition and removal of elements, functions support two other elementary operations: assigning a value (setting or writing a value) and reading a value (getting the current function output).
Another crucial difference from the purely set-oriented approach is that no tuple attributes (and hence whole tuples) can be modified without any exceptions. If an entity property changes then the corresponding function changes its current output value to some other value. Consequently, the whole database state consists of two parts: (i) the state of sets defined by their elements and (ii) the state of functions defined by their mappings. Here is how the usage of functions changes data modeling: • A set is defined for each entity type and tuples are used to identify entities by representing the fact of their existence. Sets of the model are modified only if new entities are created or deleted. In terms of the relational model, a set should contain tuples with the structure of traditional PKs excluding all other attributes. • Entity properties are not represented by tuple attributes -for each entity property a function is defined. If an entity changes its state then some function of this entity is modified. In terms of the relational model, a function should be defined for each FK.
Thus, by means of functions we can solve our problem of modifying immutable tuple attributes. In the next section, we discuss some properties of this model which relies on both sets and functions rather than on only sets.

Concept-oriented model: both sets and functions for data modeling
The concept-oriented model [5] is a pair 〈 , 〉 where S is a collection of sets { 1 , 2 , … } and F is a collection of functions { 1 , 2 , … }, : → , , ∈ . This definition is similar to the category of sets from category theory (a category whose objects are sets and morphisms are functions) which could be therefore used as the underlying formalism similar to relational algebra and set theory for the relational model. For comparison, the relational model (its representational part) consists of only sets (relations and domains).
It is a generic definition of COM and depending on additional constraints imposed on the structure of sets and functions we can get more specific models. For example, we could impose constraints on the sets by requiring that they have certain tuple structure (defined by a finite set of attribute types) instead of having the sets storing arbitrary values. We also might work with only one set, the universe of discourse, while functions (all typed by this universal set) will define mappings on this set. In some sense, this model could be thought of as the opposite one to the relational model which works only with sets.
A data schema is a model with no set elements and no function elements. In a schema, we specify only sets we are going to use (without members) and function signatures as pairs of their input and output sets. A schema is intended for defining structure all (future) elements must satisfy. Given a schema, the elements of the model define its (current) data state. By adding or removing set elements as well as changing the mappings defined by functions, we can change the current data state of the model. Note that we also can infer new sets and new functions from the model. The main operations for inference are relation composition and function composition.
Below we shortly describe some aspects of this model which help to understand and distinguish it from the conventional set-oriented models relying on only sets.
Functions store data state. The database state in COM is determined by both sets and functions rather than only sets. In particular, two databases may have identical sets but different functions. By modifying a mapping between some sets we will get a new state of the database. In this sense, a function is viewed as storage at all levels of organization: conceptual, logical and physical. We can manipulate this (functional) storage by creating and deleting functions as well as modifying the function state, that is, its mapping from inputs to outputs. Note that conventional column stores (column-oriented databases) rely on the physical representation of tables by a number of columns which is very useful for many workloads but does not change the logical and conceptual levels.

Function is not a binary relation.
A typical argument against independent use and equal role of functions in data modeling is that a function can be formally represented as a binary relation, that is, a set of input-output pairs. In this case, we eliminate the need in functions as a separate notion and hence, presumably, simplify the model because everything including functions can be expressed using sets and set operations. The main problem of this approach is that when representing functions as binary relations we lose the most important aspect (at least for data modeling): the semantics of functions. Indeed, a binary relation by itself does not represent the semantics of mapping one set to another -it is simply a relation. If we still want to have this semantics, that is, the knowledge that the first attribute represents inputs and the second attribute represents outputs, then we again need to introduce additional levels, mechanisms and constraints. Even such simple thing like the constraint that one input may have maximum one output value assigned requires additional mechanisms which make the model more complicated. The situation is actually worse because the whole point of having functions in a data model is that the semantics of mapping is different from the semantics of containment and our goal is to have both of them equally supported. We introduce functions because we postulate that data has two primary aspects: how entities exist and how entities are characterized. The existence is described by sets and tuples. The characterization is described by functions.
Removing functions from the model leads to the need in additional mechanisms and level of representation (essentially compensating the absence of functions) like various key types, controversies in typing, difficulties in defining objects, controversies in treating nulls, having no assignment operation and do notion, normalization theory with numerous normal forms etc. Many or maybe all of these problems are consequences of having no functions in the data model.
Basic semantic relationship. In any data model, one of the main questions is how data elements are related to each other. In RM, two or more values in some sets are related if there is a tuple which stores these values in its attributes. This relationship is symmetric (all related values have equal status) and has arbitrary arity (we can relate n elements). In COM, two values are related if there is a function which maps one of them to the other. This basic relationship is directed and it relates only two values.
Separating identification and characterization. Having both sets and functions in a data model reflects two important aspects: 1) existence and identification of entities modeled by tuples and sets with the semantics of containment and add-remove basic operations, and 2) characterization of entities via other entities including primitive values modeled by functions with the semantics of mapping and setget basic operations. In a purely set-oriented model, it is quite difficult to cleanly separate these two concerns and it is necessary to introduce additional mechanisms and levels which eventually do what functions can do much simpler and more natural.
Keys and normalization. Various kinds of keys and numerous normal forms are an integral part of the relational model and probably any set-oriented approach just because using only sets is not enoughsomething very important will be missing without these mechanisms. On the other hand, ambiguity and controversy of these mechanisms and levels of modeling make the model more complex and difficult to apply. Indeed, there are numerous disputes about the need and usefulness of various kinds of keys and about the usefulness of different normal forms. Introducing functions as one of two primary (semantic, logical and physical) constructs of the model essentially eliminates the need in these mechanisms because now sets have only one purpose: identifying entities and representing what exists. Primary and candidate keys (as an attribute role) are not needed just because any tuple in a set is by definition an identifier of the corresponding entity. Foreign keys are also not needed because functions replace this mechanism by providing many additional benefits like typing, assignment and dot notion. Normalization theory loses its importance as a means of controlling and eliminating redundancy because the problem of redundancy is caused by the need to put data with different roles (identification and characterization) in attributes of one tuple while COM explicitly separates these two roles by putting data in two different constructs: sets and functions. Note that this does not mean that functions somehow magically solve all the problems related to the mechanisms of keys, normalization and functional dependencies (as they are understood in the relational model). Functions allow us to look at these problems from a completely different direction by re-formulating them and finding simpler solutions or even making them obsolete.
Querying by means of functions. The introduction of functions as a first-class element of the model is not simply a formal mathematical convenience resolving the issue with immutable tuples. Since functions store data state (along with sets), we can query and process data using functions. In other words, we can infer new data implicitly represented in the database by deriving new functions from existing (maybe also derived) functions. Functions have not only their own representational semantics as mappings -they also have their own operational semantics which relies on the function composition operation. Just as the semantics of mapping is opposed to the semantics of containment, the function composition operation is opposed to the relation composition operation (join). The whole general approach to querying and data processing changes: instead of or in addition to inferring new sets in terms of existing sets, we define or infer new functions in terms of existing functions. Some examples where the set-oriented approach is conceptually inadequate and the function-oriented approach solves the problems in a simple and natural way are described in [5], Section 1.1.
Assignment and dot notion. The relational model and other set-oriented models have always had difficulties in dealing with assignments just because such an operation does not exist in set theory. Accordingly, dot notion for reading and writing values is also not supported at the same level as set operations. This status contrasts with extremely wide use and semantic clarity of these operations. It is simply difficult to imagine how data can be processed and even thought of without these basic operations. By introducing functions in the model, the status of these operation is accordingly increased and made equal to that of set operations. In general, whenever we think about reading and writing data values, we need to apply functions and operations with functions, and whenever we think about adding and removing data, we need to apply sets and operations with sets.
Types. In the relational model, type is defined as "a named, finite set of values" [3]. Yet, "the relational model and type theory are almost completely independent of each other" and type system "complements the relational model" [3]. Essentially, we are able to use the relational model even without strong support of types because types are not inherent part of relational algebra. In particular, relations are not treated as types and cannot be used as types which is strange because relations are sets of values. In contrast, COM treats types as integral part of the model because any set is a type and any function and attribute must specify its type as some set from this model.
Objects. In the relational model, "the very term object itself does not seem to have a precise or universally agreed meaning" [3] which leads to the problem frequently referred to as the objectrelational impedance mismatch and the existence of many alternative solutions trying to integrate these concepts. Functions allow us to provide a new definition of an object: an object is a couple of one tuple treated as a reference and a number of function outputs for this reference [5]. Note that an object is not a tuple -only its reference is a tuple. Also, object fields are not a tuple because they exist as values in different sets. In this sense, COM provides another view on this problem especially taking into account ideas (including new mechanism of inheritance) developed in concept-oriented programming [7].
Other functional models. Most existing functional models [4,9,10] are conceptual models which are closer to the entity-relationship model or they heavily rely on the relational model by translating their constructs and operations to those of relational algebra. In contrast, COM significantly strengthens the role of functions by making them first-class constructs of the model at the same level as sets. In particular, functions are used to represent data state as well as to infer new data. The usage of join is limited by producing a multidimensional space (product) and much less or not at all for relating data values -functions are now used for that purpose. Another important difference is that traditional functional models are typically treated as graph models where sets representing entities are nodes and functions are edges. COM interprets functions (and in general any references) as "member of" or "IS-IN" relation by making it closer to multidimensional models where a set is a multidimensional space with axes defined by its function ranges.

Conclusion
One of the main postulates behind set-oriented models including the relational model is that data is represented by tuples in sets. This means that all other mechanisms and data interpretations must be expressed in terms of tuples, attributes and sets. In this paper, we described one flaw of this category of models which is a consequence of the immutability of mathematical tuples. The problem is that if tuples are immutable (and they must be immutable if we want to apply set theory), and we assume that entity properties are represented by tuple attributes, then we are not able to modify entity properties in the model without conflict with set theory. In practice, this issue is simply ignored by permitting tuple attribute modifications, that is, if we need to change an attribute then the system just does it. In theory, some theoretical justifications are introduced like remove-add instead of update or assigning special roles to attributes which "legalize" their modification by essentially defining a new layer of the model obeying to different theoretical rules.
In the paper we argued that these workarounds result in a more complicated model with inconsistent theoretical basis and various semantic controversies. The main cause of the problem is the desire to fit both (immutable) entity identifiers and (mutable) entity properties into one construct -tuple. As a principled solution to this problem, we propose to use mathematical functions as first-class elements of the model at the same level as sets. In this model, data is stored not only in sets but also in functions. Moreover, data processing is performed not only by deriving new sets but also by inferring new functions. Such a model based on both sets and functions is much simpler and more natural because it significantly reduces operational and semantic load on sets by producing a nice balance between two aspects: entity existence with add and remove operations modeled by tuples in sets, and entity state with set and get operations modeled by functions. The usefulness of this model was also demonstrated in several open source systems for function-oriented data processing.


Cloud Computing and Distance Learning in Computer Science

This work demonstrates that the use of laboratories for the development of curricular work in the area of information technology exclusively supported by cloud computing technology does not decrease the level of learning and assessment objects on the part of students. This scenario arose from the need to interrupt faceto-face classes in physical laboratories due to the COVID-19 Pandemic. K e y w o r d s: Cloud Computing, Azure, distance learning, WEB App, Virtual Labs, DevOps.

The Context
In everyday language Cloud Computing (CC) is a set of computational resources made available to a group of users, remotely, taking the form of services. And like any service today, electricity, water, gas, etc., they are always available for both individual and business use. This is possible because throughout the second half of the 20th century, the technical industry adopted a set of standard models from different sources and technological platforms. CN works as a universal, paid service, but is always available to users/customers who need it, in the same way that they have the electricity service. The main principle that supports this technology and this model is the provision of computing, storage and software as a service. Cloud is a distributed and parallel computing system, consisting of a collection of virtualized and interconnected computers that are presented as a set of dynamic and unified resources, based on Service Level Agreement (SLA) established between the service provider and the end customer. With the crisis caused by the pandemic of COVID-19, almost all universities had to change the model of classroom classes to a model of distance classes. The paradigm is radically different. In certain scientific and technical areas, the transition was more straightforward. However, in the case of laboratory classes the process became more complicated or even impossible. In the specific case of computer network laboratories which were based on computers and servers installed at universities' on-premise infrastructures, the process was almost impossible and these laboratory classes had to be postponed, or complex processes had to be created so that students could go to the labs. This work intends to develop a demonstration of a model that can allow to simulate the teaching of the development and operation of computer networks through a laboratory created by the teacher in a Cloud Computing system -in this case, in Azure.
The main objective of this work is to verify if the use of cloud computing laboratories (in this case in Azure) for curriculum development in substitution of physical laboratories on university campuses, due to the mandatory interruption of classroom classes in the context of COVID-19, had an impact on learning and what is the effect on school success, namely on assessments. The second objective of this work is to compare if the school objectives and the evaluation between two different curricular units obtained the same performance standard or, in case of divergences, this second objective helps to validate whether the method used based on laboratories in cloud computing is successful or not. This study is contextualized in the area of information technology and, specifically, in the area of a master's degree in computer science.
Main objectives may be encapsulated as follows: • to compare the evaluation made in the pre-Covid-19 period and the evaluation during the first phase of Covid-19; • to analyze whether the use of online laboratories had a negative impact on the evaluation. At the beginning and during the first phase of the Covid-19 pandemic, more than 90% of teachers were not familiar with distance learning. In a record period of two months, they had to adapt to a new paradigm. The adaptation was made essentially with self-study by the teachers. In the case of students there was an identical situation, they were also not familiar with distance learning. They had always taken classes exclusively face-to-face.

History of Cloud Computing
The concept of CC arises from another idea that was called time-sharing, and which implied sharing, by several entities at different times, the same computing equipment. However, today, there are substantial differences between the concept of computational time-sharing and CC. At the time of computational time-sharing, the services or machines that held them could only be used by one operator at a time, that is, they were divided according to portions of time and not portions of accommodation space; today the question of time-sharing does not exist, it pays according to the service that is obtained or the space that the information occupies, but not according to the time that this resource is being used. But the basic idea is very similar -it is to provide a computing service remotely and not locally. Using daily and straightforward concepts by analogy, we can say that both the computational time-sharing system and the DC system can be seen as a service that is made available in the same way as electricity or water, that is, they are available when we need them, we pay for that availability and its use. For example, if we use Office 365 we pay for its use as when we consume electricity, but we can also pay for the accommodation of the documents produced by it, as we pay if we want to have a storage system for reserve energy. Initially, in the sixties of the 20th century, computer systems were in large rooms with powerful and expensive cooling systems and a high consumption of electricity. Besides, they could only be used locally. The next step was to change this situation through a system that would allow remote access to a central computer; it is from here that we can talk about time-sharing.
Organizations could buy time to use a computer system, without having to have it in their facilities, and without having to worry about its maintenance and administration. Microcomputers started to appear when the concept of time-sharing was already popular. Microcomputers were smaller than mainframes and were significantly cheaper. Microcomputers quickly became more sophisticated than the old mainframes, but more importantly, microcomputers had multitasking capabilities, allowing for time-sharing. The concept of time-sharing and microcomputers quickly led to the creation of a new idea, that of distributed systems.

Fundamentals of Cloud Computing Definitions
The term cloud computing (CC) has become somewhat of a sensational term, almost everyone in the industry has its definition of CN, in this paper we adopted the definition of CC assumed by the National Institute of Technology and Standards (NIST, 2020): Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics (On-demand self-service, Broad network access, Resource pooling, Rapid elasticity, Measured Service); three service models (Cloud Software as a Service (SaaS), Cloud Platform as a Service (PaaS), Cloud Infrastructure as a Service (IaaS)); and, four deployment models (Private cloud, Community cloud, Public cloud, Hybrid cloud). Key enabling technologies include fast wide-area networks, powerful, inexpensive server computers, and high-performance virtualization for commodity hardware. The Cloud Computing model offers the promise of massive cost savings combined with increased IT agility. It is considered critical that government and industry begin adoption of this technology in response to difficult economic constraints. However, cloud computing technology challenges many traditional approaches to datacenter and enterprise application design and management. Cloud computing is currently being used; however, security, interoperability, and portability are cited as major barriers to broader adoption. The long-term goal is to provide thought leadership and guidance around the cloud computing paradigm to catalyze its use within industry and government. NIST aims to shorten the adoption cycle, which will enable near-term cost savings and increased ability to quickly create and deploy enterprise applications. NIST aims to foster cloud computing systems and practices that support interoperability, portability, and security requirements that are appropriate and achievable for important usage scenarios. (Mell, 2011) In everyday language, Cloud Computing (CC) is a set of computational resources made remotely available to a group of users, taking the form of services. And like any service today, electricity, water, gas, etc., are always available for both individual and business use. This is possible since throughout the second half of the 20th century, the technological industry adopted a set of standard models from different sources and technical platforms. CC works as a universal, paid service, but always available to users/customers who need it, in the same way that they have the electricity service. However, CC is a term that has many meanings, but an effort has been made in the last ten years to establish common denominators in these meanings, to create a more objective definition. This effort has mainly been made through the publications of the Information Technology Infrastructure Library (ITIL), which is a library of good practices to be applied in infrastructures, operations and maintenance of information technology services, having been developed by the Central Computer and Telecommunications Agency (CCTA), today under the Office for Government Commerce (OGC) in England. In the most generic form, and following the ITIL concept, a service is a relationship between a consumer and a provider, in which the provider makes available and delivers to the consumer a value (service) and the consumer avoids the risks and investments in providing it with this value (service) itself, currently the CC is also inserted in this context. For example, the simple storage and database management services of a retail store on the Web, if they are using the CC, are always available to the store owner, as well as to his customers, without the said owner having to worry about maintaining those services, and don't have to bear the investment risks of purchasing a complex platform. If the business does not go well, it merely cancels the services, having had no losses associated with the investment of fixed technological assets (CSIAC, 2020).

Main characteristics of cloud computing technology
• On-demand self-service services: a consumer can unilaterally provision computing resources, such as server time and storage network, as needed automatically, without requiring human interaction with each service provider. • Broad network access: resources are available on the network and accessed through standard mechanisms that promote use by thin or thick heterogeneous client platforms (e.g. cell phones, tablets, laptops, and workstations). • Pooled resources: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to the consumer's requirements. There is a sense of location independence, as the customer generally has no control or knowledge about the exact location of the resources provided, but may be able to specify the location at a higher level of abstraction (for example, country, state or data-center). Examples of resources include storage, processing, memory and network bandwidth (Soundarjan, 2015). • Rapid elasticity: resources can be provisioned elastically and made available, in some cases automatically, to scale out and in quickly, according to the needs. To the consumer, the resources available for provisioning generally appear to be unlimited and can be appropriated in any quantity and at any time.
• Services with metrics, cloud systems automatically control and optimize the use of resources, leveraging a metering resource at levels of abstraction appropriate to the types of services (for example, storage, processing, bandwidth and active user accounts). The use of resources can be monitored, controlled and reported, providing transparency to the provider and the consumer of the services used (Brandao, 2019).

Service Model
Currently, cloud computing technology has three service models ( Figure 1): • Infrastructure as a Service (IaaS): the user can implement and execute software arbitrarily, which can include operating systems and applications. The user does not administer or control the underlying cloud infrastructure, but has control over operating systems, storage, deployed applications and limited control over some network components, for example, host firewalls. The services offered by this delivery model include: hosting servers, Web servers, storage, computing hardware, operating systems, virtual instances, load balancing, Internet access and bandwidth provisioning. • Platform as a Service (PaaS) allows a cloud user to implement a product created or purchased by the consumer as applications using programming languages and tools supported by the service provider. The user has control over the implemented applications and, possibly, the settings of the hosting environment. He/ she does not administer or control the underlying cloud infrastructure, including network, servers, operating systems or storage. This model is not particularly useful when: the application must be portable; proprietary programming languages are used; hardware and software must be customized to improve application performance (Carlyle, 2016). • The service provider provides software as a service only. The user does not administer or control the underlying cloud infrastructure or the resources of individual applications. Services offered include business services, such as workflow management, groupware and collaboration, supply chain, communications, digital signature, customer relationship management (CRM), desktop software, financial, geospatial and research management. Web 2.0 applications, such as: metadata management, social networks, blogs, Wiki services and portal services. It is not suitable for real-time applications or for those where data cannot be hosted externally. Examples: Office 365, Salesforce.com, Gmail (Voorsluys, 2011).

Implementation Models
There are four models for implementing cloud computing technology: • Private Cloud: the cloud infrastructure is provisioned for exclusive use by a single organization, composed of several consumers (for example, business units). It can be owned, managed and operated by the organization, third parties or a combination of them, and it can exist on or off the premises (Armbust, 2009). • Community Cloud: the cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that share concerns (for example, mission, security requirements, policy and compliance considerations). It can be owned, managed and operated by one or more community organizations, by third parties or a combination of them, and it can exist on or off the premises (Page, 2012). • Public cloud: the cloud infrastructure is provisioned for open use by the general public. It may be owned, administered and operated by a company, academic or governmental organization, or some combination thereof. It exists on the premises of the cloud provider. • Hybrid Cloud: the cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community or public) that remain unique entities, but are united by standardized or proprietary technology that allows the portability of data and applications (for example, cloud augmentation for load balancing between clouds).

DevOps
Azure DevOps consists of a mixture of development (Dev) and operations (Ops) -DevOps is the union of people, processes and technology to deliver applications quickly and safely. DevOps gives way to functions that previously worked in silos -development, IT operations, quality engineering and security coordinate and collaborate to produce better and more reliable products. By adopting a culture of DevOps and DevOps practices and tools, teams gain the ability to better respond to development needs and increase confidence in the applications they create as well as achieve their goals faster. The students who used DevOps did so in the context of a curricular unit for developing applications for mobile devices. The methodology followed in curriculum development and application development was as follows: 1. Plan. In the planning phase, the DevOps teams devise, define and describe the features and capabilities of the applications and systems they are going to create. They track progress through high and low levels of granularity, from tasks for individual products to cross-cutting tasks for multiple products. Some of the ways in which DevOps teams plan with agility and visibility include creating to-do records, monitoring errors, managing agile software development with Scrum, using Kanban boards and viewing progress with dashboards. 2. Develop. The development phase includes all aspects of programming -writing, testing, revising and integrating the code by the team members -as well as compiling that code into compilation artefacts which can be implemented in various environments. DevOps teams seek to innovate quickly without sacrificing quality, stability and productivity. To do this, they use highly productive tools, automate mundane and manual steps and iterate in small increments through automatic testing and continuous integration. 3. Distribute. The delivery consisted of the process of implementing applications in production environments consistently and reliably. The delivery phase also includes implementing and configuring the entirely governed base infrastructure that makes up these environments. At this stage, the teams define a launch management process with exact manual approval steps. They also define automatic limits that move applications between phases until they are made available to customers. The automation of these processes makes them scalable, repeatable and controlled. Thus, teams that follow DevOps can frequently deliver with ease, confidence and tranquility. 4. Operate. The operation phase involves the maintenance, monitoring and troubleshooting of applications in production environments. Teams, when adopting DevOps practices, work to ensure the reliability of systems and high availability and aim for no downtime, while reinforcing security and governance. DevOps teams seek to identify problems before they affect the customer experience and mitigate them quickly before they occur. Maintaining this surveillance requires advanced telemetry, actionable alerts and full visibility to applications and the underlying system.

The research methods
The main techniques and tools used for gathering research data include the following quantitative methods: • Observation. This involved counting the number of times that a specific event occurred or encoding observational data to translate them into numbers. In this case, the difficulties in completing the laboratories were requested for the evaluation. • Screening of assessment documents -obtaining numerical data from the evaluation forms and counting of unrealized events that were considered mandatory objectives for evaluation. • Comparative experimentation -testing hypotheses in laboratories, testing cause and effect relationships, through experience in the development of network laboratories, comparing the results in terms of performance between laboratories developed in person before the COVID-19 crisis and the performance in the development of network labs in a 100% cloud computing environment. • Hypotheses. One of the leading hypotheses presented is that the transition from a classroom model to a fully online class model does not affect the students' performance and learning level, nor does it provide a lower level of evaluative success in the area of information technology information. As a second hypothesis, it is expected that precisely in the area of information technology, the results will be even more positive in the case of curriculum development done in online laboratories, in particular via cloud computing.

Laboratory to teach how to create a WEB App
The plan for creating a WEB App follows the exact indications advised by Microsoft in its teaching plan for the development of these solutions in Azure (Microsoft, 2020).
If you want to build a website for a new business, or you are running an existing web app on an old on-premises server, you can do it in 15 minutes. Setting up a new server can be challenging. You need appropriate hardware, likely a server-level operating system, and a web hosting stack. Hosting your web application using Azure App Service makes deploying and managing a web app much easier when compared to managing a physical server. In this module, we will implement and deploy a web app to App Service.
Learning objectives: • use the Azure portal to create an Azure App Service web app; • use developer tools to create the code for a starter web application; • deploy your code to App Service. Using the Azure portal, you can easily add deployment slots to an App Service web app. For instance, you can create a staging deployment slot where you can push your code to test on Azure. Once you are happy with your code, you can easily swap the staging deployment slot with the production slot. You do all this with a few simple mouse clicks in the Azure portal. When you are ready to run a web app on Azure, you visit the Azure portal and create a Web App resource. Creating a web app allocates a set of hosting resources in App Service, which you can use to host any web-based application that is supported by Azure, whether it be ASP.NET Core, Node.js, Java, Python, etc.
If you are deploying your app as code, many of the available runtime stacks are limited to one operating system or the other. After choosing a runtime stack, the toggle will indicate whether you have a choice of operating system. If your target runtime stack is available on both operating systems, select the one that you use to develop and test your application. If your application is packaged as a Docker image, choose the operating system on which your image is designed to run. Selecting Windows activates the Monitoring tab, where you have the option to enable Application Insights. Enabling this feature will configure your app to automatically send detailed performance telemetry to the Application Insights monitoring service without requiring any changes to your code. Application Insights can be used from Linux-hosted apps as well, but this turnkey, no-code option is only available on Windows. An App Service plan is a set of virtual server resources that run App Service apps.
A plan's size (sometimes referred to as its Sku or pricing tier) determines the performance characteristics of the virtual servers that run the apps assigned to the plan and the App Service features that those apps have access to. Every App Service web app you create must be set to a single App Service plan that runs it.
A single App Service plan can host multiple App Service web apps. In most cases, the number of apps you can run on a single plan will be limited by the performance characteristics of the apps and the resource limitations of the plan. App Service plans are the unit of billing for App Service. The size of each App Service plan in your subscription, in addition to the bandwidth resources used by the apps deployed to those plans, determines the price that you pay. The number of web apps deployed to your App Service plans does not affect your bill.
You can use any of the available Azure management tools to create an App Service plan. When you create a web app via the Azure portal, the wizard will help you to create a new plan at the same time if you do not already have one. The Azure Portal provides a wizard to create the solution with the following options: subscription, resource group, App name, publish, runtime stack, operating system, region and App service plan.
To create the WEB App, the steps below must be followed (Figure 2): On the Azure portal menu or from the Home page, select Create a resource. Everything you create on Azure is a resource. The portal navigates you to the Marketplace page. From here, you can search for the resource you want to create or select one of the popular resources that people create in the Azure portal. Select Web > Web App to display the web app creation wizard. Fill out the wizard with the following values: Subscription (Concierge), Resource Group (Sandbox resource group), Name (enter a unique name), Publish (Code), Runtime stack (.NET Core 3.1 -LTS), Operating System (Linux), Region (chose the close to you), SKU and Size (F1). Then select Review and Create.

The Analysis
The investigation focused on the analysis of the results of school progress, including the final assessment of 21 students in a master's degree course in Information Technology.
We present two hypotheses to verify: first, whether or not there was a decrease in school results in the period of confinement caused by the Pandemic of COVID-19; second, check if there is any correlation between the evolution of the evaluation results between different curricular units, in the referred period. Both hypotheses considered referring to contexts of curriculum development through Cloud Computing systems.
The participants were the students of the first year of the master's degree. Both classes needed to use the same laboratories for curriculum development work.
One of the curricular units, Digital Systems Architecture, was run from the first semester, that is, from a pre-COVID-19 period. In this period the laboratory work was performed in person, that is in the laboratories of the university. The other curricular unit was Private Cloud Computing, already developed in the period of COVID-19, without face-to-face classes. It is important to consider that our university closed all face-to-face classes at the beginning of March -unlike many other countries, Portugal was one of the first countries to close schools and universities. The law of university autonomy in Portugal allows university directors to establish autonomous contingency plans, this is what happened at our institution.
In the confinement phase, students only took online classes, Google Classroom taught asynchronous classes, synchronous classes by Google Meet. In the case of this master's degree in computer science, the part of technological laboratories migrated entirely to Microsoft Azure. The laboratories developed by this class were all implemented in the area of computational infrastructure.
Analysing the evolution of the curricular unit of the first semester, Digital Systems Architecture, it was found that the average of the evaluations obtained was 16 values (on a scale from 0 to 20), it was also found that the standard deviation was 2.718 ( Figure 3 ).
Laboratory work in the first semester was only completed in the last week of that semester. Not all students were able to finish the laboratories on time, mainly because they were working students and did not have the necessary time to dedicate to the face-to-face laboratories, as well as the fact that they had to miss classes for different reasons. The teacher had to extend classes for over a week for everyone to finish their work.
On the other hand, the Private Cloud Computing Course Unit, was taught in the confinement period of COVID-19, all took place through distance learning, that The results obtained from the analysis to the evaluation and performance of the students were genuinely superior to what happened in the first semester, curricular unit.
The average of the final evaluation was 18 values, and the standard deviation was 1.590 ( Figure 4). This is a significantly higher average -the fact that the general population and students were experiencing a period of enormous emotional stress, which did not occur in the first semester should be considered here) -yet in spite of this, they obtained higher ratings. Another aspect to note are the differences in standard deviation between the two scenarios. The standard deviation of the second-semester assessment is lower, which indicates that the general consolidation of objectives and learning, in addition to being more elevated, is more consistent and more students improved their performance.
The average difference between the results of the assessment obtained before confinement and the results obtained during the confinement period for similar curricular units (represented in Figures 3 and 4) is two values; in the confinement period, the students on average obtained a superior evaluation in two values, on an evaluative scale of zero to twenty values. It was also found that all students finished laboratory work before the deadlines with fewer doubts about the contents to be developed. This is not a quantitative aspect, but I consider it relevant. It is the opinion expressed by all students that the fact that the laboratories are in cloud computing allowed them to work at any time and repeat the tests and learning in a more straightforward way. They were able to review all the work easily. In technical terms, these labs also allowed students to reset any development errors as they were using virtual machines which, due to their characteristics, allow easy to create reverse images.

Advantages of Cloud-based E-Learning
We believe that there are many advantages in laboratory teaching based on Cloud Computing for some technical-scientific regions of Computer Sciences (Riahi, 2015), we also recognize that this model does not adapt so well to other areas.
However, some advantages of Cloud-based E-Learning should be summarized: 1. Low cost; e-learning computer users need not configure up for e-learning applications. They can cloud applications via PC, mobile phone, tablet with an Internet connection to run with minimal configuration (Maskarade, 2014). 2. Improved performance; since cloud-based applications for e-learning run with super-strength, super-source software is automatically updated. So, students always received updates (Viswanath, 2012). 3. Direct benefits for students; they can take online courses, take the exam online, received feedback about the coaches, and post projects and assignments online through their teachers (Patel, 2014). 4. Cybersecurity; cloud computing providers supply some major security benefits for individuals and companies that are using e-learning solutions (Mohammed, 2014). All the information is more secure. We carried out the same type of study for two other curricular units in an area other than that of the Azure infrastructure. In this case, we compared two curricular units for the development of applications for mobile devices, one taught in the pre-COVID-19 period, the other taught at the peak of the COVID-19 pandemic in which students only had classes through online technologies, and in this case through Azure DevOps.
In the curricular unit Web and Multimedia Programming, taught before the COVID-19 period, always in face-to-face classes in the classroom and with the use of development software existing on students' computers or in the classroom, the results were average ( Figure 5). On the other hand, in the curricular unit Development for Android Platforms, taught during the COVID-19 period, always in online classes, and still using the Azure DevOps ceiling, the students obtained, on average, much higher final evaluation results. We also received direct information from students who much appreciated this method of corrective development, as they could efficiently work at their own pace and easily correct errors without jeopardizing the work already done. We recognize that these curricular areas are easily adapted to the use of these technologies; however, the results in terms of the evaluation were outstanding in the generality of the pool of students analyzed. We can even consider the assessment as excellent ( Figure 6). In the analysis of the second hypothesis, that is, when comparing the results of well-differentiated curricular units, in which they used types of curriculum development tools other than the Azure infrastructure, the results obtained would also have a pattern during the period of confinement comparable to the pattern obtained with the results shown in Figure 1 and 2. In the teaching scenario which employed DevOps, the average difference between the results of the assessment obtained before confinement and the results obtained during the confinement period for similar curricular units and represented in Figures 5 and 6, is five values -in the period of the confinement, the students obtained on average a much higher evaluation of five more values. On an evaluative scale of zero to twenty values, the difference is even higher than that obtained in an identical scenario in the Azure infrastructure curriculum. On the other hand, the results of standard deviations demonstrate that students learned and had better evaluations.
The value of the standard deviation for the results of the assessment in the preconfinement period and shown in Figure 5, is 1.5275; the standard deviation value for the evaluation results during the period of confinement, shown in Figure 6, is 1.3989. The latter value is lower, which means that the assessment obtained by students during the period of confinement, using Cloud Computing tools and taking classes exclusively online was much higher in the entire group of students studied.

Conclusion
In a new paradigm in which online education or combined teaching, both online and classroom, must be considered, having technologies which allow a correct teaching/learning process that achieves the objectives of obtaining skills through laboratories is a fundamental requirement.
The use of cloud computing technology allows today to give laboratory classes in the area of computer science entirely via online. As demonstrated, we can create an online laboratory on Azure and demonstrate/teach students how to develop a WEB application. On the other hand, students can use the same online infrastructure to build their project and put the acquired knowledge into practice. One can easily set up and provide on-demand access to preconfigured virtual machines (VMs) to support one's scenarios. One can teach a class, train professionals, run a hackathon or a hands-on lab, and more. Simply define your needs, and the service will roll the lab out to your audience. Users access all their lab VMs from a single place. For this reason, cloud computing laboratories solve problems of not accessing laboratories where students must be in person. From the study carried out using a mainly quantitative method, comparing the school results of two curricular units that had the need to use computational laboratories, in which one had access to on-site laboratories and others had only access to laboratories in Cloud Computing, it was found that the results of evaluation, performance, and easiness in reaching the objectives was more positive in the use of the laboratories in Cloud Computing, showing that all this teaching activity was carried out under enormous social and psychological pressure, due to the context of COVID-19. Another conclusion that we can also draw is that the most favourable results obtained through the use of Cloud Computing platforms are identical in totally different curricular units. That is why there is a correlation between the good results obtained in the use of Cloud Computing for laboratories in Azure and the application development platform (DevOps). However, if a second wave of COVID-19 occurs, this study should be repeated this year to increase the validation of the results now obtained.