concerns on architecture-centered software development - IOS Press

2000 Society for Design and Process Science Printed in the United States of America

CONCERNS ON ARCHITECTURE-CENTERED SOFTWARE DEVELOPMENT: A SURVEY

John J. Kyaruzi Jan van Katwijk Faculty of Information Technology and Systems, University of Technology, Delft, The Netherlands

We propose a framework for practical realization of architecture-centered software development that consolidates two major view-points in the domain of software architecture: (1) an architecture-based systems development view which requires development processes and products to respect good architecting principles and (2) a system-based architecture technology development view which requires software architecture methods and technologies to respect evolution, reuse and componentization as, inherently, basic properties of software systems. We survey and discuss the use of software architecture technologies in solving problems of evolution, reuse, and componentization as inherent characteristics of any complex systems. Issues of concern for adopting architecture-centered software development are then discussed together with problems facing current ADLs, as technologies for software architectures. We propose possible research directions necessary for practical realization of the framework. Key Words: Architecture-centered software development, software architecture, software reuse, component-based software development, software evolution, software architecture ontology.

1. Introduction 1.1. Our Research Recent literature attributes the success of the development of many large and complex systems, such as (computer systems embedded in) fighter planes, cellular mobile systems, and payment systems, to well-chosen architectures as central element in their design [Rechtin92]. Current research typically addresses methods and technologies for software architecture tailored to coordinate evolution-, reuseand component-based software development. Despite promising results in this field of research, the

Transactions of the SDPS

SEPTEMBER 2000, Vol. 4, No. 3, pp.13-35

development of complex systems is still a high-risk human-intensive venture, as the methods are still immature and often not effectively employed and no consistent picture of the field of architecturecentered software development exists. Our long-term research goals are concerned with the development of a software development environment in which the notion of “architecture” is not only acknowledged as integrated element, but also helps to recognize and manage “reuse”, “componentization” and “evolution” as basic inherent properties of complex systems. Justification of the research is found in consolidating results from the conducted literature survey (related to software architecture), with experience gained from our participation in the development of the National Payment System (NPS) in Tanzania: it soon became apparent that no integrated models for architecture-centered software development were available. 1.2. Claims of Architecture-Centered Development We define Architecture-Centered Software Development (ACSD) as a development practice that advocates the application of good and sound architecturing principles, techniques and technologies to derive the entire software development life cycle. In particular, ACSD seeks to identify, apply and reinforce good architecture methods and technologies that provide a unified solution for evolution, reuse and componentization in a single framework. In our view, architecture-centered software development forces both the technologies for software architecture, on one hand, and the industrial software development practices, on the other hand, to equally respect and harmonize each other’s concerns (Fig. 1). The two major issues are: 1. architecture technology development should be system-based - i.e. software architecture methods and technologies should address recurring problems of complex software systems viz. evolution, reuse and componentization problems. Currently, the place of ACSD is not universally agreed upon based on the diverse approaches that are taken by ACSD technologies. It is not clear whether industrial problems are optimally addressed by ACSD technologies or whether these industrial problems (i.e. evolution, reuse and componentization) are legitimate issues for ACSD technologies at all. A legitimate survey question then is “what are the opportunities for applying architecture-centered software development to the industry?” 2. systems development should be architecture-based - i.e. industrial practices (i.e. processes and products) should explicitly acknowledge and respect good architectural principles[CN96]. Currently, appropriate methods and technologies for architecturing still have little acceptance and application in industries. Even when they are adopted, they have varying degrees of usefulness and applicability. Applying these technologies therefore comes with their own challenges. A legitimate survey question then is “what are the challenges in adopting architecture-centered software development?” 1.3. Rationale for Our Work The topic of software architecture has been the subject of many survey-like papers and books already. Typical surveys include: ? Clements and Northrop [CN96] who give a good framework for the use of software architecture but fail to address support for componentization and evolution. ? Rowe et. al. [RLL96] provide a good framework for understanding software architecture and evolution with minimal mention on reuse and componentization. They also fail to point out challenges for adopting the framework in industrial environment. ? Dusink and Katwijk [DK95] give a good introduction on reuse but fail to show how reuse relates to architecture or evolution. Furthermore, do not give attention to industrial application.

Journal of Integrated Design and Process Science

SEPTEMBER 2000, Vol. 4, No. 3, 14

Brown [BW96] gives a framework for component-based software development but again falls short of providing challenges for its adoption. Each of these surveys covers a rather limited domain by describing isolated perspectives, hence missing the underlying unifying model. As a result most of the recommendations that result from these surveys are of academic interest only. Our survey is based on our recommended architecture-centered software development framework (presented in section 1.2) that best suits industrial acceptance and application. We use the framework for understanding architecture-centered software development to show the coverage of various problem areas of software architecture by documented research. With the views expressed in section 1.2 as a starting point, claims of architecture-centered software development can be validated through: ?

1. Looking at software architecture as a concept for bringing complex systems under engineering control. 2. Looking at software architecture as a tool for managing the evolution, reuse and componentization as inherent properties of complex systems. 3. Looking at issues of concern in taking an architecture-centered software development approach. For each of the above points, we traced the literature and were also able to pinpoint problematic research areas that needs further attention in this regard. This survey shows white spots that are believed to be obstacles for a successful architecture-centered software development, and which need to be addressed in future research. In section 2 we revisit the current perspectives and understanding of the term “software architecture” as an engineering tool to complex systems. In section 3 we explore the terms “evolution”, “reuse” and “componentization” respectively, as basic inherent properties of complex systems, highlighting the rationale for architecture as a better way to fulfil their expectations. In section 4 we highlight the challenges in adopting architecture-centered software development and in section 5 we list research prospects associated with current technologies and suggests further research directions.

Industrial Software Development Practices require consolidation

Evolution

and management of

Componentizati

Enforces an ArchitectureBased Software Development Practices

Reuse

ARCHITECTURE-CENTERED SOFTWARE Methods

Tools provide Software Architecture Technologies

Processes

Enforces a System-Based Software Technology Development Practices

Fig. 1 The Architecture-Centered Software Development Framework.



2. Software Architecture Is An Engineering Tool Software architecture is a young, growing but relatively immature field of research. There is little consensus on terminology, representation and even methodology. Even though the term may be interpreted and defined in many different ways, its underlying essence is the same: ? Implicitly, every system has an architecture, so its explicit acknowledgement simplifies the management of these complex systems [WBST97].

A direct benefit from this acknowledgment is to use architecture as an engineering tool (viz. capturing, representation, control and management of various aspects of software system during its development). This section discusses this issue in more detail. 2.1. What is Software Architecture Although there is no a single universally accepted definition, there is no shortage of proposed ones either. Looking at a number of definitions in literature (e.g. [IEEE90,TAFIM95, GACB95, SZ92]), we found that most of them are was not useable to us. As an example, consider the IEEE 610.12-1990 standard definition of software architecture, defining ‘architecture’ as: “The organizational structure of a system or component”[IEEE90]. The definition: 1. does not separate architectural concerns (e.g. interaction of the system with other systems) from non-architectural concerns, such as details of construction. 2. does not offer a basis for treating architectures as engineering objects [Boehm95]. We settled on the following definition: An architecture is the highest-level concept of a system in its environment consisting of structure(s) of interacting components. This definition has a number of implications: ? ?

? ?

it implies that every software system has an “architecture”, where every system can be shown to be composed of components and relations among them. it implies that the “architecture” of a system embodies information on how the components interact with each other. On the other hand, the “architecture”, intentionally, omits content information about components that does not pertain to their interaction. it implies that the behavior of each component is part of the “architecture” of the system, insofar as that behavior can be observed or discerned from the point of view of another component. it makes clear that systems can comprise more than a single structure, and that no single structure holds the irrefutable claim to being the architecture. By intention, the definition neither specifies what relationships exist between components nor does it say to what entities components are restricted; a software component may be an object, a process, a library, a database or a commercial product or anything else.

