Showing papers on "View model published in 2002"

Combining static and dynamic views for architecture reconstruction

Abstract: Static analysis aims at recovering the structure of a software system, while dynamic analysis focuses on its run time behaviour. We propose a technique for combining the analysis of static and dynamic architectural information to support the task of architecture reconstruction. The approach emphasises the correct choice of architecturally significant concepts for the reconstruction process and relies on abstraction techniques for their manipulation. The technique allows the software architect to create a set of architectural views valuable for the architecture description of the system. To support our technique, we outline an environment that relies on hierarchical typed directed graphs to show the system's structure and message sequence charts for its behaviour. The main features of the environment are: visualisation of static and dynamic views, synchronisation of abstractions performed on the views, scripting support and management of the use cases. The approach and the environment are demonstrated with an example.

On Architectural Stability and Evolution

Abstract: Many organizations are now pursuing software architecture as a way to control their software development and evolution costs and challenges. A software architecture describes a system's structure and global properties and thus determines not only how the system should be constructed but also guides its evolution. An important challenge is to able to evaluate the "goodness" of a proposed architechture. I suggest stability or resilience as a primary criterion for evaluating an architecture. The stability of an architecture is a measure of how well it accomodates the evolution of the system without requiring changes to th architecture. As opposed to traditional predictive approaches to architecture evalution, I suggest retrospective analysis for evaluating architectural stability by examining the amount of change applied in successive releases of a software product. I review the results of a case study of twenty releases of a telecommunication software system containing a few million lines of code to show how retrospective analysis may be performed.

Integrating hundred's of products through one architecture - the industrial IT architecture

Abstract: During the last few years, software product line engineering has gained significant interest as a way for creating software products faster and cheaper. But what architecture is needed to integrate huge amounts of products, from different product lines? This paper describes such an architecture and its support processes and tools. Through cases, it is illustrated how the architecture is used to integrate new --- and old --- products in such diverse integration projects as vessel motion control, airport baggage handling systems, pulp&paper and oil&gas, in a very large organization. However, in a large organization it is a challenge to make everyone follow an architecture. Steps taken to ensure global architectural consistency are presented. It is concluded that a single architecture can be used to unify development in a huge organization, where the distributed development practices otherwise may prohibit integration of various products.

Systematic Integration of Variability into Product Line Architecture Design

Abstract: Product lines consider related products, their commonalities and their differences. The differences between the single products are also referred to as variability. Consequently, variability is inherent in every product line and makes a key difference as compared to single systems. While, on the requirements level, the methods for analyzing product line variability are understood today, their transition to architecture remains vague. Bringing variability to architecture as an "add-on" is just a provisional solution and forebodes the risk of violating other intentions. This paper presents a systematic approach to integrate variability with product line architecture design. In particular, it promotes variability as an architectural driver, embeds variability requirements in the architecture design framework "Quality-Driven Software Architecting" (QUASAR), and gives guidelines and examples for documenting variability in architectural views.

Software Architecture Reconstruction: Practice Needs and Current Approaches

Abstract: : Software architectures serve as the blueprints for systems, and they are central to the development of software product lines and the design of component-based systems. In existing systems, the architecture often must be reconstructed to reflect the as-built system accurately. This report presents the concept of practice scenarios for architecture reconstruction, which outline common problem/solution pairs that can be used in the strategic application of architecture reconstruction at Department of Defense (DoD) and commercial organizations. Based on an investigation of already developed and presented reconstruction approaches, the report describes deficiencies that have been uncovered in several practice scenarios and proposes improvements.

Four metaphors of architecture in software organizations: finding out the meaning of architecture in practice

Abstract: Current literature, research, and practice provide ambiguous meanings for the concept of architecture in the context of software and systems development. This qualitative and grounded theory based study delves into the practice of architecture design and description in three software-producing organizations. Nineteen architects, designers, and managers are interviewed and the general meanings of architecture in practical real-life situations are distilled and analyzed The ambiguity of the concept of architecture receives its explanation. Architecture emerges as a plastic concept including diverging and simultaneous connotations for different stakeholders. The research process produces four general metaphors for architecture, "architecture as blueprint", "architecture as literature", "architecture as language", and "architecture as decision". These metaphors and the research process are presented and discussed in detail.

