Experience of building an architecture-based generator using GenVoca for distributed systems

The generic programming approach is popular in functional languages (for example, OCaml, Haskell). In essence, it is a compile-time generation of code that performs transformations of user-defined data types. The generated code can carry out various kinds of transformations of the values. Usually, transformations are represented as functions that implement algorithms of transformation. New transformations could be built from these transformation functions and user-defined ones. The representation based on functions has a downside: functions behave as final representations, and hence it is not possible to modify the behavior of the already built function. If the current set of transformations does not suit well, software developers are obliged to write a completely distinct transformation, even in the case when the new transformation is almost identical to the existing one. This work proposes to build transformations that are extensible after construction. The object-oriented programming paradigm will be followed, transformations will be represented not as functions but as objects. Instead of calling a transformation function, one of the object’s methods will be called. The transformation itself will be split into methods. The extensibility is supported by adding new methods and overriding existing ones. In this paper, the authors propose an approach to represent transformations as objects in the OCaml functional programming language. Every alternative in data type definition has a corresponding object method. This design allows the construction of many distinct transformations. The cases where too many methods are not desirable are also discussed. The method is applicable to represent extensible transformations for polymorphic variant data types in OCaml when other methods fail to do it. The method is not bound to any particular domain. It allows the creation of extensible transformations in OCaml. It could be ported to other functional languages supporting object-oriented programming.

Non-Functional requirements (NFRs) are overlooked whereas Functional Requirements (FRs) take the center stage in developing agile software. Research has shown that ignoring NFRs can have negative impacts on the software and could potentially cost more to fix at later stages. This research extends the Capture Elicit Prioritize (CEP) methodology to predict NFRs in the early stages agile software development. Research in other fields such as the medical field have shown that historical data can be beneficial in the long run. In the medical field it was found that historical data can be beneficial in determining patient treatments. The Capture Elicit Prioritize (CEP) methodology extended the NERV and NORMAP methodologies in previous research. The CEP methodology identified 56 out of 57 requirement sentences and was successful in eliciting 98.24% of the baseline an improvement of 10.53% of the NORMAP methodology and 1.75% improvement over the NERV methodology. The NFRs count for the CEP methodology was 86 out of 88 NFRs which was an improvement of 12.49% over the NORMAP methodology and 4.55% over the NERV methodology. The CEP was used and utilized the EU eProcument requirements document. The CEP methodology utilized the capture methodology by gathering potential NFRs using OCR from requirements images. The elicit part took the NFR Locator plus and takes sentences from documents and places them in distinct categories. The NFR categories are defined from the Chung's NFR framework utilizing a set of keywords utilized for training to locate NFRs. The e αβγ-framework was utilized to prioritize the NFRs. Utilizing the data from previous research of the CEP methodology and extending the CEP methodology to include a decision tree to predict future NFRs. A simple decision tree was utilized to make a prediction utilizing the past NFRs data. If a certain NFR appears three times or higher in the requirements document. It is most likely that NFRs will appear in the next iteration of the software requirements specification. If the NFRs is equivalent to three times it is likely it will appear in the next iteration. If the NFRs is between one and two it is not likely to appear in future iteration. The path can be traced from the root of the tree to a decision tree's leaf (yes or no) that determines whether the NFRs will appear in future iterations. This research showed that using the data available can be beneficial for the next iteration of software development. This research showed that historical metadata can help in predicting NFRs utilizing a decision tree to make a prediction where NFRs appear multiple times in a set of the EU procurement documents can predict the next iteration of software development. The NFRs Availability, Compliance, Confidentiality, Documentation, Performance, Security, and Usability were found and these NFRs are most likely to appear in the next iteration of the EU procurement software.

Software architecture involves a series of decisions based on many factors in a wide range of software development. Architects face recurring issues in different software architecture design, and to reduce huge cost and risks, software architecture decisions can rely on a set of idiomatic patterns commonly named architectural styles or patterns. Architectural pattern determines the vocabulary of components and connectors that are used in instances of the pattern together with a set of constraints to combine the two. Little contemporary data exists to document actual practices used by software professionals when selecting and incorporating architectural patterns for their projects in industry. Therefore, a comprehensive survey of software professionals was conducted to attempt to discover these practices. This exploratory survey and its quantitative results offer opportunities for further interpretation and comparison. Data from this survey are presented in this paper and include characteristics of projects, practices, organizations, and practitioners related to the usage of architectural patterns. Some of the notable findings include that architectural patterns are widely used in software projects with the Model–View–Controller being the most common. Despite reported difficulties in incorporating architectural patterns, the majority of the software professionals revealed that patterns were the most essential for completing the projects. The most difficult pattern to implement and the most expensive to adopt was the peer-to-peer, while the easiest was the client–server.