Finally, the definition addresses its own limitations: 1. “architecture” pertains to the highest-level of a system, distinguishing it from detailed design and implementation concerns. This seems consistent with e.g. the observation of Mary Shaw who warns, “let’s not dilute the term ‘architecture’ by applying it to everything in sight.” [Garlan95]; 2. by reminding us that systems are situated in their environments, and 3.that architecture is in part a recognition and response to that environment.



The weak point in our definition is obviously that the notion “concept” is not particularly useful as an engineering construct. It is easy to find references to the following “concepts” of architectures: domainspecific, systems, information, information systems, functional, software, hardware, network, infrastructure, C2, client-server, applications, operations, technical, framework, conceptual, reference, enterprise, manufacturing, building, machine-tool, etc. At other times the term “architecture” is simply an inappropriate reference[CN96]. In an attempt to provide meaning to the “concept” of architecture as an engineering construct, we find the building metaphor – the analogy between software systems architecture and traditional building architecture - quite useful [HRS96,PW92]. The “concept” of architecture could imply: 1. The art or science of building edifices of any kind for human use. 2. The action or process of building. 3. Architectural work i.e. structure or building. 4. Special method or style in accordance with which the details of the structure and ornamentation of a building are arranged. 5. Construction or structure generally. 1 Each of these senses of the “concept” is applicable in the software context and there is similar interests and activities in software/system architectural thinking (e.g. [Garlan95b, LRS94, Rechtin91]). The key term is “architecture” itself but its “concept” is applicable with varying perspectives as elaborated next. 2.2. Perspectives on Software Architecture In this paper, we take different perspectives on the notion of software architecture, we discuss architecture seen as description, architecture seen as a view on a system, architecture seen as a design, and architecture seen as style. The last two dimensions are related to the role with which architectural descriptions may play within life cycles.

