Working Notes from the 1992 AAAI Workshop on Automating Software Design. Theme: Domain Specific Software Design

The goal of this workshop is to identify different architectural approaches to building domain-specific software design systems and to explore issues unique to domain-specific (vs. general-purpose) software design. Some general issues that cut across the particular software design domain include: (1) knowledge representation, acquisition, and maintenance; (2) specialized software design techniques; and (3) user interaction and user interface

Elements of Design for Containers and Solutions in the LinBox Library

We describe in this paper new design techniques used in the \cpp exact linear algebra library \linbox, intended to make the library safer and easier to use, while keeping it generic and efficient. First, we review the new simplified structure for containers, based on our \emph{founding scope allocation} model. We explain design choices and their impact on coding: unification of our matrix classes, clearer model for matrices and submatrices, \etc Then we present a variation of the \emph{strategy} design pattern that is comprised of a controller--plugin system: the controller (solution) chooses among plug-ins (algorithms) that always call back the controllers for subtasks. We give examples using the solution \mul. Finally we present a benchmark architecture that serves two purposes: Providing the user with easier ways to produce graphs; Creating a framework for automatically tuning the library and supporting regression testing.Comment: 8 pages, 4th International Congress on Mathematical Software, Seoul : Korea, Republic Of (2014

A heuristic-based approach to code-smell detection

Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

Formal Specification and Testing of a Management Architecture

The importance of network and distributed systems management to supply and maintain services required by users has led to a demand for management facilities. Open network management is assisted by representing the system resources to be managed as objects, and providing standard services and protocols for interrogating and manipulating these objects. This paper examines the application of formal description techniques to the specification of managed objects by presenting a case study in the specification and testing of a management architecture. We describe a formal specification of a management architecture suitable for scheduling and distributing services across nodes in a distributed system. In addition, we show how formal specifications can be used to generate conformance tests for the management architecture

Developing an architecture for a test sequencer

Testing is an important aspect of developing systems and products. It ensures quality of the product and that it works as it has been specified to work. Testing is a very expensive and time consuming process. It can be made more effective by automating it using test automation tools. In this work a test automation tool called DriveTest2 is developed. DriveTest2 is a test sequencer that can be used to test different kinds of devices. A test sequencer is a program that controls a test setup by creating command sequences to device under test and other devices in the test setup. DriveTest2 will be capable of data acquisition during tests. This data is used for monitoring the sequence and for test reports. DriveTest2 can be used for different kinds of testing such as verification, reliability, accelerated lifetime and stress testing. DriveTest2 will replace an existing software called DriveTest. DriveTest is replaced because it is hard to maintain and update, and there is no documentation. The objective of this work is to find out what kind of software archi tecture a test sequencer should have. DriveTest2 and its architecture is developed using an iterative development process. Develop ment starts from gathering and analyzing requirements for the software which was done in pre vious work. The first iteration of the architecture is created from these requirements. Then the first design and implementation of DriveTest2 is created and given to users to get feedback. According to the feedback and requirements, refinements to the architecture and implementa tion are made. Then this process is repeated until we have software that we are satisfied with. DriveTest2 is developed using C# programming language. DriveTest2 uses Model-View-View Model architectural pattern to separate user interface and business logic. The business logic of DriveTest2 is designed to be object-oriented and is modelled using UML class diagrams. Throughout the iterations the architecture and design are refined with changes to the initial architecture and new functionalities like new interfaces to handle device specific functionalities. As a result of this work, we have an iteration of DriveTest2 that is used in test laboratories with success. The software architecture of DriveTest2 enables DriveTest2 to satisfies its critical func tional and non-functional requirements. We can conclude that a test sequencer software archi tecture should be able to enable the software to satisfy its requirements, have decoupled com ponents with clear responsibilities, be flexible enough to accommodate changes to the architec ture during the development and be extensible so that new functionalities can be added and make use of abstraction to abstract lower-level components and the actual hardware.Testaaminen on tärkeä osa tuotteiden ja systeemien kehityksessä. Sillä varmistetaan, että tuote pystyy tekemään sille määritetyt asiat ja, että se on laadukas. Testaaminen on hyvin kallis ja aikaa vievä prosessi. Sitä voidaan tehostaa automatisoimalla käyttäen testiautomaa-tiotyökaluja. Tässä työssä kehitetään testiautomaatiotyökalu nimeltä DriveTest2. DriveTest2 on testisekvensseri, jota voidaan käyttää erilaisten laitteiden testaamiseen. Testisekvenssi on ohjelma, jolla voidaan ohjata testiympäristön laitteita luomalla sekvenssejä, jotka muo-dostuvat komennoista. DriveTest2 pystyy keräämään dataa sekvenssin ajon aikana. Tätä da-taa käytetään sekvenssin ajon monitorointiin ja testiraportissa. DriveTest2:sta voidaan käyt-tää erilaisissa testeissä kuten verifikaatio-, luotettavuus-, elinikä- ja stressitesteissä. Drive-Test2 korvaa olemassa olevan testisekvensserin nimeltä DriveTest. DriveTest korvataan, kos-ka sitä on vaikea ylläpitää ja päivittää ja siihen ei ole olemassa dokumentaatiota. Tämän työn tavoite on selvittää millainen ohjelmistoarkkitehtuuri testisekvensseri pitää olla. DriveTest2 ja sen ohjelmistoarkkitehtuuria kehitetään iteratiivisella kehitysprosessilla. Kehi-tys alkaa vaatimusten keräämisellä ja analysoinnilla, joka tehtiin aikaisemmassa työssä. Näi-den vaatimusten perusteella luodaan ensimmäinen versio ohjelmistoarkkitehtuurista. Tämän ohjelmistoarkkitehtuurin perusteella luodaan ensimmäinen iteraatio DriveTest2:sen toteu-tuksesta ja se annetaan käyttäjille saadaksemme palautetta. Palautteen ja vaatimusten pe-rusteella arkkitehtuuria ja toteutusta hiotaan paremmaksi. Tätä prosessia sitten toistetaan, kunnes todetaan, että ohjelmisto on riittävän hyvä. DriveTest2 kehitetään C# ohjelmointikielellä. DriveTest2 käyttää Model-View-ViewModel arkkitehtuurimallia erottaakseen käyttöliittymän muusta logiikasta. DriveTest2:sen logiikka on tehty olio-ohjelmoinnilla ja se on mallinnettu UML luokkakaavioilla. Iteraatioiden aikana Dri-veTest2:sen ohjelmistoarkkitehtuuria hiottiin paremmaksi muuttamalla aikaisempaa arkki-tehtuuria ja lisäämällä uusia toiminnallisuuksia kuten uusia rajapintoja hoitamaan laitekohtai-sia toiminallisuuksia. Työn tuloksena saatiin luotua iteraatio DriveTest2:sta, jota pystytään käyttämään testilabora-torioissa hyvällä menestyksellä. DriveTest2:sen ohjelmistoarkkitehtuuri pystyy mahdollista-maan, että DriveTest2 pystyy toteuttamaan sille määritetyt toiminnalliset ja ei-toiminnalliset vaatimukset. Voidaan päätellä, että testisekvensserin ohjelmistoarkkitehtuurin on pystyttävä mahdollistamaan sille määritettyjen vaatimusten täyttäminen. Sillä on oltava komponentejä, joilla on selvät vastuualueet, ja sen on hyödynnettävä abstraktointia varsinkin laitetasolla. Arkkitehtuurin on oltava joustava, jotta sitä voidaan muokata ja kehittää kehityksen aikana sekä lisäämään uusia toiminnallisuuksia

Automatically generating complex test cases from simple ones

While source code expresses and implements design considerations for software system, test cases capture and represent the domain knowledge of software developer, her assumptions on the implicit and explicit interaction protocols in the system, and the expected behavior of different modules of the system in normal and exceptional conditions. Moreover, test cases capture information about the environment and the data the system operates on. As such, together with the system source code, test cases integrate important system and domain knowledge. Besides being an important project artifact, test cases embody up to the half the overall software development cost and effort. Software projects produce many test cases of different kind and granularity to thoroughly check the system functionality, aiming to prevent, detect, and remove different types of faults. Simple test cases exercise small parts of the system aiming to detect faults in single modules. More complex integration and system test cases exercise larger parts of the system aiming to detect problems in module interactions and verify the functionality of the system as a whole. Not surprisingly, the test case complexity comes at a cost -- developing complex test cases is a laborious and expensive task that is hard to automate. Our intuition is that important information that is naturally present in test cases can be reused to reduce the effort in generation of new test cases. This thesis develops this intuition and investigates the phenomenon of information reuse among test cases. We first empirically investigated many test cases from real software projects and demonstrated that test cases of different granularity indeed share code fragments and build upon each other. Then we proposed an approach for automatically generating complex test cases by extracting and exploiting information in existing simple ones. In particular, our approach automatically generates integration test cases from unit ones. We implemented our approach in a prototype to evaluate its ability to generate new and useful test cases for real software systems. Our studies show that test cases generated with our approach reveal new interaction faults even in well tested applications. We evaluated the effectiveness of our approach by comparing it with the state of the art test generation techniques. The evaluation results show that our approach is effective, it finds relevant faults differently from other approaches that tend to find different and usually less relevant faults

Extending ROOT through Modules

The ROOT software framework is foundational for the HEP ecosystem, providing capabilities such as IO, a C++ interpreter, GUI, and math libraries. It uses object-oriented concepts and build-time components to layer between them. We believe additional layering formalisms will benefit ROOT and its users. We present the modularization strategy for ROOT which aims to formalize the description of existing source components, making available the dependencies and other metadata externally from the build system, and allow post-install additions of functionality in the runtime environment. components can then be grouped into packages, installable from external repositories to deliver post-install step of missing packages. This provides a mechanism for the wider software ecosystem to interact with a minimalistic install. Reducing intra-component dependencies improves maintainability and code hygiene. We believe helping maintain the smallest "base install" possible will help embedding use cases. The modularization effort draws inspiration from the Java, Python, and Swift ecosystems. Keeping aligned with the modern C++, this strategy relies on forthcoming features such as C++ modules. We hope formalizing the component layer will provide simpler ROOT installs, improve extensibility, and decrease the complexity of embedding in other ecosystemsComment: 8 pages, 2 figures, 1 listing, CHEP 2018 - 23rd International Conference on Computing in High Energy and Nuclear Physic