Distribution pattern-driven development of service architectures

Distributed systems are being constructed by composing a number of discrete components. This practice is particularly prevalent within the Web service domain in the form of service process orchestration and choreography. Often, enterprise systems are built from many existing discrete applications such as legacy applications exposed using Web service interfaces. There are a number of architectural configurations or distribution patterns, which express how a composed system is to be deployed in a distributed environment. However, the amount of code required to realise these distribution patterns is considerable. In this paper, we propose a distribution pattern-driven approach to service composition and architecting. We develop, based on a catalog of patterns, a UML-compliant framework, which takes existing Web service interfaces as its input and generates executable Web service compositions based on a distribution pattern chosen by the software architect

How do software architects consider non-functional requirements: an exploratory study

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.Peer ReviewedPostprint (author’s final draft

Semi-automatic distribution pattern modeling of web service compositions using semantics

Enterprise systems are frequently built by combining a number of discrete Web services together, a process termed composition. There are a number of architectural configurations or distribution patterns, which express how a composed system is to be deployed. Previously, we presented a Model Driven Architecture using UML 2.0, which took existing service interfaces as its input and generated an executable Web service composition, guided by a distribution pattern model. In this paper, we propose using Web service semantic descriptions in addition to Web service interfaces, to assist in the semi-automatic generation of the distribution pattern model. Web services described using semantic languages, such as OWL-S, can be automatically assessed for compatibility and their input and output messages can be mapped to each other

Designing and Documenting the Behavior of Software

The development and maintenance of today's software systems is an increasingly effort-consuming and error-prone task. A major cause of this problem is the lack of formal and human-readable documentation of software design. In practice, software design is often informally documented (e.g. texts in a natural language, `boxes-and-arrows' diagrams without well-defined syntax and semantics, etc.), or not documented at all. Therefore, the design cannot be properly communicated between software engineers, it cannot be formally analyzed, and the conformance of an implementation to the design cannot be formally verified.\ud \ud In this chapter, we address this problem for the design and documentation of the behavior implemented in procedural programs. We introduce a solution that consists of three components: The first component is a graphical language called VisuaL, which enables engineers to specify constraints on the possible sequences of function calls from a given program. Since the specifications may be inconsistent with each other, the second component of our solution is a tool called CheckDesign, which automatically\ud verifies the consistency between multiple specifications written in VisuaL. The third component is a tool called CheckSource, which automatically verifies that a given implementation conforms to the corresponding specifications written in VisuaL.\ud \ud This solution has been evaluated empirically through controlled experiments with 71 participants: 23 professional developers of ASML, and 49 Computer Science M.Sc. students. These experiments showed that, with statistical significance of 0.01, the solution reduced the effort of typical maintenance tasks by 75% and\ud prevented one error per 140 lines of source code

Development of Variant of Software Architecture Implementation for Low-power General Purpose Microcontrollers by Finite State Machines

As a result of the research, two directions for development of software architecture for low-power general purpose microcontrollers (LPGPM) are identified. The first, classical approach is the development using standard State patterns. The second is the development of programs, algorithms and structures based on mathematical analysis.The first direction is chosen in the work. The variant of the implementation of a typical pattern for development of software architecture (SA) in the form of a finite state machine (FSM) is proposed to discussion. This pattern allows to divide the development of the architectural part of the program for LPGPM and programming the LPGPM hardware. This approach makes it possible to divide the work of the software architect and the work of LPGPM hardware specialists. Advantage of the solution in comparison with the real time operating system (RTOS) is the saving of LPGPM hardware resources. In addition, it improves the readability of code and good testing prospects. The resulting architecture makes it possible to easily accompany the software and switch to other types of microcontroller. The disadvantage is an increase in the required amount of RAM with an increase in the number of states. It is this disadvantage that requires the application not only of experimental and engineering-intuitive methods, but also to continue research in the second direction

An initial performance review of software components for a heterogeneous computing platform

The design of embedded systems is a complex activity that involves a lot of decisions. With high performance demands of present day usage scenarios and software, they often involve energy hungry state-of-the-art computing units. While focusing on power consumption of computing units, the physical properties of software are often ignored. Recently, there has been a growing interest to quantify and model the physical footprint of software (e.g. consumed power, generated heat, execution time, etc.), and a component based approach facilitates methods for describing such properties. Based on these, software architects can make energy-efficient software design solutions. This paper presents power consumption and execution time profiling of a component software that can be allocated on heterogeneous computing units (CPU, GPU, FPGA) of a tracked robot

Pattern-based software architecture for service-oriented software systems

Service-oriented architecture is a recent conceptual framework for service-oriented software platforms. Architectures are of great importance for the evolution of software systems. We present a modelling and transformation technique for service-centric distributed software systems. Architectural configurations, expressed through hierarchical architectural patterns, form the core of a specification and transformation technique. Patterns on different levels of abstraction form transformation invariants that structure and constrain the transformation process. We explore the role that patterns can play in architecture transformations in terms of functional properties, but also non-functional quality aspects