Nary Subramanian

Process-oriented metrics for software architecture evolvability

Evolution of software systems is almost a natural process. Evolution can occur at different levels of abstraction of software. Evolution at the architectural level, being the highest level of solution, can often times be the most critical to the success and survival of the pertaining software system. Metrics for software architectural evolvability will help determine the extent to which the architectural evolution can take place. We propose a framework called the POMSAE, process-oriented metrics for software architecture evolvability, that will help not only to intuitively develop architectural evolvability metrics but also to trace the metrics back to the evolvability requirements. This will then help analyze the reasons for the strengths/weaknesses in the metrics. POMSAE is partially validated by demonstrating its application to two practical telecom systems.

Adaptable architecture generation for embedded systems

Architecture generation is the first step in the design of software systems. Many of the qualities that the final software system possesses are usually decided at the architecture development stage itself. Thus, if the final system should be usable, testable, secure, high performance, mobile and adaptable, then these qualities or non-functional requirements (NFRs) should be engineered into the architecture itself. In particular, recently adaptability is emerging as an important attribute required by almost all software systems. Briefly, adaptability is the ability of a software system to accommodate changes in its environment. Embedded systems are usually constrained both in hardware and software. Current adaptable architecture development methods for embedded systems are usually manual and ad hoc--there are almost no comprehensive systematic approaches to consider NFRs at the architecture development stage. While there are several examples of approaches to generate architectures based on functional requirements, we believe that there are very few techniques that consider NFRs such as adaptability during the process of architecture generation. In this paper we present an automated design method that helps develop adaptable architectures for embedded systems by developing a tool called Software Architecture Adaptability Assistant (SA3). SA3 helps the developer during the process of software architecture development by selecting the architectural constituents such as components, connections, patterns, constraints, styles, and rationales that best fit the adaptability requirements for the architecture. The developer can then complete the architecture from the constituents chosen by the tool. SA3 uses the knowledge base properties of the NFR Framework in order to help automatically generate the architectural constituents. The NFR Framework provides a systematic method to consider NFRs, in particular their synergies and conflicts. We validated the architectures generated by SA3 in a type of embedded system called the vocabulary evolution system (VES) by implementing the codes from the generated architectures in the VES and confirming that the resulting system satisfied the requirements for adaptability. A VES responds to external commands through an interface such as ethernet and the vocabulary of these commands changes with time. The validation process also led to the discovery of some of the shortcomings of our automated design method.

Software architecture adaptability: an NFR approach

Adaptation of software systems is almost an inevitable process, due to the change in customer requirements, needs for faster development of new, or maintenance of existing, software systems, etc. No doubt numerous techniques have been developed to deal with adaptation of software systems. In this paper we present an overview of some of these techniques. As the first step in the development of software solution it is our opinion that software architecture should itself be adaptable for the final software system to be adaptable. In order to systematically support adaptation at the architectural level, this paper adapts the NFR (Non-Functional Requirements) Framework and treats software adaptability requirement as a goal to be achieved during development. Through this adaptation, then, consideration of design alternatives, analysis of tradeoffs and rationalization of design decisions are all carried out in relation to the stated goals, and captured in historical records. This NFR approach can also be adapted to a knowledge-based approach for (semi-)automatically generating architectures for adaptable software systems and we also discuss how this can be achieved.

An NFR-Based Framework for Establishing Traceability between Enterprise Architectures and System Architectures

Enterprise architectures (EAs) usually capture the information technology architecture of the organization including hardware, software, and networking standardizations, if any, that serves as the basis for all information systems developed within an organization. Usually EAs are closely aligned to the strategic enterprise plan of the organization. Any information system developed within the organization is derived, on the other hand, from the strategic information systems plan of the organization. The initial stages of developing an information system, after approval by the executive sponsors, include the scope definition, problem analysis and the requirements analysis phases. It is during the requirements analysis phase that the requirements of the new system are elicited from the stakeholders and analyzed - the analysis includes, among other aspects, the development of candidate system architectures (SA) that considers different ways of allocating the requirements between hardware, software and the network. One way of selecting the optimal architecture among the candidate system architectures is to determine the compliance of the architectures with the enterprise architecture. In this paper we provide a framework, called the propagatory framework, for establishing the traceability between SA and the EA that is based on the NFR approach where NFR stands for non-functional requirement. We demonstrate the practicality of the propagatory framework by applying it to determine the traceability of the system architectures for a home appliance control system (MACS)

Goal-Oriented Software Architecting

Designing software architectures to meet both functional and non-functional requirements (FRs and NFRs) is difficult as it oftentimes relies on the skill and experience of the architect, and the resulting architectures are rarely derived directly from the requirements models. As a result, the relationships between the two artifacts are not explicitly captured, making it difficult to reason more precisely whether an architecture indeed meets its requirements, and if yes, why. This chapter presents a goal-oriented software architecting approach, where FRs and NFRs are treated as goals to be achieved, which are refined and used to explore achievement alternatives. The chosen alternatives and the goal model are then used to derive, using the provided mapping rules, a logical architecture, which is further mapped to a final concrete architecture by applying an architectural style and architectural patterns chosen based on the NFRs. The approach has been applied in an empirical study based on the 1992 London ambulance dispatch system.