Less is more with minimalist architecture

Abstract: Architecture and governance bring an element of control that can rub people the wrong way. Architectural decisions should be focused where the payoff is highest to maximize the likelihood of success. The minimalist approach to architecture involves sorting out the highest-priority architectural requirements, and then doing the least you possibly can to achieve them! That is, keep the architecture decision set as small as possible, while ensuring that the technical staff meets key system priorities.

Maintaining software through intentional source-code views

Abstract: Maintaining the source code of large software systems is hard. One underlying cause is that existing modularisation mechanisms are inadequate to handle crosscutting concerns. We propose intentional source-code views as an intuitive and lightweight means of modelling such concerns. They increase our ability to understand, modularise and browse the source code by grouping together source-code entities that address the same concern. They facilitate software development and evolution, because alternative descriptions of the same intentional view can be checked for consistency and relations among intentional views can be defined and verified. Finally, they enable us to specify knowledge developers have about source code that is not captured by traditional program documentation mechanisms.Our intentional view model is implemented in a logic metaprogramming language that can reason about and manipulate object-oriented source code directly. The proposed model has been validated on the evolution of a medium-sized object-oriented application in Smalltalk, and a prototype tool has been implemented.

A system of systems focused enterprise architecture framework and an associated architecture development process

Abstract: Today, many organizations are concerned with how to successfully transition to an organization utilizing information technology to its fullest strategic extent. The organization's enterprise architecture plays a key role in this transition. Enterprise architectures are typically comprised of many components and can be very complex. All of these components must be integrated well for the organization to easily evolve and successfully adapt to the frequent technology and business changes that occur. An Enterprise Architecture Framework (EAF) can significantly aid development of an adaptable enterprise architecture. When developing an enterprise architecture, the major areas of focus should be stakeholders' perspectives, contextual awareness interrogatives by which these perspectives are expressed, and System of Systems (SOS) hierarchical levels. This research has led to the identification of an enterprise architectural framework for a complex system of systems. It identifies an enterprise architecture framework and an Architecture Development Process (ADP) to engineer an effective, flexible enterprise architecture. The resulting three-dimensional enterprise architecture framework incorporates hierarchical levels of the system of systems that characterize the enterprise as well as the perspectives of all stakeholders, including such external ones as customers and partners, and contextual awareness interrogatives. The resultant enterprise architecture framework explicitly addresses the complexity of systems and the high degree of integration needed across system of systems levels. Measures of effectiveness for the enterprise architecture framework, architecture development process, and the resulting architecture are briefly discussed as well as an empirical evaluation. The results of the evaluation suggest that use of both the framework and the architecture development process are beneficial.

Making architecture reviews work in the real world

Abstract: This article explores the nontechnical aspects of formal architecture reviews-social, psychological, and managerial. Architecture reviews differ from other technical reviews because of their close relationship to a system's business goals, so they need to be approached differently. The authors draw lessons from their experiences in reviewing and evaluating software and system architectures in a wide variety of application domains. They discuss the issues architects face when running such reviews, common pitfalls to avoid, and ways of increasing an organization's chances of a successful review.

A Family of Software Architecture Implementation Frameworks

Abstract: Software architectures provide high-level abstractions for representing the structure, behavior, and key properties of software systems Various architecture description languages, styles, tools, and technologies have emerged over the past decade At the same time, there has been comparatively little focus on techniques and technologies for transforming architectural models into running systems This often results in significant differences between conceptual and concrete architectures, rendering system evolution and maintenance difficult Furthermore, it calls into question the ability of developers to consistently transfer the key architectural properties into system implementations One solution to this problem is to employ architectural frameworks Architectural frameworks provide support for implementing, deploying, executing, and evolving software architectures This paper describes the design of and our experience with a family of architectural frameworks that support implementation of systems in a specific architectural style-C2 To date, the C2 frameworks have been used in the development of over 100 applications by several academic and industrial organizations The paper discusses the issues we have encountered in implementing and using the frameworks, as well as the approaches adopted to resolve these issues

Development and attributes of z/Architecture

