Metacommunication between programmers through an application programming interface: A semiotic analysis of date and time APIs

BASTOS, JOAO ANTONIO DUTRA MARCONDES; Afonso, Luiz Marques; Souza, Clarisse Sieckenius de

doi:10.1109/vlhcc.2017.8103470

Cited by 11 publications

(9 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Semiotic Engineering has also been applied in the evaluation of programming APIs. The work of Bastos et al [52] applied a semiotic engineering method called SigniFYIng APIs. In this work, they evaluated a date and time API of the Java programming language.…”

Section: Semiotic Engineeringmentioning

confidence: 99%

On the identification of design problems in stinky code: experiences and tool support

et al. 2018

View full text Add to dashboard Cite

Background: Developers often have to locate design problems in the source code. Several types of design problems may manifest as code smells in the program. A code smell is a source code structure that may reveal a partial hint about the manifestation of a design problem. Recent studies suggest that developers should ignore smells occurring in isolation in a program location. Instead, they should focus on analyzing stinkier code, i.e., program locations-e.g., a class or a hierarchy-affected by multiple smells. There is evidence that the stinkier a program location is, the more likely it contains a design problem. However, there is no empirical evidence on whether developers can effectively identify a design problem in stinkier code. Developers may struggle to make an analysis of inter-related smells affecting the same program location. Besides that, the analysis of stinkier code may require proper tool support due to its analysis complexity. However, there is little knowledge on what are the requirements for a tool that helps developers in revealing stinkier program locations. As a result, developers may not be able to identify design problems due to tool issues. Method: To address this matter, we aimed at achieving three goals. In the first case, we proposed Organic-a tool supporting the analysis of stinky code. In the second case, we applied a mixed-method approach to analyze if and how developers can effectively find design problems when reflecting upon stinky code-i.e., a program location affected by multiple smells. We conducted a study with 11 software professionals. Finally, in the third case, we aimed at understanding if Organic could be used by developers to identify design problems. To achieve this goal, we used a method from the Semiotic Engineering theory. This method enabled us to evaluate what are the tool issues that may hinder the identification of design problems in stinky code. Result: Our study revealed that only 36.36% of the developers found more design problems when explicitly reasoning about multiple smells as compared to single smells. Moreover, 63.63% of the developers reported much lesser false positives when using the first approach as compared to the latter. The second study, in its turn, showed that most developers may be unable to identify design problems in stinky code without proper tool support. Conclusion: Our experiences, in particular the second study, helped us to refine the features of Organic for better supporting developers in reflecting upon stinkier code. For example, analyses of stinky code scattered in class hierarchies or packages is often difficult, time-consuming, and requires proper visualization support. Moreover, without effective support, it remains time-consuming to discard stinky program locations that do not represent design problems.

show abstract

Section: Semiotic Engineeringmentioning

confidence: 99%

On the identification of design problems in stinky code: experiences and tool support

et al. 2018

View full text Add to dashboard Cite

show abstract

“…This chapter presents a paper that was published in the Symposium (3). This paper is presented as the first contribution from the work we developed in this thesis: the creation of the concept of conversational APIs (section 1.2).…”

Section: Api As Conversation Mediator Artifactmentioning

confidence: 99%

“…However, designing an API that explains the design rationale of who created it is not a trivial task. One way to accomplish this task is through the creation of conversational APIs (3). The notion of conversational APIs, characterized in this thesis, contains potential pre-established dialogues for the API to have with its users.…”

Section: Introductionmentioning

confidence: 99%

“…The notion of conversational APIs, characterized in this thesis, contains potential pre-established dialogues for the API to have with its users. The lack of explicitly defined conversational resources hinders the API users in understanding how to properly use their interfaces (3). In chapter 2, we demonstrated through a study with date and time APIs in Java how harmful it could be the use of an API that lacks in conversations.…”

Section: Introductionmentioning

confidence: 99%

“…A conversational API is an API capable of indicating the appropriate use to its users, solving pragmatic conflicts during the API use. The lack of the conversational characteristics hampers API users on understanding how to properly use the API's interfaces (3). The concept of conversational API is anchored in the Semiotic Engineering (13), a theory of human-computer interaction.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Promoting Conversational Apis: A Conceptual Framework and a Method for Api Design

BASTOS¹

View full text Add to dashboard Cite

To my advisor Professor Alessandro Garcia for the stimulus and partnership for this work. Thank you for believing in my work and for accepting the difficult mission of concluding a doctoral work that was already underway. To my first teacher counselor Clarisse de Souza and to my co-coordinator Luiz Afonso for all the help and guidance in the initial part of the Doctorate. By chance of fate we ended up not concluding the doctorate together, but your help was fundamental for my success. Thanks also to Professor Renato Cerqueira for the opportunity to carry out part of the research in the IBM Research Brazil laboratory. To all friends and research partners of OPUS and SERG groups. Thank you for all your support throughout my Doctorate. Counting on such well aligned and tuned groups helped a lot on the path to individual success. Thank you very much to all of you who in various ways contributed to my work. In particular, my thanks to Daniel Tenorio and Rafael Maiani who participated in an active way dedicating much time to my Doctoral research. Thank you very much for your valuable comments, suggestions and reviews. To my mother, Miriam, and to my wife Erica, without whom I would not have achieved success in this thesis. Thank you for all your support throughout this journey. To my in-laws, Alcemir and Dione for their support and affection over the past few years. To my brother Ernesto and his family. To my grandmother Zica and my aunts Marlene and Neuza. To all my friends and family who have supported me in this journey in various ways, thank you very much.

show abstract

How “Friendly” Integrated Development Environments Are?

Morales

Botella

Rusu

et al. 2019

Social Computing and Social Media. Design, Human Behavior and Analytics

View full text Add to dashboard Cite

Metacommunication between programmers through an application programming interface: A semiotic analysis of date and time APIs

Cited by 11 publications

References 14 publications

On the identification of design problems in stinky code: experiences and tool support

On the identification of design problems in stinky code: experiences and tool support

Promoting Conversational Apis: A Conceptual Framework and a Method for Api Design

How “Friendly” Integrated Development Environments Are?

Contact Info

Product

Resources

About