Abstract Cybersecurity analysis touches on diverse interdisciplinary aspects, both technical and business-oriented, and diverse stakeholders from different backgrounds must be supported with a knowledge capture environment that operationalizes the “secure by design” principles while also ensuring semantic traceability of the design decisions, to enable AI-based analysis. This paper introduces a domain-specific modeling method supported by a process-centric visual language (a BPMN extension) to enable a knowledge graph treatment for designing cyber threats mitigations in tandem with business process engineering activities and associated data flows. The treatment is intended to be leveraged by LLM (large language model) services, therefore experimentation leans towards AI integration. The domain-specific modeling language (DSML) hybridizes BPMN and threat modeling, further subjected to model transformations into RDF graphs. A demonstrator is implemented on the ADOxx metamodeling platform and its interoperability/adapters for integration with triplestores and LLMs—this makes possible both SPARQL and natural language queries over the prescriptive diagrammatic designs, as analysis approaches. The proposed method can be used to describe contextualized cybersecurity threats during the design phase of a system or during IT system auditing. The integration bridge with knowledge graphs and large language models enhances the system analysis capabilities by streamlining heterogeneous knowledge flows comprising diagrammatic representation, RDF graphs and generative AI, towards an emerging flavor of model-driven engineering. The method was developed iteratively according to the Design Science framework, with its development activities specialized for the DSML-focused Agile Modeling Method Engineering framework.

Abstract Symbolic AI has been facing long-term adoption obstacles and a slow uptake caused by the limited availability of frictionless tooling—that can support not only knowledge engineers, but also novice users and educators, with designing and presenting graph exemplars that can be visually communicated, edited and ad hoc processed. There’s still a shortage of tools that can democratize knowledge graph (KG) creation, something that is increasingly needed—firstly by educators trying to discuss examples with novices without stumbling on OWL jargon at the earliest step, but also for more recent integration cases such as (i) GraphRAG, where private KGs are called to augment or ensure factuality of large language model services; or (ii) in search engine optimization (SEO), where SEO practitioners lacking knowledge engineering background must embed Schema.org graph data into their Web content. Most visual KG tools are visualizers of KGs created by other means—either in OWL-centric ontology editors posing high expertise barriers, or converted from available serializations, or lifted from legacy data sources. The few actual KG editors are mostly OWL editors neglecting to support the creation of schemaless graph datasets as well as of flexible combinations of graph data and schema fragments. This paper reports on a Design Science effort adopting metamodeling means, traditionally employed for the engineering of domain-specific modeling languages, toward defining a KG development and integration method that facilitates both the visual design of KG exemplars and their operationalization. We aim to balance a diagrammatic look and feel with machine readability of the semantic content being produced—further streamlined in an architecting proposition for integration with LLM services and for the production of Schema.org graph snippets. The DSML was deployed and evaluated as a tool implemented on the ADOxx metamodeling platform, using RDF and LangChain as mediators that streamline the content toward triplestores and LLM services.

Debugging is hard. Interactive debuggers are mostly the same. They show you a stack, a way to sample the state of the stack, and, if the debugger is live, a way to step through execution. The standard interactive debugger for a general-purpose programming language provided by a mainstream IDE mostly offers a low-level interface in terms of generic language constructs to track down and fix bugs. A custom debugger, such as those developed for specific application domains, offers alternative interfaces more suitable to the specific execution context of the program being debugged. Custom debuggers offering contextual debugging views and actions can greatly improve our ability to reason about the current problem. Implementing such custom debuggers, however, is non-trivial, and poses a barrier to improving the debugging experience. In this paper we introduce moldable exceptions, a lightweight mechanism to adapt a debugger’s interface based on contextual information provided by a raised exception. We present, through a series of examples, how moldable exceptions can enhance a live programming environment.