Abstract: The IBM z/Architecture™ instruction set architecture (ISA) is an extension of the IBM Enterprise Systems Architecture/390® (ESA/390) ISA and features 64-bit general registers, 64-bit operations, and 64-bit virtual and real addressing. In addition, z/Architecture includes new instructions to optimize the handling of modern multi-byte character encodings and to improve the performance of programs written in high-level languages. It provides compatibility for ESA/390 application programs and increases the ease of development of new application programs. This paper presents an overview of the interesting aspects of z/Architecture and some of the associated decisions and tradeoffs made in its development.

Describing and Communicating Software Architecture in Practice: Observations on Stakeholders and Rationale

Abstract: Despite considerable attention paid on software architecture, the organizational aspects of architecture design remain largely unexplored. This study analyses the stakeholders participating in architecture design in three software companies, their problems in relation to architecture, and the rationale for architecture description they emphasize. This qualitative, grounded-theory-based, study shows how the stakeholders' rationales for describing architecture exceed the plain programming-in-the-large metaphor, emphasizing such issues as organizational communication, and knowledge creation and management. Whereas designers alone highlighted architecture as the basis for further design and implementation, the other stakeholders emphasized architecture mostly as a means for communication, interpretation, and decision-making. The results suggest a need for further research on practices and tools for effective communication and collaboration among the varying stakeholders of the architecture design process.

On the design of a new CPU architecture for pedagogical purposes

Abstract: Ant-32 is a new processor architecture designed specifically to address the pedagogical needs of teaching many subjects, including assembly language programming, machine architecture, compilers, operating systems, and VLSI design. This paper discusses our motivation for creating Ant-32 and the philosophy we used to guide our design decisions and gives a high-level description of the resulting design.

Classifying and evaluating architecture design methods

Abstract: The concept of software architecture has gained a wide popularity and is generally considered to play a fundamental role in coping with the inherent difficulties of the development of large-scale and complex software systems. This chapter provides a classification and evaluation of existing software architecture design methods. For this, contemporary definitions on software architectures are analyzed and a general definition of software architecture is introduced. Further, a meta-model for architecture design methods is presented, which is used as a basis for comparing various architecture design approaches. The problems of each architecture design method are described and the corresponding conclusions are given.

Enterprise frameworks: issues and research directions

Abstract: Enterprise frameworks are a special class of application frameworks. They are distinguished from other application frameworks in terms of scale and focus. In terms of focus, application frameworks typically cover one particular aspect of an application, either a domain-dependent aspect (e.g., billing in a web-based customer-to-business ordering system), or a computational infrastructure aspect such as distribution, man-machine interface, or persistence, etc. Generally, an application framework alone delivers no useful end-user function. With infrastructure frameworks, we still have to plug in domain functionalities, while with domain frameworks, we need to set-up the infrastructure. In contrast, enterprise frameworks embody a reference architecture for an entire application, covering both the infrastructure aspects of the application, and much of the domain-specific functionality. Instantiating an enterprise framework is nothing short of application engineering, where the architecture and many of the components are reusable. While creativity and continual improvement may be the major ingredients for building a good application framework, anything related to enterprise frameworks, be it building, documenting, or instantiating them, is complex and requires careful design and planning. In this paper, we identify the issues involved in building, using, and maintaining enterprise frameworks, both from research and practical perspective.

Architecture Reconstruction Guidelines, 2nd Edition

Abstract: : Architecture reconstruction is the process of obtaining the "as-built" architecture of an implemented system from the existing legacy system. For this process, tools are used to extract information about the system that will assist in building successive levels of abstraction. Although generating a useful representation is not always possible, a successful reconstruction results in an architectural representation that aids in reasoning about the system. This recovered representation is most often used as a basis for redocumenting the architecture of an existing system if the documentation is out of date or nonexistent, and can be used to check the "as-built" architecture against the "as-designed" architecture. The architectural representation can also be used as a starting point for reengineering the system to a new desired architecture. Finally, the representation can be used to help identify components for reuse or to help establish a software product line. This report describes the process of architecture reconstruction using the Architecture Reconstruction and Mining (ARMIN) tool developed by the Carnegie Mellon(registered) Software Engineering Institute and the Robert Bosch Corporation. Guidelines are presented for reconstructing the architectural representations of existing systems. Most of these guidelines are not specific to ARMIN, can be used with other tools, and are useful even if the architecture reconstruction is carried out manually.

