Alexander Ran

Design decision trees

The paper proposes a formalism to be used as a systematic approach to incrementally document, refine, organise and reuse the architectural knowledge for software design. The formalism is a hierarchical organisation of design patterns into a design decision tree (DDT) that is a partial ordering of design decisions put in the context of the problem requirements and the constraints imposed by earlier decisions. Our model supports the representation of the essential problems that recur in the domain, knowledge of alternative solutions to these problems and the implications of the solutions. This model integrates architectural knowledge of software design into a software development process.

Configuring designs for reuse

The main problem in developing software product families is how to share effort and reuse parts of design and implementation while providing variation of features and capabilities in the products. We discuss the mechanisms that are commonly used to achieve reuse and sharing in product families, and the kind of variance each is best suited for. Our analysis motivates a need for a new mechanism to deal with ad hoc variation of features found in different members of a family. We argue that higher level abstraction and parametrization techniques are not well suited for this task. We propose an alternative approach that enables sufficiently detailed designs for every variant and at the same time achieves a level of design reuse without making designs unnecessarily complex or implementations inefficient.

Third eye — specification-based analysis of software execution traces (poster session)

In the Third Eye project we have defined a methodology for tracing execution of software by reporting events meaningful in the application domain or essential from the implementation point of view. The implemented portable prototype of the Third Eye framework includes reusable software components for event definition and reporting and stand-alone tools for storage and query of event traces, constraint specification and trace analysis. Third Eye can be used for debugging, monitoring, specification validation, and performance measurements. These scenarios use typed events, a concept simple and yet expressive enough to be shared by product designers and developers. The Third Eye has an open architecture allowing easy replacement of third-party tools, including databases, analysis and validation tools. Third Eye is a practical framework for specification-based analysis and adaptive execution tracing of software systems.

Evolution of Software Product Families

Evolution in software product families is a difficult problem that is not well understood and studied insufficiently. In this article, we present a categorization of product family evolution, a discussion of the implications of architectural evolution and a summary of the discussion during the workshop.

Software isn't built from Lego blocks

Component-based reuse is seen by many software engineers and managers as a promising approach to reduce high costs of building complex sohare. Lego blocks often serve as a metaphor for component-based reuse. Different kinds of blocks from standard block sets can be used for constructing endless variety of structures. Why cannot software be constructed as easily using ready-made, well-designed, carefully implemented, thoroughly tested, and clearly documented components? As far as experience goes reusing non-trivial software components even in a homogenous environment is very hard. 1 believe the main reason for this is that complex software is not built from simple components, like Lego blocks. Complex components depend on other components providing specific functionality; they need to observe system-wide policies for security, flowcontrol, overload control, fault detection and handling; they must rely on infrastructure for communication, coordination, state maintenance, execution tracing, etc. For a project to develop reusable components the context of use must be well understood. The context of use for software components is determined by software architecture. Therefor component-based reuse is only possible as a consequence of architecture-based reuse. If we intend to reuse architectures we need to improve our understanding regarding what it is, how it is created, and how it can be reused. This understanding must be shared by software engineers, product and project managers forming a conceptual framework for understanding complex software a culture in a community

Architectural structures and views

ion, parametrization, configuration, binding, generation, etc. Views

Architecting software with interface objects

One of the main concerns of software architects is managing the complexity that is inherent in the development and evolution of large software by minimising and isolating dependencies between different parts into concise descriptions of their interfaces. Possible grouping, ordering or other relations and constraints between the interface elements themselves or with the intended user appear as informal comments or are left unspecified. We have developed a model for structuring and describing interfaces that is suitable for complex software components. In each interaction domain, we use interface objects for hierarchical groupings of interface elements related to the specific function or role played by the component in its interactions with other components. When components are aggregated into composite components, their interface objects may be aggregated in a similar way into composite interface objects. The state of an interface object allows one to specify the conditional availability of its interface elements. Nonuniform visibility of interface elements to different collaborators may be achieved by alternative groupings of interface elements and by selective visibility of interface objects. Interface objects isolate and open a part of the component implementation that is relevant for understanding the interactions of the component, and they thus serve as precise descriptions of its interfaces. An important principle of our approach was to address these problems without introducing new tools or languages, in order to make the approach immediately useful for software engineers working on product development.

Making sense of runtime architecture for mobile phone software

Making sense of runtime architecture for mobile phone software.

Tracing execution of software for design coverage

Test suites are designed to validate the operation of a system against requirements. One important aspect of a test suite design is to ensure that system operation logic is tested completely. This is a difficult task. Code coverage tools support test suite designers by providing the information about which parts of source code are covered during system execution. Unfortunately, code coverage tools produce only source code coverage information. For a test engineer it is often hard to understand what the noncovered parts of the source code do and how they relate to requirements. We propose a generic approach that provides design coverage of the executed software, simplifying the development of new test suites. We demonstrate our approach on common design abstractions such as statecharts and structure diagrams. We implement the design coverage using tracing and a trace analysis framework. Using design coverage, test suites could be created faster by focussing on untested design elements.

Selected issues in architecture of software intensive products

About two year ago (end of ‘94), after studying the software of several Nokia Telecommunication products we identified a number of problems that, at the time, we traced to a lack of attention to software architecture. From discussions with our colleagues from Philips we learnt that the problems were not Nokia-specific, and together decided to initiate a co-operative research project in the ESPRIT framework. In order to focus the project, we chose to emphasise the role of software architecture in developing families of software-intensive products. In this paper we provide a short summary of what we, at Nokia, have learnt from the industrial case studies during the first phase of the project. We address the role of architecture in software development project and the problems caused by overly concentrating on a single description of software architecture. Since architecture can be represented only through a collection of different descriptions we also believe that a mechanism is needed to manage and relate architectural information. In the case studies we recognised a set of problems caused by the abstraction of interfaces and suggest that further research is needed ‘on structuring interfaces. Architecture is often taken as a static model not addressing the legitimate paths for software evolution. A software designer faced with the task of extending existing software must recognise what are the essential problems to be addressed in her design and what are the constraints imposed by the architecture. We address this by introducing structure into description of recurring problems and creating classification trees to facilitate selection and composition of appropriate design decisions.