An approach to ontology-aided performance engineering through NFR framework

In this article we intend to make an attempt to formalize the Software Performance Engineering Body of Knowledge (SPEBoK) by means of the formal semantics of an ontology written in OWL. We do not claim that our SPEBoK is complete nor the information contained correct. Rather we propose the structure of an ontological database to contain it. This structure allows the Performance Engineering issues to be related among themselves and even to other non-functional requirements with which they may interact. Our work uses the NFR Framework.

Architecture-based semantic evolution: a study of remotely controlled embedded systems

Evolution of a software system is a natural process. In many systems evolution occurs during the working phase of their lifecycles. Such systems need to be designed to evolve, i.e., adaptable. Semantically adaptable systems are of particular interest to industry as such systems adapt themselves to environmental change with little or no intervention from their developers. Research in embedded systems is now becoming widespread but developing semantically adaptable embedded systems presents challenges of its own. Embedded systems usually have a restricted hardware configuration, hence techniques developed for other types of systems cannot be directly applied to embedded systems. This paper briefly presents the work done in semantic adaptation of embedded systems, using remotely controlled embedded systems as an application. In this domain, an embedded system is connected to an external controller via a communication link such as ethernet, serial, radio frequency, etc., and receives commands from, and sends responses to, the external controller. Techniques for semantic evolution in this application domain give a glimpse of the complexity involved in tackling the problem of semantic evolution in embedded systems. The techniques developed in this paper were validated by applying them in a real embedded system - a test instrument used for testing cell phones.

Quantitative Assessment of Safety and Security of System Architectures for Cyberphysical Systems Using the NFR Approach

Cyberphysical systems (CPSs) are an integral part of modern societies since most critical infrastructures are controlled by these systems. CPSs incorporate computer-based and network-based technologies for the monitoring and control of physical processes. Two critically important properties of CPSs are safety and security. It is widely accepted that properties such as safety and security should be considered at the system design phase itself, particularly at the architectural level wherein such properties are embedded in the final system. However, safety and security are interrelated, and there seems to be a lack of techniques that consider both of them together. The nonfunctional requirement (NFR) approach is a technique that allows the simultaneous evaluation of both safety and security at the architectural level. In this paper, we apply the NFR approach to quantitatively evaluate the safety and security properties of an example CPS, i.e., an oil pipeline control system. We conclude that the NFR approach provides practical results that can be used by designers and developers to create safe and secure CPSs.

SaViT: Technique for Visualization of Digital Home Safety

Digital homes are expected to be the standard in the near future when all aspects of the home can be monitored and controlled remotely by the home owner. For example, if the home owner is unsure whether she closed the garage door before leaving for work, she can view the status of the garage door on her portable computing device such as laptop, PDA or cell phone, and if the garage door is indeed open, she can close it remotely from the same device. A chief requirement for this eventuality is proper visualization of the status as well as ability to control remotely. Among the more important aspects to be visualized for the digital home is “home safety” which lets the home owner know the current safety level of her home and reasons therefor. Current trends in home safety visualization provide separate interfaces for each device at home: home alarm system has its own web interface different from that provided by a home security camera. Visualizing home safety based on the data from different devices is not only labor and time consuming, but the decision regarding safety also needs to be made by the home owner. Moreover, current systems are bandwidth intensive and require expertise on the part of the home owner for proper usage. We have developed a novel home safety visualization technique called SaViT (Safety Visualization Technique) that not only provides an integrated safety view of the home but also automates safety computation and is extremely easy to use.

System and software architectures

Just about every system has an architecture — be it a computer system, a software system, a social system, a manufacturing system, or even a human body. The architecture of a system essentially is about the parts of the system and the connections between the parts. For example, the parts of a computer (system) include a CPU, a main memory, a disk drive and several input and output devices. These parts are then connected through various serial or parallel ports, cables, memory bus, etc. Taking another example, the parts of a university as a social system include students, professors, courses, classrooms and administrators. These parts are then connected with one another through such interrelationships as students-in-a-course and instructors-of-a-course. There seems to be a reason, of course, for the existence of each and every architecture. The parts of each architecture s em to interact with one another in order to (help) achieve certain goals, which may be only implicit or explicitly stated as such. For example, the parts of a computer system may interact wi h each other to accept commands from the users of the system, execute the commands and produce the desirable outputs. Similarly, the parts of a university may socially interact with each other, perhaps through various workflows, to provide high quality education, produce good research results and serve the community. The type of system of particular concern in this special issue is software systems. A software system is different from other system types in many ways. One important difference lies in the notion of an intended application domain — which itself is a system. A software system is supposed to help the users of the intended application domain system achieve their goals. For this to happen, it would be desirable for the goals of a software system to align with the goals of the users of the intended application domain system. The various services offered by a software system should ultimately help the users of the intended application domain system achieve their goals, by helping them carry out the various tasks individually and also the various interactions with one another: help on the parts and connections among the parts — i.e., help on the architecture of the intended application domain system. In a nutshell, the architecture of a software system should be designed to meet the goals of a software system, which in turn should provide help on sustaining the arc hitecture of the intended application domain system. Building a high quality (software) system, of course, is a critical goal for software developers. Consider the effect of poor quality software – human lives are lost and a huge