An approach to software architecture evaluation with the 4+1 view model of architecture

Abstract: Architectural evaluation to determine a software architecture's fitness with respect to its desired quality attributes is one of the most important issues in architecture-based software development. However, existing techniques have too many limitations for widespread application, such as the inappropriate representation of architecture and ambiguities in the evaluation process. Therefore, this paper presents an approach to evaluate software architecture with a 4+1 view model in UML. Our approach is divided into three main areas of activity: the work involved in preparation, execution, and completion of the evaluation. By performing these activities, architecture evaluation can be explicitly described and its result can be systematically organized based on the 4+1 view model. In addition, we show the practical applicability and features of our approach via an ATM example.

Requirements specification and architecture design for Internet-based control systems

Abstract: The Internet is playing an important role not only in information retrieval, but also in industrial process manipulation. This paper describes an approach to writing requirements specifications for Internet-based control systems and to deriving architecture for this new type of control system according to the requirements specification. Specification is described in terms of a functional model and then extended into information architecture. In contrast to the functional model, the information architecture gives an indication to the architecture of the Internet-based control systems. An integrated-distributed architecture has been derived from the functional model and the information architecture as a case study.

Causal architecture: Bringing the Zachman framework to life

Abstract: This article describes how Causal Architecture (CA) can be used to identify and create content for the most relevant Zachman Framework cells, as well as how Ptech's Enterprise FrameWork solution can be used to interrelate the cells within the Zachman Framework. Two recent examples of the Causal Architecture implementation are also illustrated. Enterprise Architecture (EA): An Enterprise Architecture is a set of aligned business and IT models of an enterprise, as well as the key aspects of the governing processes needed to keep these models applied and in a usable format. Zachman Framework (ZF): the Zachman Framework is a classification model developed by John Zachman to assist in the development and management of comprehensive and aligned Enterprise Architecture models.

FORMAware: framework of reflective components for managing architecture adaptation

Abstract: Software engineers use abstraction to better understand, model and reason about the surrounding world. Recently Architecture Description Languages (ADLs) introduced new levels of abstraction with potential use at run-time to support system evolution. In this paper we propose the FORMAware architecture that blends run-time architectural representation with a reflective programming model to address adaptation issues and promote the proximity between design and development. Reflection opens up composition architecture through a replaceable default style manager that permits to execute architecture reconfigurations. This manager enforces the structural integrity of the architecture through a set of style rules that developers may change to meet other architectural strategies. Each reconfiguration runs in the scope of a transaction that we may commit or rollback.

Quality driven multimode DSP software architecture development

Abstract: Traditionally, DSP software development has concentrated on optimising the algorithms. The future wireless communication systems create challenges to the DSP software. In order to handle the new requirements, more emphasis has been placed on software architecture. This thesis examines the way quality driven architecture development can be applied to multimode DSP software. First, the main quality attributes for DSP software are defined. Performance ensures that the timing requirements are fulfilled, with simultaneously minimising the resource usage. Cost attribute ensures that the development of the system is affordable. Variability is for evaluating how well the architecture can adapt to changes that are required to the system during its lifetime. It is proposed that the DSP software architecture should be described with four architectural views. A logical view shows the required functionality in an implementation independent way; a physical view depicts the deployment of logical components to the hardware architecture and the interfaces that are relevant to the software; a process view is used for understanding the runtime functionality of the system; a development view describes how the system is actually implemented with today’s software platforms and technologies. The process of developing the architectural views is iterative and incremental. More details are added to the diagrams when the development continues. View development is a series of iterations between refinement of architectural structures and evaluation of the decisions made. An evaluation strategy is presented for comparing architectural decisions against quality requirements. The results are validated with a case study of a future multimedia terminal that supports three systems: GSM, WLAN, and WCDMA. It is shown that the quality-driven development clarifies the design decisions so that it is easier to compare and refine architecture candidates.

Bridging the gap between IEEE 1471, an architecture description language, and UML