A traditional round-trip engineering approach based on model transformations does not scale well to modern agile development environments where numerous artifacts are produced using a range of heterogeneous tools and technologies. To boost artifact connectivity and maintain their consistency, we propose to create and manage software-related artifacts as first-class entities directly in an integrated development environment (IDE). This approach has two advantages: (i) compared to employing separate tools, creating various artifacts directly within a development platform eliminates the necessity to recover trace links, and (ii) first-class artifacts can be composed into stakeholder-specific live document-artifacts. We detail and exemplify our approach in the Glamorous Toolkit IDE (henceforth, Glamorous toolkit), and discuss the results of a semi-structured pilot survey we conducted with practitioners and researchers to evaluate its usefulness in practice.

Exception handling allows developers to deal with abnormal situations that disrupt the execution flow of a program. There are mainly three types of exceptions: standard exceptions provided by the programming language itself, custom exceptions defined by the project developers, and third-party exceptions defined in external libraries. We conjecture that there are multiple factors that affect the use of these exception types. We perform an empirical study on long-lived Java projects to investigate these factors. In particular, we analyze how developers rely on the different types of exceptions in throw statements and exception handlers. We confirm that the domain, the type, and the development phase of a project affect the exception handling patterns. We observe that applications have significantly more error handling code than libraries and they increasingly rely on custom exceptions. Also, projects that belong to different domains have different preferences of exception types. For instance, content management systems rely more on custom exceptions than standard exceptions whereas the opposite is true in parsing frameworks.

Programming languages use exceptions to handle abnormal situations during the execution of a program. While programming languages often provide a set of standard exceptions, developers can further create custom exceptions to capture relevant data about project- and domain-specific errors. We hypothesize that, given their usefulness, custom exceptions are used increasingly as software systems mature. To assess this claim, we empirically analyze the evolution of exceptions and exception-handling code within four, popular and long-lived Java systems. We observe that indeed the amount of error-handling code, together with the number of custom exceptions and their usage in catch handlers and throw statements increase as projects evolve. However, we find that the usage of standard exceptions increases more than the usage of custom exceptions in both catch handlers and throw statements. A preliminary manual analysis of throw statements reveals that developers encode the domain information into the standard Java exceptions as custom string error messages instead of relying on custom exception classes.

A picture tells a thousand words. We all know that. Then why are our development tools showing mainly text with so much obstinacy? Even when visualizations do make it into our tools, they typically do not make it past the periphery. Something is deeply wrong. We argue that visualizations must become pervasive in software development, and to accommodate this goal, the integrated development environments must change significantly.

Analyzing how software engineers use the Integrated Development Environment (IDE) is essential to better understanding how engineers carry out their daily tasks. SPOTTER is a code search engine for the Pharo programming language. Since its inception, SPOTTER has been rapidly and broadly adopted within the Pharo community. However, little is known about how practitioners employ SPOTTER to search and navigate within the Pharo code base. This paper evaluates how software engineers use SPOTTER in practice. To achieve this, we remotely gather user actions called events. These events are then visually rendered using an adequate navigation tool chain. Sequences of events are represented using a visual alphabet. We found a number of usage patterns and identified underused SPOTTER features. Such findings are essential for improving SPOTTER.

Software corpora facilitate reproducibility of analyses, however, static analysis for an entire corpus still requires considerable effort, often duplicated unnecessarily by multiple users. Moreover, most corpora are designed for single languages increasing the effort for cross-language analysis. To address these aspects we propose Pangea, an infrastructure allowing fast development of static analyses on multi-language corpora. Pangea uses language-independent meta-models stored as object model snapshots that can be directly loaded into memory and queryed without any parsing overhead. To reduce the effort of performing static analyses, Pangea provides out-of-the box support for: creating and refining analyses in a dedicated environment, deploying an analysis on an entire corpus, using a runner that supports parallel execution, and exporting results in various formats. In this tool demonstration we introduce Pangea and provide several usage scenarios that illustrate how it reduces the cost of analysis.