This paper shows the application of a generic constraint-based task specification approach for sensor-based robot systems to a laser tracing example. Key properties of the used approach are (i) its ability to specify complex robot tasks by introducing auxiliary task-oriented feature coordinates, defined with respect to user-defined object and feature frames, (ii) its support for both underconstrained and overconstrained robot tasks, and (iii) its ability to integrate sensor measurements in a unified way, using auxiliary uncertainty coordinates, to estimate geometric uncertainties in the robot system or its environment. Simulation and real world experimental results are presented.

The main goal of this study is to apply a scientific quantitative approach to the investigation of contextual fit. This is approached mathematically within the framework of cognitive science and research on categorization and prototypes. Two experiments investigated two leading mathematical-cognitive approaches for explaining people’s judgment of contextual fit of a new building with an architectural/urban context: prototype approach and feature frequency approach. The basic concept is that people represent the built environment via architectural prototypes and/or frequencies of encountered architectural features. In the first experiment, a group of twelve participants performed rank order tasks on artificially created architectural patterns, for the purpose of psychological scaling. Perceptual distances among all patterns were mathematically determined. In the second experiment, three groups of architectural patterns were constructed to represent assumed architectural contexts. The prototype of each context was mathematically determined according to prototype cognitive model, and based on the distances calculated in the first experiment. Fifty-six students participated in the main experiment, in which they rank ordered a group of fifteen architectural patterns in terms of contextual fit to each of the three architectural contexts. Participants’ rank order data of the fifteen patterns were regressed on both the perceptual distances from prototypes, and numbers of features shared with each architectural context. Results indicated that both prototype and feature frequency approaches significantly accounted for important portions of participants’ judgments. However, participants tended to prefer one approach to the other according to context composition. Results have implications for both research on utilizing cognitive-mathematical models in architectural research and on urban design guidelines and control.

Managing non-functional requirements (NFRs) has been a challenge in software development for many years. These requirements are typically used to make important architectural decisions early in the project, which can be problematic if they are uncertain or unstable. When this uncertainty is not considered when designing the software architecture, changes are often costly and sometimes even unfeasible. Some empirical studies on the subject have already been carried out, but few have focused on the perspective of professionals with extensive experience on the changes and uncertainties of NFRs. This work aims to expand the understanding about the management, clarity and validation of NFRs to fill this gap in the literature. To achieve this goal, a survey was carried out with professionals to find out how NFRs were managed and validated. For the research design, instead of generic questions, the questionnaire focused on some specific types of NFRs to induce participants to recall and report concrete situations. As a result, 40 valid responses were obtained, most from professionals with more than 10 years of experience. The results reveal that a significant number of NFRs were defined after the delivery of software increments (more than 30%) and that revision and change occurred in about a third of the NFRs. Hence, this study presents evidence that NFRs, as the functional ones, can also be uncertain and change frequently, requiring agile approaches and techniques to evolve the software architecture to consider this uncertainty.

We present a framework to assemble concurrent applications from modules that capture reusable architectural pat-terns. The framework focuses on concurrent systems where computational processes communicate through asynchronous messages. The language provides support to modularize architectural patterns at different levels of granularity, using agents, regions, aspects and morphing. We present sample implementations of the architectural patterns and show how they are composed using a real-world example. Finally discuss how the deployment and composition of patterns can be further automated.

One of the vexing challenges of software architecture is the problem of satisfying the functional specifications of the system to be created while at the same time meeting its non-functional needs. In this work we focus on the early stages of the software architecture process, when initial high-level system partitioning is being performed. Specifically, we study the problem of system partitioning with respect to both functional requirements and quality attributes. Architecture patterns are particularly well-suited to simultaneously addressing functional requirements and quality attributes. They support architects in considering both, understanding the impact of decisions on other attributes, and making tradeoffs among them. Existing architectural design methods accommodate pattern use, but do not exploit it in detail. We propose a pattern-based approach that leverages the benefits of patterns, and fits well with existing methods.