Abstract: A lot of attention has been paid to software architecture issues in academia, industrial research and standardization organizations working in the software area. The software architecture research community has focused on the creation and improvement of special-purpose languages: architecture description languages (ADLs). However, ADLs lack adequate support for separating various kinds of stakeholders’ concerns along different viewpoints. But also, they do not address the difference between the architecture of a software system and its representations. In contrast, ANSI/IEEE-Std-1471 makes a clear distinction between the architecture and the architectural description of a software system.

On the definition of a framework for an architecting process supporting product family development

Abstract: Product families are an important system development paradigm that can yield significant improvements in time-to-market, cost reduction, and quality. In order to gain such improvements, a product family must be built based on a common architecture. The architecture is a key artifact of the development process because all product family members make use of it. However, not all requirements on designing such architectures have been addressed in depth within current research. This paper presents QUASAR, a process framework that supports the design of high-quality product family architectures. QUASAR deals with early architectural considerations, guides the modelling of architectural views and variability, and documents how to evaluate the achievement of architectural qualities. The paper describes fundamental concepts, activities, and benefits of the QUASAR framework.

Fast Tracking ICT Infrastructure Requirements and Design, Based on Enterprise Reference Architecture and Matching Reference Models

Abstract: The Globemen Consortium has developed the virtual enterprise reference architecture and methodology (VERAM), based on GERAM and developed reference models for virtual enterprise management and joint mission delivery. The planned virtual enterprise capability includes the areas of sales and marketing, global engineering, and customer relationship management. The reference models are the basis for the development of ICT infrastructure requirements. These in turn can be used for ICT infrastructure specification (sometimes referred to as ‘ICT architecture’).Part of the ICT architecture is industry-wide, part of it is industry-specific and a part is specific to the domains of the joint activity that characterises the given Virtual Enterprise Network at hand. The article advocates a step by step approach to building virtual enterprise capability.

Software architecture recovery and modelling: [WCRE 2001 discussion forum report]

Abstract: This paper covers current trends and issues in software architecture recovery. It consists of a summary of the presentations and discussions of the Software Architecture Recovery and Modelling discussion forum held during WCRE 2001, the Working Conference on Reverse Engineering, Stuttgart, Germany, October 2, 2001.

Technological innovation in architecture : effective practices for energy efficient implementation

Abstract: The objective of this research is to simultaneously address the environmental concerns in building design and the urgency in the architectural, engineering, and construction industry (AEC) to advance technologically by providing specific responses to the following questions. What are the barriers that a design team faces when introducing environmental strategies and innovations into building projects? What are the mechanisms that can assist design teams to surpass industry standards or even break away from the limits of their own professional training? Ultimately, what is required to successfully implement environmentally sound and technologically innovative solutions in buildings? In order to gain a better insight into these issues, this research examines eight case studies and reconstructs their respective patterns of practices to discover how and why certain AEC teams successfully overcome design, development, and implementation barriers relating to energy efficient innovation (EEl) while most do not. The results of the study are categorized into four distinct, but related, components: (1) implementation techniques, (2) basic team attributes, (3) critical success factors, and (4) the implementation process. Contrary to popular belief, the findings suggest that technological innovation, specifically EEl, is best fostered by team members with prior work experience with each other, as opposed to an assembly of individuals selected solely on the basis of expertise. The repeated collaborations serve multiple functions: technical-risk reduction, financial security, and psychological assurance. In addition, six key factors of EEI implementation are isolated and organized into two groups: team dynamics and project logistics. Team dynamics encompasses concurrent collaboration, team relational competence, and commitment to environmental goals. Project logistics encompasses external funding; research collaboration; and technical evaluation, demonstration, and validation. A strong relationship was found between the integrated design process and the commitment to EEl. Specifically, contributors of EEI worked in parallel with an expedient feedback loop or explicit feedback period. Interestingly, financial contributions external to the clients' allocated budgets were consistently found and often related to the particular research of at least one member within the team. The direct relationship between research and the resultant innovation suggests that technological innovation is not random, but rather predictable and specific to team members' areas of expertise. Thesis Supervisor: William L. Porter, Norman B. and Muriel Leventhal Professor of Architecture and Planning Thesis Supervisor: Andrew M. Scott, Associate Professor of Architecture