=Paper=
{{Paper
|id=Vol-3941/BENEVOL2024_NICE_paper1
|storemode=property
|title=Application of Programming Cocktails Identity Cards to
Development Complexity Analysis
|pdfUrl=https://ceur-ws.org/Vol-3941/BENEVOL2024_NICE_paper1.pdf
|volume=Vol-3941
|authors=Alvaro Costa Neto,Maria João Varanda Pereira,Pedro Rangel Henriques
|dblpUrl=https://dblp.org/rec/conf/benevol/NetoPH24
}}
==Application of Programming Cocktails Identity Cards to
Development Complexity Analysis==
https://ceur-ws.org/Vol-3941/BENEVOL2024_NICE_paper1.pdf
Application of Programming Cocktails Identity Cards to
Development Complexity Analysis
Alvaro Costa Neto1,2,3 , Maria João Varanda Pereira2 and Pedro Rangel Henriques3
1
Instituto Federal de Educação, Ciência e Tecnologia de São Paulo, Avenida C-1, 250, 14781-502 Barretos, SP, Brasil
2
Instituto Politécnico de Bragança, Campus de Santa Apolónia, 5300-253 Bragança, Portugal
3
ALGORITMI Research Centre/LASI, DI - University of Minho, Campus de Gualtar, Rua da Universidade, 4710-057 Braga, Portugal
Abstract
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.
Keywords
programming cocktails, programming languages, development complexity, cognitive analysis
1. Introduction
It is well established that as development projects grow in size and requirements multiply, complexity
also increases [1, 2, 3, 4]. From the many factors that contribute to this growth, the interconnection be-
tween programming technologies (such as languages, libraries, tools and frameworks) poses challenges
that may negatively affect cognitive effectiveness, raise risks and generate costs.
In this context, analysis should be made on the combined uses and interconnections of these technolo-
gies, reaching beyond comparison of individual metrics (as it is common [5, 6, 7]). This point-of-view
highlights several factors that may influence success in choosing and managing which programming
technologies should be used in a certain project. Which language is a better fit for a substitution
mid-development? What cognitive strains would it impose based on its differences to other languages,
libraries and frameworks already in use? Do these differences raise security risks and vulnerabilities, or
do they enforce behaviors that may nullify each other weaknesses?
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
BENEVOL’24: 23rd Belgium-Netherlands Software Evolution Workshop, November 21–22, 2024, Namur, Belgium
$ alvaro@ifsp.edu.br (A. Costa Neto); mjoao@ipb.pt (M. J. V. Pereira); prh@di.uminho.pt (P. R. Henriques)
http://www.ipb.pt/~mjoao/ (M. J. V. Pereira); https://www.di.uminho.pt/~prh/ (P. R. Henriques)
0000-0003-1861-3545 (A. Costa Neto); 0000-0001-6323-0071 (M. J. V. Pereira); 0000-0002-3208-0207 (P. R. Henriques)
© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
Specific Concept Individual Composing Concept Composing Individual
isa (specialization) iof (instantiation) pof (composition) pof (composition)
General Concept Concept Composed Concept Composed Individual
Figure 1: Programming Cocktails ontology’s graphical notation.
improve planning of several aspects in development life-cycles, both technical, such as risk and cost,
and psychological, such as cognitive burden and affinity 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.
2. Programming Cocktails
At its basis, Programming Cocktails are the sets of programming technologies that are directly used to
develop software systems [8]. They may be composed of four types of Ingredients:
• Languages for programming, communication, configuration etc.
• Libraries, both in source and pre-compiled varieties;
• Frameworks, as complementary code that requires the use or adoption of specific protocols,
behavior or paradigms;
• Tools that are directly used in the development tasks, such as source code editors, and IDEs.
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 [8]. It formed the basis on which the entire model of Programming
Cocktails was created, including the Cocktail Identity Cards (explained in Section 3). Figure 2 shows
the open conceptual model for the ontology (see Figure 1 for the graphical notation), with all its basic
definitions, such as the previously mentioned concepts, the core concepts of System, Development, and
Cocktail, as well as Tasks, which correspond to actual development tasks, such as Front-end Development,
Database Communication and equivalent. There are two more important points to be made about the
ontology:
• Despite the fact that the original intention of the ontology was to structure the data gathered in
the survey [8], the results have become a foundation for modelling Cocktails via instantiation of
the open conceptual model. This should aid stakeholders in the development team to visualize,
document, analyse and decide which programming technologies should be used and why;
• The conceptual model is considered open because the definition of the Task specializations (TaskA
to TaskZ) is deferred to the individuals that will model Programming Cocktails using it. This
decision aims to avoid pre-defining tasks that would eventually be either too generic for any kind
of useful representation, or too granular and specific, which would inevitably lead to obsolescence.
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.
supports
System Resource
TaskA
requires
Development
uses
TaskB
Library
Task Cocktail
extends
..
. Language
Ingredient
supports orchestrates
Framework supports
TaskZ
Tool
Figure 2: Open conceptual model for the Programming Cocktails ontology.
3. Cocktail Identity Cards
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 pruned 2 , the
resulting diagram is easily recognizable and most of the structural information about the Cocktail is
immediately observable, such as ingredient quantity and diversity, different branches of development,
which languages are more dependant of complementary ingredients, etc.
Figures 3 and 4 show two Cocktail Identity Cards, for two different 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 different 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 affinity [9, 10] and cognitive
load [11]) are constant in each branch.
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
1
The instance of an ontological concept may also be called an individual.
2
Some instantiation relations are hidden in order to avoid cluttering the diagram.
3
That 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.
Resource
Elasticsearch MongoDB RabbitMQ
supports supports supports
App1
requires
Language App1Development Framework
uses
App1Cocktail
orchestrates
CSS HTML JavaScript NodeJS ReactJS
supports supports supports supports supports
WebSiteStyling WebSiteMarkup WebSiteScripting
Figure 3: Cocktail Identity Card for a Q&A system.
App2
requires requires
App2iOSDevelopment App2AndroidDevelopment
uses uses
App2iOSCocktail Tool App2AndroidCocktail
Language Language
Swift Kotlin
AdobeXD
supports supports
supports
BusinessLogic UserInterface
Prototyping
Figure 4: Cocktail Identity Card for a multiplatform Covid-19 pass application.
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 [12], affinity, security risk, etc. With
these augmentations, the Identity Cards would provide different points-of-view for the structure of the
Cocktail. Stakeholders would be able to quickly assess current, former and even possibilities for future
changes in the Cocktail’s structure and how these changes would affect each of the augmented metrics.
This use would form a historic account of how the programming technologies in the project have
App1Cocktail
LOW HIGH
LOW HIGH
HIGH
CSS HTML JavaScript LOW NodeJS ReactJS
HIGH
Figure 5: Hypothetical security risk augmentation for App1’s Cocktail. This analysis would be recursively
applied up to the System instance.
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 different 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 different 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 different projects, given that each group would adapt
the ontology to their particular needs;
• Different 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 different peers in a project, such as
developers, designers, managers, etc.
5. Conclusion
Programming Cocktails provide a novel way to model and observe how different 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 different 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, affinity, 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 decision-
support 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.
Acknowledgments
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).
References
[1] A. Ghazarian, A theory of software complexity, in: 2015 IEEE/ACM 4th SEMAT Workshop on a
General Theory of Software Engineering, 2015, pp. 29–32. doi:10.1109/GTSE.2015.11.
[2] M. Benaroch, K. Lyytinen, How much does software complexity matter for maintenance produc-
tivity? the link between team instability and diversity, IEEE Transactions on Software Engineering
49 (2023) 2459–2475. doi:10.1109/TSE.2022.3222119.
[3] T. Honglei, S. Wei, Z. Yanan, The research on software metrics and software complexity metrics,
in: 2009 International Forum on Computer Science-Technology and Applications, volume 1, 2009,
pp. 131–136. doi:10.1109/IFCSTA.2009.39.
[4] L. Hanyan, W. Shihai, L. Bin, X. Peng, Software complexity measurement based on complex
network, in: 2017 8th IEEE International Conference on Software Engineering and Service Science
(ICSESS), 2017, pp. 262–265. doi:10.1109/ICSESS.2017.8342910.
[5] A. H. Odeh, Analytical and comparison study of main web programming languages: Asp
and php, TEM Journal 8 (2019) 1517–1522. URL: http://www.temjournal.com/content/84/
TEMJournalNovember2019_1517_1522.pdf. doi:10.18421/TEM84-58.
[6] M. Fourment, M. R. Gillings, A comparison of common programming languages used in bioin-
formatics, BMC Bioinformatics 82 (2008). URL: https://bmcbioinformatics.biomedcentral.com/
articles/10.1186/1471-2105-9-82. doi:10.1186/1471-2105-9-82.
[7] N. Walia, A. Kalia, Programming languages for data mining: a review, International Journal
of Computer Trends and Technology 68 (2020) 38–41. URL: https://ijcttjournal.org/archives/
ijctt-v68i1p109. doi:10.14445/22312803/IJCTT-V68I1P109.
[8] A. C. Neto, M. J. V. Pereira, P. R. Henriques, An ontology to understand programming cocktails,
in: M. Ganzha, L. Maciaszek, M. Paprzycki, D. Ślęzak (Eds.), Proceedings of the 19th Conference
on Computer Science and Intelligence Systems, Annals of Computer Science and Information
Systems, IEEE, 2024. To be published.
[9] A. Costa Neto, C. Araújo, M. J. V. Pereira, P. R. Henriques, Programmers’ affinity to languages,
volume 91, Open Access Series in Informatics (OASIcs), Schloss Dagstuhl – Leibniz-Zentrum
für Informatik, 2021, pp. 1–7. URL: https://drops.dagstuhl.de/opus/volltexte/2021/14219. doi:10.
4230/OASIcs.ICPEC.2021.3.
[10] A. Costa Neto, C. Araújo, M. J. V. Pereira, P. R. Henriques, Value-focused investigation into
programming languages affinity, volume 102, Open Access Series in Informatics (OASIcs), Schloss
Dagstuhl – Leibniz-Zentrum für Informatik, 2022, pp. 1–12. URL: https://drops.dagstuhl.de/opus/
volltexte/2022/16605. doi:10.4230/OASIcs.ICPEC.2022.1.
[11] V. Chiew, Y. Wang, A large-scale empirical study on the cognitive complexity of software, in:
CCECE 2010, 2010, pp. 1–4. doi:10.1109/CCECE.2010.5575116.
[12] J. Sweller, Cognitive load during problem solving: Effects on learning, Cognitive Science 12 (1988)
257–285. URL: https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1202_4. doi:https:
//doi.org/10.1207/s15516709cog1202_4.