Requirements Engineering (RE) is the area of softwa re engineering that deals with the discovery and specification of the objectives for the system unde r development and the environment in which it is us ed including the human activities it supports. Require ment Elicitation is process of gathering requiremen ts from stakeholders. Incorporating RE to identify non Functional Requirements (NFR) in early stages of design and implementation avoids ambiguities, confl icting requirement and other defects. The efficacy of the requirement engineering methodology is its abil ity to capture NFR in an efficient manner. In this study, we propose a novel method of elicitation using mobi le multimedia and to automatically trace the NFR. T he requirements description is captured in video using smart phones. Requirement document are prepared using voice to text converter. NFR is detected auto matically from the requirement document and hand gestures emphasise the importance of the requirement. It is observed that the precision and recall of the class ifiers is better using multimedia data. Features were extract ed from video frame and audio using image processing technique and speech processing. We investigated data mining approach to identify Non Functional Requirements (NFR) from Functional Requirement (FR) Documents. Results obtained were satisfactory.

Current architecture review methods predominantly focus on verifying compliance between design and requirements, as well as between code and design. However, they often overlook whether the final product has been adequately tested against architecturally significant requirements and architectural risks. As the software industry evolves, such adaptable models will be crucial for maintaining and enhancing product quality efficiently and cost-effectively, especially considering that widely used maturity models in the industry lack mechanisms for assessing architectural maturity together with testing processes. Recognizing that appropriate testing is a critical component of software architecture processes, this paper proposes an assessment model that incorporates testing into architecture review processes, effectively bridging this gap. Our approach integrates widely used methods, such as the lightweight Architecture Tradeoff Analysis Method (ATAM), into our model to assess architectural quality in an easy and pragmatic manner. By integrating risk-based architectural testing review, this model ensures monitoring and improvement of architectural quality throughout the software development lifecycle, aids in early risk identification and mitigation, and ensures the final product meets high standards of quality in terms of quality attributes and non-functional requirements (NFR).

In web system development, the Non-Functional Requirements (NFRs) are typically considered only briefly during the requirements elicitation stage and not rigorously articulated by either web developers or the client. This paper reports on an investigation into this issue involving interviews with web developers who were engaged in commercial web development projects. The results from this qualitative research highlight that web developers commonly do not pay sufficient attention to NFRs. This arises due to uncertainty, lack of time, lack of knowledge in the importance of NFRs and partly because NFRs are not readily available and documented from previous similar projects. Web developers also do not elicit NFR at the same time and at the same level of details as Functional Requirements (FRs). This study highlights that exploring the domain at an early stage of development will help developers to better understand NFR. A lack of rigour in articulating NFRs may significantly impact on the development effectiveness and the quality of the resulting web system. An evaluation of NFRs may also lead to discovering new FRs.

Over the last years, two new software engineering approaches have been proposed: generative programming and aspect-oriented software development. Generative programming addresses the study and definition of methods and tools that enable the automatic production of system families from a high-level specification. Aspect-oriented software development has been proposed as a technique for improving separation of concerns in the construction of OO software and supporting improved reusability and ease of evolution. The use of aspect-oriented techniques in a definition of a generative approach can bring benefits to the modeling and generation of crosscutting features since early development stages. This paper presents our experience in the definition of an aspect-oriented generative approach. The proposed approach explores the multi-agent systems domain to enable the code generation of agent architectures.

Architectural patterns are a key point in architectural documentation. Regrettably, there is poor support for modeling architectural patterns, because the pattern elements are not directly matched by elements in modeling languages, and, at the same time, patterns support an inherent variability that is hard to model using a single modeling solution. This paper proposes tackling this problem by finding and representing architectural primitives, as the participants in the solutions that patterns convey. In particular, we examine a number of architectural patterns to discover those primitive abstractions that are common among the patterns, and at the same time demonstrate a degree of variability in each pattern. These abstractions belong in the components and connectors architectural view, though more abstractions can be found in other views. We have selected UML 2 as the language for representing these primitive abstractions as extensions of the standard UML elements. The added value of this approach is twofold: it proposes a generic and extensible approach for modeling architectural patterns by means of architectural primitives; it demonstrates an initial set of primitives that participate in several well-known architectural patterns.