2.2.1. Architecture as a view An established engineering approach to bringing descriptions of complex architectural systems under control is to “separate concerns” by identifying one or more viewpoints [RGI75]. Meszaros [Meszaros95] defines an architectural view as `a way of looking at an architecture.’ He continues by stating that `Each view may have a different concept of components and relationships’. Each `way of looking’ will be determined by the interests of the users of that view. Large to complex industrial systems relate to many disciplines, the National Payment System e.g. relates to financial, banking, markets, economics, embedded systems, real-time systems, etc. It is therefore useful to regard architecture as a multidisciplinary practice [Maier96]. Views offer a way to get a handle on this. An architectural description then conveys a set of views each of which depicts the system by describing domain concerns. Engineering principles governing views may be generic, for example, completeness, the principle that an architectural view should represent the whole system from a single, well-defined perspective, is adopted in various methods [MQ94, SZ92]. Some common architectural views include: behavioral, dynamic, operational views [LVM95, Kruchten95, TAFIM95], data, data flow, information views [DLRSV94, GACB95], development, maintenance views [Boehm95b, EHR96], distributed, network views [SZ92, EHR96], functional, activity views [SofTech78, SZ92], logical views [Kruchten95, MQ94], static views [Kruchten95, GACB95], physical views [TAFIM95, Kruchten95]. Notice that nothing has been said on how a view is depicted, i.e. what notion is used to represent a view.



2.2.2. Architecture as a description It is clear that we distinguish the notion of an ‘architecture’ from the description (or descriptions) of a view (views) on that architecture: an ‘architectural description’ is a model - document, product or other artifact - to communicate and record a system’s architecture. The distinction between architecture and architectural description allows us to retain the idea that every system has an architecture, while advocating that the explicit description of a system’s architecture allows that system to be brought under “engineering control.” The form and content of architectural descriptions may then be subject to standardization - not the architectures themselves. Architecture description language (ADL) technologies provide languages, tools, environments, and techniques to support scientific and engineering basis for design, analysis, and composition of complex systems from independently executing modules (or components)[MT97].

2.2.3. Architecture as a design The term ‘architecture’ could imply the use of an architectural description as the vehicle for expressing high-level system characteristics that define and organize its major elements and their inter-relationships. The architectural description is often developed through an evolutionary process from the initial expression of a system concept as a high-level abstraction to one of a more detailed and tangible expression that is widely accepted as being an expression of design. The architectural description is used, in this respect, to communicate between client and developer to aid clarification of requirements and assess their impact on system design. Architecture as design is useful for individual product development, analogous to the design of individual buildings [PW92, KW94].

2.2.4. Architecture as a style An ‘architectural style’ is a set of patterns [BMRSS96] for creating one or more architectures in a consistent fashion. Style is a partial characterization of a system. It does not represent the complete architecture for a system, it rather is a template (or a set of templates) for specifying the architecture of a specific system. Consequently, styles are used to mean idioms, reference architectures, or frameworks [SG96] and there are many ways to capture and communicate a style [AB95, AAG93]. Shaw et al have been attempting to classify the different styles, some examples include [SG96]: ? ? ? ? ?

the pipe and filter style : Input is transformed both locally and incrementally so that output begins before input is consumed (a parallel system) the database style: centralized control of all operational data is the key to all information sharing among components in the system the blackboard style: data sharing among components is opportunistic, with reduced levels of system overhead the message bus style: components have separate data stores coordinated through messages announcing changes among components the object request broker (ORB) mediated style: ORB technology [BW96b] provides mechanisms for language-independent interface definition and object location and activation

Each style has its own particular strengths and weaknesses. Currently, research and product development is taking place in object request brokers (ORBs) conforming to the Common Object Request Broker Architecture (CORBA), in Java Beans, Jini, etc ·

CORBA (Common Object Request Broker Architecture) is a standard for distributed objects.



The standard is being developed by the Object Management Group (OMG). The OMG is a consortium of software vendors and end users.. The CORBA ORB is an application framework that provides interoperability between objects, built in (possibly) different languages, running on (possibly) different machines in heterogeneous distributed environments. It is the cornerstone of OMG’s Object Management Architecture. ? A Java Bean is a reusable software component that can be manipulated visually in a builder tool. The goal of the JavaBeans APIs is to define a software component model for Java, so that third party software vendors can create and ship Java components that can be composed together into applications by end users. Individual Java Beans will vary in the functionality they support, but the typical unifying features that distinguish a Java Bean are: (1) Support for “introspection” so that a builder tool can analyze how a bean works, (2) Support for “customization” so that when using an application builder a user can customize the appearance and behavior of a bean. (3) Support for “events” as a simple communication metaphor than can be used to connect up beans. (4) Support for “properties”, both for customization and for programmatic use. (5) Support for persistence, so that a bean can be customized in an application builder and then have its customized state saved away and reloaded later. ? Jini connection technology is a Sun Microsystems invention designed to allow distributed systems of components to exist on many different platforms. Jini lets software and hardware components become seamlessly “federated” into a network through the use of Java technology. Devices in a Jini network are connected using Java Remote Method Invocation (RMI). This enables the Jini system to be secure and allows Java objects to move between Java Virtual Machines (VM) to implement the discovery protocol, join protocol, and the lookup service. To form a Jini network of devices and services, a registration process occurs with a lookup service. When a device is connected to the network, it performs the discovery process and locates the Jini lookup service where it uploads all of its interfaces for all its services and thereby joins the Jini network. The lookup service also has the responsibility to behave as a control center to connect clients to a particular service. When that happens, the interface for the requested service is copied to the client. 2.3. Benefits to Software Engineering Whether software architecture is interpreted as a view, a description, a design or a style, its explicitly acknowledgement enable the development of technologies for simplifying software development throughout the life-cycle[SG95]. These technologies are expected to provide models and tools for selection (guide designer’s choice among implementation alternatives), simulation (prototyping system’s dynamic behavior), verification (determining whether an implementation matches specification), analysis (determining software system implications of the specification), refinement (constructing an instance from a specification), code generation (generating code from specification), etc.

3. Architecture-Centered Development Solves Industrial Problems Our insights that architecture-centered software development is indeed helpful are based on the following reasoning: ? Complex systems typically have continuously changing requirements, so their long-term effectiveness is influenced by their ability to adapt to these changing requirements. For this reason, evolvability (the system’s ability to evolve or cope with changing requirements), is often a desirable property of complex systems [Pott94] that is well addressed by architecture-centered development. This topic is elaborated on in section 3.1



? Complex systems are critically subjected to their urgent implementation, proven technologies and guaranteed performance, and so their management to cope with these desires is improved by the ability to reuse components that have already proven to work from other environments into new environments. Reusability (subsystems’ ability to be reused in new environments) is also a desirable property of complex systems [HM84] well served by architecture-centered development. This topic is elaborated on in section 2.3.2 ? Complex systems are heterogeneous and distributed in nature, so their smooth operation is influenced by their ability to be independently composed, maintained and/or evolved. For this reason, componentization (sub-system’s ability to be composed or adapted into larger systems) and interoperability (independently executing systems’ ability to communicate) are also desirable properties of complex systems [TOGAF99] well served by architecture-centered development. This topic is elaborated on in section 2.3.3

3.1 Architecture-Centered Development Addresses Software Evolution Software evolution has been regarded as a gradual change of software systems, through a disciplined process [RLL96]. It is well-known that changing software accounts for a major part of software maintenance costs [Horo91] and continuous change is intrinsic to the nature of complex software systems. Therefore, attention in software development should therefore be both on reducing the likelihood of change and on minimizing the unit cost of change [Lehman80]. Modifying an architecture can have a wide spread effects on both system functionality and performance, and change in a systems architecture can form the biggest factor of cost in systems change[Horo91]. Studies show that when the original architecture of a system is not maintained (termed architectural erosion), the system becomes difficult to modify (resulting in a “brittle” architecture) [PW92], which in turn, increases the cost of change. Thus, the key to evolution or evolvability is the ability to make changes in a cost effective manner [IM94], while maintaining the integrity of the original architectural philosophy [Brooks75]. A system that is required to evolve must be designed to accommodate changes [IM94] and this can be achieved through ACSD because in principle architecture technologies support partial and evolutionary specification which allows partial specifications to localize the description of system structure independent of the elements being structured[SG96]. Internal component elements can then be incrementally configured and reconfigured without affecting the entire structure. Analysis capabilities supported by architecture technologies (see 2.3) can then be applied to guide the evolution path. 3.2 Architecture-Centered Development Addresses Reuse Reuse is the usage of existing components in order to produce new entities without having to start from scratch. In particular, ‘software reuse’ enables developers of new systems to make use of already existing software development artifacts to construct new projects based on “off-the-shelf” material. Research areas, such as ‘domain analysis’, ‘object-orientation’, and ‘component libraries’ are almost totally devoted towards providing a good understanding of software components and their potential reuse in the future. Many observers note that software reuse cannot succeed unless ‘the software that is supposed to be reused was designed to be reused’ [Tracz90] [GJK95]. While a universal software reuse solution may prove ineffective, significant improvements can be realized by focusing on well-defined areas of knowledge or domains. Architectures support domainspecific reuse by serving as frameworks for understanding families of systems. Work is under way to develop generalized techniques to support architecture-based, domainspecific reuse (e.g. STARS, SEI, PRISM, DSSA and DISA). The possibilities for reuse are greatest where specifications are least Journal of Integrated Design and Process Science


constrained. Since an architecture captures system characteristics that are relatively constant through time, architectures are most likely to remain consistent between successive system versions and can often be reused across applications within the same domain. Furthermore, architectures themselves can be reusable assets, but they also support reuse of design and code components by standardizing interfaces, protocols, and the packaging of functionality at a high level of abstraction. Standardization facilitates smooth integration of both off-the-shelf and custom components during initial development and subsequent maintenance phases. The (re)use of standardized architectural templates helps focus creativity where customization is needed [PW92]. Thus ACSD tools (e.g. ADLs) and techniques for defining, and manipulating component interfaces will help to facilitate reuse. 3.3. Architecture-centered development Acknowledges Componentization Componentization or sometimes called component-based software development (CBSD) focuses on building large software systems by integrating existing software components and can be considered component-based software engineering (CBSE) [Brown96, BW96]. CBSD embodies the ‘buy, don’t build’ philosophy espoused by Fred Brooks [Brooks87] and it is a special case of reuse-based development. The heart of a component-based system is a set of components, each of which is a building block (BB) known to have at least the following characteristics [TOGAF99]: ? A BB is a module or package of functionality that be independently composed and executed. ? A BB has published interfaces to access its functionality.. ? A BB may interoperate with other BBs only through its interface. ? A good BB exploits standards, and may be assembled from other BBs. ? A BB may be a subassembly of other BBs; it is well-specified and - ideally - reusable and replaceable. A BB may have multiple implementations, with different interdependent BBs. ? A component encompasses: 1. reusable BBs (such as legacy items), 2. BBs such as new applications, and 3. BBs as subject of purchase e.g. commercial off-the-shelf applications. The process of identifying BBs includes looking for collections of functions which require integration to draw them together or make them different using the desired level of integration to bind or combine functions into BBs. For instance useful legacy elements could be treated as large BBs to avoid breaking them apart.

3.3.1. CBSD perspectives Following Brown [BW96], component-based development approaches fall into four major activities: component qualification (sometimes referred to as suitability testing), component adaptation, assembling components into systems and system evolution (Fig. 2).

3.3.2. Component qualification Component qualification is the process of determining fitness for use of existing components (and it therefore includes a process for selecting components when a marketplace of competing products exists).



Qualification of a component can also be extended to include qualification of the development process used to create and maintain it (for example, ensuring algorithms have been validated, and that rigorous code inspections have taken place). In component qualification, there are two phases: discovery and evaluation. In the discovery phase, the properties of a component are identified, e.g. component functionality, interface standards, quality aspects and “non-technical” component properties such as the vendor’s market share, past business performance, etc. In the evaluation phase, evaluation techniques are employed for selecting from among a group of peer products. For example, ISO describes general criteria for product evaluation [ISO91] while others describe techniques that take into account the needs of particular application domains [IEEE93, PS92]. One recent trend is the “product line” approach, based on a reusable set of components that appear in a range of software products. This approach assumes that similar systems have a similar software architecture [Foreman96]. The common functionality can therefore be provided by the same set of components, thus simplifying the development and maintenance life cycle [LW96, STARS95].

3.3.3. Component adaptation Components usually are written to meet particular requirements, and are therefore based on specific assumptions about their context. Therefore, often they will have to be adapted. The degree to which a component’s internal structure is accessible suggests different approaches to adaptation [VK95]: ? white box- access to source code allows components to be significantly rewritten to operate with other components ? grey box- source code of a component is not modified but the component provides its own extension language or application programming interface (API) ? black box- only a binary executable of the component is available. There is no extension language or API

The way components are ‘plugged’ in an architecture is dictated by the style and with varying consequences. e.g. White-box approaches, because they modify source code, can result in serious maintenance and evolution concerns in the long term. Wrapping, bridging, and mediating are specific programming techniques used to adapt grey- and black-box components. Adaptation should, therefore, be done with respect to the architectural style that will be used, since this style dictates the semantics of the context in which the component will operate.

States

Activity transformation

Qualifications to discover interface and fitness for use

Adaptation to remove architectural mismatch

Composition into selected architectural styles

Evolution to update components

Off-the-shelf components

qualified components

Adapted components

updated components

Fig. 2 Activities of the Component-Based Development Approach.



3.3.4. Assembling and evolution Once adapted, components must be integrated and evolved through some well-defined infrastructure. This infrastructure provides the binding that forms a system from the disparate components. At first glance, component-based systems may seem relatively easy to evolve and upgrade since components are the unit of change, but this is not always the case. Replacement of one component with another is often a time-consuming and tedious task since the new component will never be identical to its predecessor. Wrappers must typically be rewritten, and side-effects from changes must be found and assessed. One possible approach is the use of the Simplex Architecture [Altman97].

3.3.5. Software architecture and CBSD CBSD shifts the development emphasis from programming to composing software systems [Clements95]. The notion of building a system by writing code has been replaced by building a system through assembling and integrating existing software components. In contrast to traditional development, where system integration is often the tail end of an implementation effort, component integration is the centerpiece of the approach. The availability of an architecture should provide the needed component integration mechanisms to minimize interoperability and mismatch problems. ACSD acknowledges componentization because in principal architecture technologies supports composition which allow independent architectural elements to be combined into larger systems. To support the above CBSD stages, therefore, these technologies are expected to provide tools and models for capturing (retaining, explaining or retrieving a definition), construction (explaining how to build larger pieces from constituent parts), composition (saying how to join pieces to get a new instance), active specification (checking consistency and preventing errors during design), selection (guide designer’s choice among design alternatives), and propagation (generating new information to improve old specifications and analysis), etc. 3.4. In The Absence of ACSD Technologies In this section, we have shown that evolution, reuse and componentization are indeed inherent complicated properties of complex system’s development whose management can be simplified by applying proper ACSD technologies. In this way we have validated the claim of ACSD that systems development should be architecture-based. However, an equally likely question would be what are the risks involved by not taking ACSD approach to evolution, componentization and reuse. During our involvement in NPS design in Tanzania, we carefully explored a number of difficulties that were directly related to the failure to accept this view in a complex systems development including. ? ?

? ?

Ambiguity: The architect may fail to distinguish between a number of architectural abstractions. Lack of traceability: Missing justification or rationale for a specification; unexplained revisions; inadequate description of sources (people, organisations, descriptions, research, lessons learned, etc.) for specifications and rationales; or inadequate description of dependencies, other than decomposition, between specifications, or insufficient decomposition of specifications. Incompleteness: Inadequate description of the modality of a specification; an unverifiable specification; ambiguous relations between specifications; or flowery language. Contradictory specifications: Circular justifications; Applying the same term to different concepts; or different terms are used to denote the same entity.



4. Adopting Architecture-Centered Approach - A Balancing Art Architecture-based systems development is useless if the available ACSD technologies cannot be successfully applied to solve these industrial problems. In this section we try to validate that there is a need for system based architecture technology development. We do so by tracing challenges, these challenges include in addition to the normal design-program-and-test activities in conventional smallscale development projects: 1. Challenges in considering domain requirements, 2. Challenges in developing (selecting) the architecture 3. Challenges in component qualification 4. Challenges in representing and communicating the architecture, 5. Challenges in analyzing or evaluating the architecture and 6. Challenges in implementing based on the architecture and assuring conformance. We survey each of these activities in the following subsections documenting for each activity what it is, the challenges it imposes to ACSD and approaches taken to address the challenge. 4.1. Challenges in Domain Requirements Considerations Requirements are the foundations for manufacturing marketable systems and products for the complete spectrum of domains. In industrial complex systems development, normally part of the system under development is already implemented. The new system is therefore considered as an evolution of the existing one. In the best case, the requirements for a preexisting system are very general to the extent that the requirements for the system to be build either conform or can be made to conform to the preexisting general requirements. In the worst case, the component will have been written to requirements that conflict in some critical manner with those of the new system, and the system designer must choose whether using the existing component is viable at all. Issues addressed include: ? ?

identifying and prioritizing domain needs in Requirements Engineering, and aligning these needs to current implementation mechanisms

Current state of the art in this regard emphasize criteria for directing and assessing the industrial relevance of future requirements engineering research and Technological Development and Technology Transfer proposals. ACSD is therefore restricted to eliciting and defining, from an exclusively industrial perspective, what the problems and expectations are with the practice of requirements engineering. The main challenge is how to ensure a consistent record of what the requirements are since, over time, the code changes, the design changes, and the requirements change. In such a dynamically changing environment, dealing with consistency and make sure that everything is kept up to date is a human behavior issue as much as anything else. 4.2 Challenges in Developing (Selecting) the Architecture While some researchers advocate a phased approach to architectural design[Witt94], experience shows that the development of a specific architecture for a given application is a highly iterative process that requires prototyping, testing, measurement and analysis [Kruchten95]. Furthermore, architecture development for complex systems is a teamwork that may involve a number of individuals. However, as Journal of Integrated Design and Process Science


Brooks argues, conceptual integrity is the key to sound system design, and conceptual integrity can only be had by a very small number of minds coming together to design the system’s architecture [Brooks75]. Ongoing work at the SEI [Clements95] posits that architects are influenced by factors in three areas: 1. requirements (including required quality attributes) of the system or systems under development, 2. requirements imposed (perhaps implicitly) by the organization performing the development and 3. experience of the architect - the results of previous decisions, whether wildly successful, utterly disastrous, or somewhere in between, will affect whether the architect reuses those strategies. It is our experience with the design of NPS, that developing the architecture should be preceded by selecting a small team of experienced architects that can easily resolve their differences and create a common architecting environment. The main challenge is how to provide a correct balance of each element of architectural concern especially non-functional requirements (e.g. tolerable risks, constraints, quality, etc.). Finding the proper balance of all relevant attributes may sometimes seem impossible. 4.3. Challenges in Component Qualification Process In order to ensure that systems meet immediate user requirements, rapid component qualification practices must be developed and respected. Standards may provide a frame of reference for comparing the components to generally accepted capabilities. Various approaches have been developed for evaluating component products in terms of their interfaces. E.g. Kontio [Kontio96] describes a rigorous process for selecting between competing COTS products. While there are several efforts focusing on component qualification, there is little agreement on which quality attributes or measures of a component are critical to its use in a component-based system. A useful work that begins to address this issue is “SAAM: a method for analyzing the properties of software architecture” [Abowd+94]. Another technique addresses the complexity of component selection and provides a decision framework that supports multi-variable component selection analysis [Kontio96]. Other approaches, such as PRISM program, emphasize “fitness for use” within specific application domains, as well as the primacy of integrability of components [PRISM96]. Yet another effort is Product Line Asset Support [PLAS96], which qualification will further be simplified through the use of standards. The selection of standards and components needs to have a sound architectural foundation, as this becomes the foundation for system evolution. This is especially important when migrating from a legacy system to a component-based system. If an organization chooses to use the component-based system development approach and it also has the goal of making a system open, then interface standards need to come into play as criteria for component qualification. The main challenge is how to construct the appropriate set of standards in the presence of heterogeneous and open environment. In complex environments like NPS most of its components are driven by COTS products, possessing different architectural styles, with different functionality, with varying levels quality but yet these have to communicate and interoperate. In this situation standards may mean quite different things for different environments. 4.4. Challenges in Representing and Communicating the Architecture In order for a given architectural instance to be effective as the backbone of the project’s design, it must be communicatable unambiguously to all stakeholders. Developers must understand assignments the choice of the architectural instance imposes; testers must understand the task structure it imposes on them; management must understand the scheduling implications it suggests. Thus the representation medium should be informative, unambiguous and readable by people with various backgrounds.



The architects themselves must ensure that the architectures developed are such that a system that is subsequently developed from the architecture (and architectural descriptions) meets the behavioral, performance, and quality requirements. Therefore, it is almost a requirements that the notation in which the architectural descriptions are expressed, is sufficiently formal to allow analysis techniques such as model-building, simulation, verification, and rapid prototyping. The notation, an Architectural Description Language (ADL) should thus be formal and complete. This field of architecture description languages is young but growing prolifically [CN96]. The challenge is in finding the right model of architecture descriptions that will satisfy all specification needs of complex systems. 4.5. Analyzing or Evaluating the Architecture Analysis capabilities for many ADLs tend to concentrate on runtime properties of the architectural instance - its performance, its behavior, its communication patterns, and the like. Less developed are analysis techniques for evaluating an architectural instance from the point of view of non-runtime quality attributes. Chief among the less developed capabilities is maintainability, the ability to support change, which has many variations: portability, reusability, adaptability, etc. A direction that is promising is scenariobased evaluation, there is emerging a consensus on the value of scenario-based evaluation to judge an architecture with respect to non-runtime quality attributes [Kazman94, Kruchten95]. The challenge is how to cope with limitations of architecture description models to provide for extra analysis capabilities. One area could be sharing and interchange among various architecture languages but there is still no clear way of doing that. 4.6. Challenges in Implementing Based on the Architecture and Assuring Conformance Implementation is concerned with ensuring that the developers adhere to the structures and interaction protocols dictated by the architecture. An architectural environment or infrastructure would be beneficial here. However, work in this area is still quite immature and largely affected by the development process as well as the planning.

4.6.1. The development process A good architecting environment aids the development process [Karat91,Norman88,SN93], by allowing: ? Collective Development. The process of software development is , among many other things, also a social process. Participation from all levels (users, policy-makers, etc.) is required for decisions affecting multiple parts or users, as well as those concerning future growth and evolution. Rather than a plan, a group adopts a process that balances collective and individual needs. ? Participatory Design. Users can help design things that they really need and want, that are better adapted to their surroundings, and that are more aesthetically pleasing. Even if the design participants are not the permanent, ultimate users, participation by someone impacted by the artifact is better than the alternative. Architects may reject user requests only when their knowledge of local constraints is demonstrably greater. ? Decentralization. Larger efforts can be subdivided into expanding centers or domains, that increasingly influence one another in the course of growth. Localized experimentation, discovery, and change are intrinsic to such adaptation. This includes situations in which conditions change and designs evolve. ? Integration of Roles. Designers operate at several levels. Primary roles should be assigned according to problem task or domain, not phase or level. Architects may be builders, and vice versa. They cannot otherwise get things right. Intimacy with all aspects of an effort allows the architect to firsthand discover constraints, needs and desires. Journal of Integrated Design and Process Science


? Integration of Activities. Design is interwoven with synthesis in a mainly bottom-up fashion. Construction proceeds in an order governed by pattern interdependencies, the continuous analysis and repair of failures, and commitment to detail, variety, experimentation, and wholeness. Concurrent development of mostly-independent parts allows construction to branch out from multiple centers, ultimately “stiffening” into final form. ? Stepwise Construction. Artifacts are constructed one pattern at a time, each of which results in a complete, recognizable form adapted to other already-constructed artifacts and partially committed plans. Efforts are focused upon operations, not components. Each operation is complete in itself. Creativity and accomplishment are maintained at all levels of this process. To facilitate the above architectural environment, an organization’s software development process and philosophy may need to change. System integration can no longer be at the end of the implementation phase, but must be planned early and be continually managed throughout the development process. It is also recommended that as tradeoffs are being made among components during the development process, the rationale used in making the tradeoff decisions should be recorded and then evaluated in the final product [BW96]. The challenge is in the selection of the proper process model for a specific environment.

4.6.2. Planning and configuration management Many of the problems encountered when integrating components cannot be determined before integration begins, especially when COTS and other black-box components are involved. Thus, estimating development schedules and resource requirements is extremely difficult and requires good planning [VGD96]. In real life, most of the software exists in multiple versions - alternative forms, custom tailored adaptations, alternative platforms, different configuration requirements and there is an increased pressure on configuration management. Naturally, this invites change conflicts in which: (a) simultaneous update problem arise when several developers modifying the same software configuration item and developer’s changes cancel or overwrites some changes made by another developer; and (b) double maintenance problem arise when several copies of SCI are kept and a fix is not propagated to all copies. Good methods for configuration management are needed to complement the planning process at architecture level. The challenge is finding a proper configuration management model. At best, configuration management tools will need to be integrated by Architecture Description Languages and tools. 4.7. Other Challenges

4.7.1. External dependencies An organization loses a certain amount of autonomy by acquiring additional dependencies when integrating COTS components [Monfort96]. COTS component producers frequently upgrade their components based on error reports, perceived market needs and competition, and product aesthetics, while most organizations’ internal systems typically change at a much slower rate. An organization must juggle its new functionality requirements to accommodate the direction in which a COTS product may be going. A new release for a component requires a decision from the component-based system developer/ integrator on whether to include the new component in the system. To answer “yes” implies facing an undetermined amount of rewriting of wrapper code and system testing. To answer “no” implies that the system is depending on older versions of one or more component that may not be adequately supported by the COTS supplier. That is why, CBSD approach is sometimes considered a risk transfer rather than a risk reduction approach. In some domains, i.e. building safety-critical systems, using COTS components is often considered too risky [BW96]. The challenge is finding where to draw the line in a specific organization. Transactions of the SDPS


4.7.2. Technology insertion Replacing a component often has rippling affects throughout the system. Especially when many of the components in the system are black box components; the system’s integrator will not know details on the component’s construction nor how details on the component’s reaction in an interdependent environment. Over the lifetime of a system, additional challenges arise, including inserting COTS components that correspond to new functionality (for example, changing to a completely new communications approach) and “consolidation engineering” wherein several components may be replaced by one “integrated” component. In such situations, maintaining external interface compatibility is very important, but internal data flows that previously existed must also be analyzed to determine if they are still needed. Therefore technology insertion initiatives should be put in place to tackled the challenges and issues associated with selecting technology solutions that will meet system requirements, while providing a flexible architecture that can accommodate cost-effective insertion of new technology. The challenge is finding proper technology insertion initiatives to for selection of technology solutions that will meet system requirements, while providing a flexible architecture that can accommodate cost-effective insertion of new technology. 4.8. In The Absence Of a Balancing Art Explicitly and systematically addressing all the issues mention in this section will guarantee performance of ACSD technologies by applying them at the right time and to the right problem. It will also help to pinpoint the loopholes in the available technologies for their improvements hence validating the claim for a system-based architecture technology development. It was observed in our NPS involvement that ignorance in addressing any of these issues may also result into serious practical problem including: ? Biased Decisions: Architects may be subjected to representations of competing perspectives which are in effect complementary and need to be understood together. In a broader and more suitable framework they together sustain but when the focus is on one such perspective, the existence and nature of that broader perspective is compromised by opposing some other perspectives. ? Wrong Purpose: Persuasive argument disguised as a specification, or preference for a particular supplier disguised as a specification, or design decision disguised as a specification. ? Over- or underestimation: An architect overlooks a specification or, in case of multiple architects, each architect may assume that another architect is responsible for describing the specification in question.

5. ADL as ACSD Infrastructure: Problems and Solutions In the previous two sections we have reiterated opportunities and challenges for ACSD in industrial applications. In this section we survey the requirements for Architecture Description Languages (ADLs) as a suitable infrastructure for ACSD and the research issues (problems and current solution) associated with current ADL technology. 5.1. Desiderata For ADLs Although ADLs are language created essentially to support explication of architectural elements and their relationships, the desire to use them as supporting technology (or infrastructure) for ACSD necessitate additional facilities. The ones directly attributed to ACSD includes (see [SG95, SG96, KN98] for more details): 1. Basic linguistic constructs: it should be possible to provide models, notations, and tools to describe architecture as a set of interconnected components;



2. Composition: It should be possible to describe a system as a composition of independent components. 3. Partial abstraction: It should be possible to describe components and their interaction of software architectures in a way that clearly and explicitly prescribe their abstract roles in a system. 4. Evolutionary specification: It should be possible describe components at multiple levels of abstractions. 5. Configuration: Architectural description should localize the description of system structure, independent of the elements being structured, and should supports dynamic reconfiguration. 6. Reuse: It should be possible to reuse components, connectors, and configurations in different architectural descriptions, even if they were developed outside the context of the architectural system. 7. Heterogeneity: It should be possible to support integration of multiple, heterogeneous architectural descriptions. 8. Analysis: It should be possible to perform rich and varied analyses of architectural descriptions. 9. Engineering Support: It should be possible to support software development life-cycle activities. 10. Scalability: It should be possible to handle large, high-level designs and adapt them to specific implementations. Clearly, there is a close interplay between language and environment issues when discussing ADL as a technology for ACSD: a language is necessary to have precise descriptions, while an environment is necessary to make those descriptions manipulated. Currently no ADL claims to provide linguistic as well as environment to cover all of the above requirements satisfactorily. 5.2. Technical Difficulties ?

Despite the recognized need for, and prospects of supporting ACSD through ADLs, the current practice is characterized by a number of impediments including: 1. different styles in architectural description languages; 2. dialects within language families, 3. lack of communication conventions, and 4. model mismatches at the architecture level (see also [Neches91] ). Heterogeneous Representations of architectures and instances: There is a wide variety of styles in architectures. Since the semantic concepts in different styles may be different, abstractions from one style cannot directly be mapped upon abstractions in another style. However, this diversity is inevitable the choice of one style over another can have a big impact on a system’s performance, and obviously, there is no single architectural style that is best for all problems, nor is there likely to be one. Thus, in many cases, sharing and reusing knowledge will involve translating knowledge from one style to another. The research problem is how to cope with the diversity of component design styles. Model Mismatches at the Architecture Level: Finally, even if the language level problems previously described are resolved, it can still be difficult to combine two components or establish effective communication between them at the architecture level. These remaining barriers arise when different primitive terms are used to organize them; that is if they lack a shared vocabulary and domain terminology. The problem is how do we cope with model mismatches. Dialects within Language Families: Even within a single family of architectural styles, it can be difficult to share abstractions across systems if the abstraction has been encoded in different notations or dialects. Some of the differences between dialects are substantive, but many involve arbitrary and



inconsequential differences in syntax and semantics. All such differences, substantive or trivial, impede sharing. It is important to eliminate unnecessary differences at this level. The research problem is how to make architectural assumptions explicit. Lack of Communication Conventions: Architectural abstraction sharing does not necessarily require a merging of all agent languages. Different agents can communicate with one another without sharing a common knowledge base. Unfortunately this approach is not generally feasible for today’s systems because we lack an agreed protocol specifying how systems are to query each other and in what form answers are to be delivered. Similarly, we lack standard protocols that would provide interoperability between architecture representation systems and other, conventional software, such as database management systems. The problem is how do we improve mediation between languages. 5.3. Current Proposed Technical Solutions Solutions to the above problems can be realised along several dimensions depending on the assumptions of the researchers involved e.g. assuming the existence of useful legacy assets that need to be protected and seek solutions to reuse them as they are; assuming lack of good architecture description languages; assuming existence of interoperability problems; or assuming the existence methodological problems. The current visible efforts in software architecture research community to address there problems are summarised below.

5.3.1. Make architectural concepts explicit Research on this issue is primarily addressing the problem of dialects within language families. Documentation at the architectural level has the problem of having less well-developed concepts, notations, and tools for supporting the documentation. Solutions to these problems are currently sought along two directions: 1. research on formal based architecture description languages [MT97] to represent architecture specifications and enable automated analysis 2. research on reverse engineering aimed at re-documentation or design recovery of architectures from legacy systems[CC90]

5.3.2. Construct large software pieces as black-boxes Research on this issue is primarily addressing the problem of heterogeneity. In most current systems, architectural design assumptions are spread throughout the constituent modules. In general, it is very difficult to separate a system into pieces or change the way the components work together, but yet reuse of those systems may prove to be valuable in many cases. The principle of information hiding seems just as important at the architectural level as it is at the code level. Architectural assumptions that might change should be hidden (encapsulated) within modules, so that a change in the assumptions would only affect a few modules of the system. Solutions are tools and techniques for automating the wrapping activities. Provide techniques for bridging mismatches. Research on bridging mismatches is primarily addressing the problem of model mismatches. Several techniques for alleviating the problems have been suggested [GAO95] including: ? Modify several components and connectors to relieve the mismatch problem. This, of course, may not be possible for components of which the source code is not available to the system developer. ? Install more versatile components and connectors. These can either assume the role of the original element or they can act as mediators between the original element and other elements in the Journal of Integrated Design and Process Science


system. For example, a mediator might translate data or communication protocols between what the original element and other elements in the system. ? Introduce a negotiated interface between two elements. In this type of design, the elements are constructed to support a range of possible interaction styles. The actual choice of which style to use in a situation is determined dynamically by “negotiation” among the components. Solutions are tools and techniques for automating the detection and bridging of model mismatches.

5.3.3. Develop guidance for architectural Interoperability Research on architecture interoperability is primarily addressing the lack of communication conventions. Some progress is being made in this area. Various systems of design patterns are being recorded and disseminated in books and articles[BMRSS96]. Architecture- and application-specific software frameworks are being developed including Common Object Request Broker Architecture (CORBA) and Common Object Model (COM), and related Capabilities [VGD96]. Solutions are tools and techniques for reinforcing, accessing and mediating interoperability infrastructure, realised along three interoperability dimensions: ? Pair-wise approach: This kind of interoperability encourages a “point-to-point connectivity.” For each pair of non-interoperable components, A and B, we need a pair of translation functions, one from A to B and one from B to A. Full connectivity among N-language components can require N(N-1) translation functions. ? Common language approach: This kind of interoperability encourages “federated architectures” where the “facilitator” is the common language e.g. UML. For each component, A, we need a pair of translation functions, one from A to S and one from S to A, where S is a common language with which every component can communicate. S can be viewed as a single standard, to which all players subscribe. ? Broker approach: This kind of interoperability encourages a “mediator network” e.g. CORBA. This is a hybrid approach. There are third parties (“brokers”), each of which understands some subset of the many protocols used by the components. If A wants to communicate with B, a broker acts as an intermediary. The broker figures out how to translate A’s language so B can understand it and vice versa. Implementers of A and B do not have to provide translation functions. Instead, brokers supply them.

6. Conclusion And Future Work In this paper, we covered industrial issues in architecture centered software development. We have shown the need for consolidation of the two complementing concerns: requiring development processes and practices to respect useful, recommended architecture principles through good methods and technologies, and requiring architecture methods and technologies to respect evolution, reuse and componentization as basic inherent properties of complex systems. Exploring the current literature on ACSD provided a good impression on the current focus of research. Its interpretation provided insight to the degree of development of research and thus serves its purpose. It became clear that attention is not broadly focused among the current research activities. While much research effort has been on technologies for architectures that enable reuse and componentization, evolution has received less attention. Only few ADLs seems to have taken this issue more seriously so far [MT97]. 6.1. New Research Directions A common understanding for software architecture abstractions and common component interface definitions, is as important for production of reusable, evolvable and interoperable software systems, as agreeing on electrical power standards and shapes of electrical sockets is, to the production of domestic Transactions of the SDPS

S EPTEMBER 2000, Vol. 4, No. 3, 31

appliances. Common component interfaces de-couple design choices, enabling systems and software application designers to respond more rapidly to new opportunities to enhance their products. Although the value of common component abstractions and interfaces is clear at the architecture level, its definition is far from consensus. Studying the formal definitions of these interpretations is a matter of software architecture ontology: a complete set of vocabulary whose relationship between one term and the other is defined using formal theories to provide a semantic basis for the terminology chosen; a taxonomy or classification with rich relationships between terms that enable the explicit expression of domain, task and method specific knowledge without the need to interpret them from code-based implementations. (See [Gruber92, Gruber93, Gruber94]). We feel that borrowing ontology design techniques from knowledge engineering into software engineering research will provide a starting point for a consolidated research solutions with industrial expectations. None of the current research initiatives (see www resource site [SARS99]) addresses the issue of software architecture ontology. Clearly there is no consensus among researchers and industry on most of the concepts and definitions. This observation forms the basis for our future research on ontologies for software architecture. A research on Software Architecture Ontology should be a first step towards developing an integrated ACSD environment.

7. Acknowledgement This research has been supported by NUFFIC, Dutch Government under MHO research cooperation between Delft University of Technology, The Netherlands and University of Dar Es Salaam, Tanzania.

8. References Abowd G., Allen R., and Garlan D., 1993, “Using Style to Understand Descriptions of Software Architecture”, ACM Software Engineering Notes, Vol. 18, No. 5, pp. 9-20. Abd-Allah A., and Boehm B.W., 1995, “Reasoning About The Composition of Heterogeneous Architectures”, Technical Report USC-CSE-95-503, University of Southern California. Abowd G., et al., 1994, “SAAM: A Method for Analyzing the Properties of Software Architecture”, Proceedings of the 16th International Conference on Software Engineering. pp. 81-90. Sorrento, Italy, Los Alamitos, CA: IEEE Computer Society Press. Alexander C., 1979, The Timeless way of Building, New York, Oxford University Press. Altman N., 1997, “The simplex Architecture”. Buschmann F., Meunier R., Rohnert H., Sommerlad P., and Stal M., 1996, Pattern-Oriented Software Architecture: A System of Patterns, Wiley. Boehm B.W., 1995, “Engineering Context for Software Architecture”, Invited talk, First International Workshop on Architecture for Software Systems, Seattle, Washington. Boehm B.W., 1995, “Software Process Architectures”, In Proceedings of the First International Workshop on Architectures For Software Systems, Seattle, WA. NPS : Stocktaking Report, 1998, National Payment System, The Bank of Tanzania, Internal report. Brooks F. P., 1975, The Mythical Man-month, Addison-Wesly. Brooks F.P., 1987, “No Silver Bullet: Essence and Accidents of Software Engineering”, Computer, Vol. 20, No. 4. Brown A.W., 1996, “Preface: Foundations for Component-Based Software Engineering”, Component-Based Software Engineering: Selected Papers from the Software Engineering Institute, pp. vii-x., Los Alamitos, CA: IEEE Computer Society Press. Brown A. W., and Wallnau K.C., 1996, “Engineering of Component-Based Systems”, Component-Based Software Engineering: Selected Papers from the Software Engineering Institute, pp. 7-15, Los Alamitos, CA: IEEE Computer Society Press. Journal of Integrated Design and Process Science


Brown A.W., and Wallnau K.C., 1996, “A Framework for Evaluating Software Technology”, IEEE Software, Vol. 13 No.5, pp. 39-49. Chikofsky E.J., and Cross J.H., 1990, “Reverse engineering and design recovery: A taxonomy”, IEEE Software, Vol. 7, No. 1, pp.13-17. Clements P.C. 1996, “From Subroutines to Subsystems: Component-Based Software Development”, ComponentBased Software Engineering: Selected Papers from the Software Engineering Institute, pp. 3-6, Los Alamitos, CA: IEEE Computer Society Press. Clements P.C., and Northrop L.M. 1996, “Software Architecture: An Executive Overview”, Technical Report CMU/SEI-96-TR-003, ESC-TR-96-003, Software Engineering Institute, Carnegie Mellon University, Pittsburgh. Dusink L., and van Katwijk J., 1995, “Reuse dimensions”, In: M.H. Samadzadeh, M.K. Zand, (eds.); Proceedings of the ACM SIGSOFT Symposium on Software Reusability (SSR’95), pp. 137-149. Seattle, Apr. 1995, ACM Press, ISBN 0-89791-739-1, New York. Druffel L., Loy N.E., Rosenberg R.A., Sylvester R.J., and Volz R.A., 1994, “Information Architectures That Enhance Operational Capability in Peacetime and Wartime”, Technical Report, US Air Force Science Advisory Board, February. Emery D.E., Hilliard II R.F., and Rice T.B., 1996, “Experience applying a practical architectural method”, In A. Strohmeier, editor, Reliable Software Technologies - Ada Europe’96, Number 1088 in Lecture Notes in Computer Science, Springer. Foreman J., 1996, “Product Line Based Software Development - Significant results, Future Challenges”, Software Technology Conference. Salt Lake City, UT. Gacek C., Abd-Allah A., Clark B.K., and Boehm B.W., 1995, “On the Definition of Software System Architecture”, In Proceedings of the First International Workshop on Architectures For Software Systems, Seattle, WA. Garlan D., Allen R., and Ockerbloom J., 1995, “Architectural Mismatch: Why Reuse is So Hard”, IEEE Software, Vol. 12, No. 6. Garlan D., ed., 1995, Proceeding of the First International Workshop on Architecture for Software Systems, Seatle, WA, Published as CMU-CS-TR-95-151. Garlan D., 1995, “Research Directions in Software Architecture”, ACM Computing Surveys, Vol 27, No.2, pp. 257-261. Gall H., Jazayeri M., and Klosch R., 1995 “Research Directions in Software Reuse: Where to go from here?”, ACM Press. Proceedings of the Symposium on Software Reusability SSR’95 pp. 225-228. Gruber T. R., 1992, “Ontolingua: A mechanism to support portable ontologies. version 3. 0”, Technical report, Knowledge Systems Laboratory, Stanford University, California. Gruber T.R., 1993, “A translation approach to portable ontology specifications”, Knowledge Acquisition, Vol.5, pp.199-220. Gruber T.R., 1993, “Towards principles for the design of ontologies used for knowledge sharing”. Guarino N., and Poli R., ed., 1994, Formal Ontology in Conceptual Analysis and Knowledge Representation. Kluwer. Harker S.D.P., et. al., 1992, “The Change and Evolution of Requirements as a Challenge to the practice of Software Engineering”, Proceedings of IEEE International Symposium on Requirements Engineering, pp. 266-72. Horowitz B.M., 1991, “The importance of architecture in DOD Software”, The MITRE Corporation, Report M91-35. Hilliard II R.F., Rice T.B., and Schwarm S.C., 1996, “The architectural Metaphor as a foundation for Systems Engineering”, In Proceedings of Sixth Annual International Symposium of the International Council on Systems Engineering. IEEE Std 610.12, 1990, Glossary of Software Engineering Terminilogy. IEEE Std. 1209-1992, 1993, IEEE Recommended Practice on the Selection and Evaluation of CASE Tools, New York, NY: Institute of Electrical and Electronics Engineers.



Isaac D., and McConaughy G., 1994, “The Role of Architecture and Evolutionary Development in Accommodating Change”, Proceedings of INCOSE’94, pp. 541-545. Information Technology - Software Product Evaluation - Quality Characteristics and Guidelines for their Use, 1991, Geneve, Switzerland: International Standards Organization/International Electrochemical Commission. Karat J., ed., 1991, Taking Software Design Seriously: Practical Techniques for Human-Computer Interaction Design, Academic Press. Kauffman S.A., 1990, “Requirements for Evolvability in complex systems: orderly dynamics and frozen components”, Physics D. Vol. 42, No. 1, pp. 135-152. Kazman R., 1994, “Toward Deriving Software Architectures From Quality Attributes”, A Technical Report, CMU/SEI-94-TR-10, SEI, Pittsburgh, Pennsylvania. Kyaruzi J., and van Katwijk J., 1997, “Facilitating Software Systems Architectural Evolution”, In proceedings of the WESS’97 2-nd international workshop on Empirical Studies of Software Maintenance, L.C.Briand, F.L.Lanubile (eds), IEEE Computer Society 3-00-002030-6, pp 67-74. Kontio J., 1996, “A Case Study in Applying a Systematic Method for COTS Selection”, Proceedings of the 18th International Conference on Software Engineering, pp. 201-209, Berlin, Germany, Los Alamitos, CA: IEEE Computer Society Press. Kruchten P.B., 1995, “The 4+1 view Movel of Architecture”, IEEE Software, Vol. 28 No. 11, pp.42-50. Lehman M.M., 1980, “Program, Life cycles, and Laws of software evolution”, IEEE Transactions on Software Engineering, Vol. 68, No. 9, pp. 1060-1076. Lettes J.A., and Wilson J., Army STARS Demonstration Project Experience Report (STARS-VC-A011/003/02), Manassas, VA: Loral Defense Systems-East. Lawson H.W., Rossak W., and Simpson H.R., 1994, “Working Group Report- CBS architecture”, In Proceedings of the 1994 tutorial and workshop on systems engineering of computer based systems, Los Alamos, CA, IEEE Computer Society Press. Luckham D.C., Vera J., and Meldal S., 1995, “Three Concepts of System Architecture”, Technical Report CSLTR-95-674, Stanford University. Luckham D., and Vera J., “An Event-Based Architecture Definition Language”, IEEE Transactions on Software Engineering, Vol. 21, No. 9. Maier M.W., 1996, “Systems Architecture: An emerging discipline?”, In 1996 IEEE Aerospace Applications Conference Proceedings, Vol. 3, pp. 231-246. Meszaros G., 1995, “Software Architecture in BNR”, In Proceedings of the First International Workshop on Architectures for Software Systems. Monfort Lt. Col., Ralph D., 1996, “Lessons Learned in the Development and Integration of a COTS-Based Satellite TT&C System”, 33rd Space Congress. Cocoa Beach, FL. Medvidovic N., Oreizy P., Robbins J., and Taylor R.,1996, “Using Object-Oriented Typing to Support Architectural Design in the C2 Style”, Software Engineering Notes, Vol. 21, No. 6, Proceedings of the Fourth ACM SIGSOFT Symposium on the Foundations of Software Engineering. Medvidovic N., and Taylor R., 1997, “A Framework for Classifying and Comparing Architecture Description Languages”, In Proceedings of the Sixth European Software Engineering Conference together with the Fifth ACM SIGSOFT Symposium on the Foundations of Software Engineering, pp. 60-76, Zurich. Moriconi M., and Qian X., 1994, “Correctness and Composition of Software Architectures”, In Proceedings of ACM SIGSOFT’94: Symposium on Foundations of Software Engineering, New Orleans, LA. Neches et al., 1991, “Enabling Technology for Knowledge Sharing”, AI Magazine, Vol.12 No.3, pp.16-36. Norman D., 1988, The Psychology of Everyday Things, Basic Books. Parnas D.L., and Clements P.C., 1985, “The modular structure of complex systems”, IEEE Transaction on Software Engineering. Vol. SE-11 No. 3, pp. 259-266. Poston R.M., and Sexton M.P., 1992, “Evaluating and Selecting Testing Tools”, IEEE Software, Vol.9, No.3 pp. 33-42.



Potts C., 1993, “Software-Engineering Research Revisited”, IEEE Software, pp. 19-28. Perry D., and Wolf A., 1992, “Foundations for the Study of Software Architecture”, ACM SIGSOFT Software Engineering Notes, Vol. 17, No. 4. Rechtin E., 1991, Systems Architecting: Creating and Building Complex Systems, Prentice Hall. Rechtin E., 1992, “The Art of Systems Architecting”, IEEE Spectrum, Vol. 29, No. 10. Ross D.T., Goodenough J.B., and Irvine C.A., 1975, “Software Engineering: Process, Principles and goals”, IEEE Computer, Vol. 8, No. 5, pp. 17-27. Rowe D., Leaney J.R., and Lowe D., 1996, “Development of a Systems Architecting Process For Computer Based Systems”, Proceedings of the ICECCS’96, Montreal Canada. Rowe D., Leaney J.R., Lowe D.B., 1998, “Defining systems evolvability - a taxonomy of change”, 11th International Conference on the Engineering of Computer Based Systems (ECBS’98). Schuler D., and Namioka A., 1993, Participatory Design, Lawrence Erlbaum. Shaw M., and Garlan D., 1996, Software Architecture: Perspectives on an Emerging Discipline, Prentice-Hall. Air Force Materials Laboratory, 1978, “SofTech”, Integrated Computer Aided Manufacturing (ICAM) Task I Final Report”, Technical Report AFML-TR-78-148. Sowa J.F., and Zachman J.A., 1992, “Extending and Formalizing the Framework for Information Systems Architecture”, IBM Systems Journal. Vol.31 No.3 pp. 590-619. Defense Information Systems Agency, 1995, Technical Architecture Framework for Information Management (TAFIM), version 2.0 edition. Thomas I., and Nejmeh B., 1992, “Definitions of Tool Integration for Environments”, IEEE Software, Vol.9, No.3, pp. 29-35. Tracz W., 1990, “Where Does Reuse Start?”, Software Engineering Notes, Vol. 15 No. 2, ACM SIGSOFT. Valetto G., and Kaiser G.E., 1995, “Enveloping Sophisticated Tools into Computer-Aided Software Engineering Environments”, Proceedings of 7th IEEE International Workshop on CASE, pp. 40-48, Toronto, Ontario, Canada, Los Alamitos, CA: IEEE Computer Society Press. Vidger M.R., Gentleman W.M., and Dean J., 1996, COTS Software Integration: State-of-the-Art. Weiderman N. H., Bergey J. K., Smith D.B., and Tilley S.R., 1997, “Approaches to Legacy System Evolution”, SEI Technical Report, CMU/SEI-97-TR-014, ESC-TR-97-014.



concerns on architecture-centered software development - IOS Press

concerns on architecture-centered software development - IOS Press

Suggest Documents

concerns on architecture-centered software

The employment concerns of Americans with multiple ... - IOS Press

Quantitative Neuroimaging Software for Clinical ... - IOS Press

The employment concerns of Americans with multiple ... - IOS Press

Communicating Concerns in Collaborative Software Development

Structuring software anthropometric variables on CD Rom ... - IOS Press

Structuring software anthropometric variables on CD Rom ... - IOS Press

Development and characterization of monoclonal ... - IOS Press

Research on seamless development of surgical ... - IOS Press

sustainable development and human factors - IOS Press

Development of intelligent service robots - IOS Press

Research on seamless development of surgical ... - IOS Press

On the Diagnosis of CADASIL - IOS Press

Occupational therapists' perspectives on binocular ... - IOS Press

JRS667 Abstracts.indd - IOS Press

Get PDF - IOS Press

JRS667 Abstracts.indd - IOS Press

JRS667 Abstracts.indd - IOS Press

JRS667 Abstracts.indd - IOS Press

Get PDF - IOS Press

Breast cancer - IOS Press

Get PDF - IOS Press

Get PDF - IOS Press

Get PDF - IOS Press