Complexity in software projects tends to grow considerably as resources and stakeholders raise in numbers. Several factors may contribute to this, ranging from miscommunication between developers, to excessive dependency on external libraries and frameworks. Consequently, managing both developers and the assets they use becomes increasingly hard as features are implemented and changes in linguistic characteristics and coding styles become necessary. This position paper presents Programming Cocktails, their Ingredients, and Resources, three basic software development management concepts. These three main concepts culminate in Programming Cocktails Identity Cards, an ontology-based modelling technique to aid in assessing, planning, and understanding how each development technology contributes-both positively and negatively-to several aspects of software development, such as cognitive burden, risk and cost.
It is well established that as development projects grow in size and requirements multiply, complexity
also increases [
In this context, analysis should be made on the combined uses and interconnections of these
technologies, reaching beyond comparison of individual metrics (as it is common [
The answers to these questions rely on the knowledge behind these combinations and how to better use and choose which technologies should be integrated into a development project. Naturally, it is of utmost importance to structure and analyse this knowledge in a productive way, considering, first of all, which factor is under evaluation (risk, cost, cognitive burden etc.), and secondly, how each technology relates to each other in this analysis. This paper presents Programming Cocktails as a formal, structured and novel concept that should aid developers, managers and their peers in reaching further conclusions about the intrinsic relationships between languages, libraries, frameworks and tools in their projects.
This position paper is divided into five sections. After the introduction and contextualization in Section 1, Section 2 introduces the basic concepts of Programming Cocktails, Ingredients, and Resources. Section 3 presents Cocktail Identity Cards as an ontological form of identification for Programming Cocktails. Section 4 proposes augmentations to and uses for the Cocktail Identity Cards that could isa (specialization) iof (instantiation) pof (composition) pof (composition) General Concept
Concept
Composed Concept
Composed Individual improve planning of several aspects in development life-cycles, both technical, such as risk and cost, and psychological, such as cognitive burden and afinity attrition. Finally, Section 5 concludes the article with final remarks of what has already been modelled via Cocktail Identity Cards, and what is planned to be researched and implemented in the near future.
At its basis, Programming Cocktails are the sets of programming technologies that are directly used to
develop software systems [
Finally, technologies that indirectly participate in the development process, such as services and runtime support systems (e.g. Database Management Systems, DBMS) are considered Resources. While some of them might have components that are directly used in the development process (such as a connection library for a DBMS), the Resource itself is intended to support execution, not development.
These concepts were defined in an ontology that was initially created to structure knowledge about
data that was gathered in a survey [
The conceptual model is the starting point to the actual modelling of the Programming Cocktails, leaving practical application to its instantiation: the Cocktail Identity Cards.
TaskA TaskB
...
TaskZ
Task
Resource uses Development
Cocktail Ingredient
Library Language extends
The conceptual model forms the basis for the modelling process, providing guidelines akin to schematics for the actual model. Its instantiation, consequently, renders a series of interconnected individuals1 that provides an instant overview of the Cocktail’s structure. If carefully drawn and pruned2, the resulting diagram is easily recognizable and most of the structural information about the Cocktail is immediately observable, such as ingredient quantity and diversity, diferent branches of development, which languages are more dependant of complementary ingredients, etc.
Figures 3 and 4 show two Cocktail Identity Cards, for two diferent software systems. The first
is a Web application for an in-house Questions and Answers (Q&A) system. As can be seen, not all
relations are shown, as the System, Development and Cocktail concepts are hidden to improve legibility.
The tasks were defined in a higher level of abstraction, including only general areas of development
(markup, styling and scripting). This might not be the case with a diferent Cocktail, or even at another
situation for the same Cocktail that requires a more detailed representation of each Ingredient’s role
in the project implementation. In the end, the definition of the granularity (or abstraction level) of
the tasks is highly situational. The second Identity Card (shown in Figure 4) models a Covid-19 pass
management mobile application. It has two branches of development, one for each target platform: iOS
and Android. This Identity Card also shows that both languages, Swift and Kotlin, are less dependant on
complementary code, as no instances of Library and Framework are connected to them3. This may lead
to a lower complexity, as linguistic and psychological features (such as afinity [
The Cocktail Identity Cards are useful as-is for quick identification of several characteristics of the Cocktails they represent. Nonetheless, if augmented with further information, it may serve as a foundation for other, more complex analysis. 4. Possible Uses and Augmentation for Cocktail Identity Cards Despite the immediate structural feedback obtained from the Identity Cards, more can be represented and documented if the relationships in the model are augmented to represent specific metrics. These metrics may relate to technical aspects, such as cost of maintenance, size needed for cloud hosting, or 1The instance of an ontological concept may also be called an individual. 2Some instantiation relations are hidden in order to avoid cluttering the diagram. 3That is not to say that these languages are inherently less dependent on other components, only that in this case, the model indicates a lower level of dependency.
Elasticsearch
MongoDB
RabbitMQ
App1 uses App1Cocktail
uses App2iOSCocktail
Swift
definitive linguistic metrics, such as number of data types and functions. On the other hand, some more
qualitative metrics could also be applied, such as cognitive burden [
HIGH JavaScript
HIGH
HIGH
HIGH LOW
NodeJS
ReactJS changed and evolved, aiding in tracking and predicting software evolution, as the software evolution can be represented by a set of identity cards in a timeline sequence.
A second possible use for the Identity Cards is decision support. By comparing diferent Identity Cards augmented with metrics such as cost, risk and cognitive burden, decision on which technologies should be included (or substituted) in the project could be taken with an overview of its impact on the project and on the team behind it. Figure 5 presents part of App1’s Cocktail Identity Card (see Figure 3) with hypothetical augmentations that represent security risks for each Ingredient. The values superimposed on the relations (HIGH and LOW ) could be measured based on specific linguistic features, such as the direct memory access via pointers, manual memory allocation, lack of bounds management in data structures, etc. but could also take into consideration historic findings about each technology and the inherent nature of its use. As an example of the latter, a markup language is naturally less vulnerable to exploits as it tends to express only structure instead of behavior and would contribute less to possible vulnerabilities. A simple score-card could be created to establish the level of risk for each Ingredient, and most important of all, for the relations between each other (such as between NodeJS and JavaScript in Figure 5).
As for comparison against other modelling options, a few points can be made: • By their own nature, ontologies are more flexible in their construction than other modelling techniques that have pre-defined semantics, such as Class Diagrams. This fact could lend Cocktail Identity Cards to better fit specific scenarios, as characteristics from diferent points of view can be assembled in one model. One possible caveat with this argument is that this flexibility could also decrease standardization. It could eventually hinder communication and information exchange between peers that come from diferent projects, given that each group would adapt the ontology to their particular needs; • Diferent levels of abstraction can be expressed in a single model, as new concepts do not have to adhere to any sort of pre-established abstraction level or standard; • By using only ontological modelling, fragmentation of tools and techniques can be avoided or at least reduced. This lowers development complexity between diferent peers in a project, such as developers, designers, managers, etc.
Programming Cocktails provide a novel way to model and observe how diferent technologies compose and interact in a development setting. This paper presented the foundational ideas and concepts behind them, as well as their immediate result: Cocktail Identity Cards. Through future research into augmenting these Identity Cards, stakeholders in a software development project could evaluate, record, document and analyse diferent metrics, ranging from the most technical and quantitative, such as points of vulnerability and racing conditions, to more philosophical and qualitative ones, such as quality, afinity, and attrition. Software evolution and maintenance could also be tackled by constructing historic accounts for the changes that occur in Cocktails during its lifetime, establishing a sequence of Identity Cards that represent the evolution of their development technologies. The Cocktail Identity Cards will be used to assess cognitive burden in Programming Cocktails, culminating in a decisionsupport methodology that should aid developers and educators in choosing programming languages, frameworks, libraries and tools that lessens the cognitive load requirements for developers and students.
This work has been supported by FCT – Fundação para a Ciência e Tecnologia within the R&D Units Project Scope: UIDB/00319/2020. The work of Maria João was supported by national funds through FCT/MCTES (PIDDAC): CeDRI, UIDB/05757/2020 (DOI: 10.54499/UIDB/05757/2020) and UIDP/05757/2020 (DOI: 10.54499/UIDP/05757/2020); SusTEC, LA/P/0007/2020 (DOI: 10.54499/LA/P/0007/2020).