Business process modelling is an important part of system design. When designing or redesigning a business process, stakeholders specify, negotiate, and agree on business requirements to be satisfied, including non-functional requirements that concern the quality of the business process. This thesis addresses the question of how to specify and compute the quality of a business process, given the model that stakeholders use. The motivation for this thesis is the increasing importance of the quality of business processes. Knowing the quality of specific business processes enables stakeholders to judge if these processes need improvement. Knowing the quality of the constructs of those processes (viz., events, inputs, activities, and outputs) and the way they are structured enables a more detailed analysis of their shortcomings and provides a basis for the design of improvements. The research challenge of this thesis is grounded in the assumption that: “Organisations need an appropriate means to effectively compute achievement of their goals and objectives by their business processes.” Given this challenge, the main research question on which this thesis focuses is: “Can the quality of a business process be computed quantitatively at different levels of granularity?” The research objective is: “To develop frameworks, factors, and metrics for computing non-functional requirements (quality) of business processes quantitatively at different levels of granularity.” The outcomes of this thesis are: 1) BPIMM, a language-independent business process integrating meta-model, based on the concepts of seven mainstream business process modelling languages: BPMN, EPC, RAD, UML AD, SADT, IDEF0, and IDEF3. 2) BPC-QC (Business Process Concept - Quality Computation), an approach to quality computation at the lowest level of granularity of a business process. The approach consists of: i. BPC-QEF (Business Process Concept - Quality Evaluation Framework), a language-independent generic framework and algorithm to compute the quality of the constructs of a business process: event, input, activity, and output. ii. A set of business process quality dimensions and factors. The following quality dimensions are distinguished: performance, efficiency, reliability, recoverability, permissibility, and availability. Each dimension categorises different quality aspects in terms of factors. A non-exhaustive set of sixteen quantitative factors is provided. iii. Quality metrics for each of the quality factors, to facilitate a quantitative computation of the quality of a specific construct of a business process. 3) BP-QC (Business Process - Quality Computation), an approach to compute the quality at the highest level of granularity of a business process. The approach consists of: i. BP-CQCF (Business Process - Compositional Quality Computation Framework), a language-independent generic framework and algorithm to compute the quality of a business process as a whole, given the quality of its constructs. ii. A set of generic business process modelling patterns to decompose a business process into more succinct parts, namely: sequential, parallel with synchronisation, exclusive, inclusive, simple loop, and complex loop. iii. A set of over one hundred computational formulae. For each combination of modelling pattern and a quality factor, there is a formula to compute the quality. 4) AAV (Approach to Application and Validation), an evaluation plan to evaluate BPIMM, BPC-QC and BP-QC in practice, together with expert stakeholders. The plan consists of the units of measure, a measurement model, and a case study procedure. To evaluate the applicability of the contributions of this thesis to real world business needs, four case studies have been conducted in different environments: a Dutch educational institution, a global financial institution, an international financial service provider, and a Dutch research project on crisis management. Each of these case studies concerns a different, single business process. This thesis shows that: 1) A quality computation approach can be adopted independent of a business process modelling language. 2) Quantitative quality factors can be introduced specifically for the constructs of a business process. 3) Quantitative metrics and computational formulae can be developed for specific quality factors, allowing the computation of different aspects of the quality of a business process quantitatively at different levels of granularity. 4) An evaluation plan can be developed to evaluate the applicability of the contributions of this thesis (viz., BPIMM, BPC-QC, and BP-QC). The contributions of this thesis are designed to be beneficial to the areas of business and management, requirements engineering, software engineering, and business process modelling. In the areas of requirements engineering and software engineering, these contributions are intended to help practitioners to consider non-functional requirements at the earliest stage. In the area of business process modelling, information systems, service computing, and cloud computing, the contributions can be used for quality-driven modelling, design, and redesign. To conclude, knowing the quality value of a business process at different levels of granularity provides a basis for its improvement.

This paper addresses the problem of supporting usability in the early stages of a product line architecture design. The product line used as an example is intended to support a variety of different products each with a radically different user interface. The development cycles for new products varies between three years and five years and usability is valued as an important quality attribute for each product in the line.Traditionally, usability is achieved in a product by designing according to specific usability guidelines, and then performing user tests. User interface design can be performed separately from software architecture design and prototyping, but user tests cannot be performed before detailed UI design and prototyping. If the user tests discover usability problems leading to required architectural changes, the company would not know about this until two years after the architecture design was complete. This problem was addressed by identifying a collection of 19 well known usability scenarios that require architectural support. In our example, the stakeholders for the product line prioritized three of these scenarios as key product-line scenarios for improving usability. For each of these three chosen product-line scenarios we developed an architectural responsibility pattern that provided support for the scenario. The responsibilities are expressed in terms of architectural requirements with implementation details and rationales. The responsibilities were embodied in a web based tool for the architects.The two architects for the product line developed a preliminary design and then reviewed their design against the responsibilities supporting the scenarios. The process of review took a day and the architects conservatively estimated that it saved them five weeks of effort later in the project.