David E. Emery

Software architecture: introducing IEEE Standard 1471

IEEE Standard 1471 identifies sound practices to establish a framework and vocabulary for software architecture concepts.In 2000, the Computer Society approved IEEE Standard 1471, which documents a consensus on good architectural description practices. Five core concepts and relationships provide the foundation for the approved IEEE 1471 version: every system has an architecture, but an architecture is not a system; an architecture and an architecture description are not the same thing; architecture standards, descriptions, and development processes can differ and be developed separately; architecture descriptions are inherently multiviewed; and separating the concept of an objects view from its specification is an effective way to write architecture description standards. IEEE 1471 focuses on both software intensive systems and more general systems, such as information systems, embedded systems, systems-of-systems, product lines, and product families in which software plays a substantial role in development, operation, or evolution.

Every architecture description needs a framework: Expressing architecture frameworks using ISO/IEC 42010

The current draft revision of ISO/IEC 42010 (IEEE Std 1471) proposes a formalization of architecture framework within the ontology of the standard. This paper discusses the origin of the concept, motivates its standardization in ISO/IEC 42010, and argues that a well-defined architecture framework should be a key component of any architecture description. The paper describes the application of the proposed construct to several well-known architecture frameworks.

Experiences Applying a Practical Architectural Method

Software architecture has come to be recognized as a discipline distinct from software design. Over the past five years, we have been developing and testing a practical software architecture method at the MITRE Software Center. The method begins with an initial statement of system goals, the purchasers vision for the system, and needs, an abstraction of the systems requirements. Multiple views of the system are then developed, to address specific architectural concerns. Each view is defined in terms of components, connections and constraints and validated against the needs. This paper briefly introduces the method and describes our experiences with its “alpha” and “beta” applications to two U.S. Army management information systems.

Updating IEEE 1471: Architecture Frameworks and Other Topics

The purpose of this working session is to solicit feedback from the software architecture community for the revision of IEEE Std 1471 (now also ISO/IEC 42010), to identify topics ripe for standardization and to get reactions on current proposals under consideration for the revision. This paper briefly outlines some of the revision proposals under consideration and provides some detail about one major area: architecture frameworks. The WICSA Wiki will be used to solicit participation, capture discussions and insights, and organize the working session. Findings and results from the session will then be recorded there.

Reviewing architecture documents using question sets

This paper proposes a structured approach for reviewing architecture documents using question sets. Given the critical importance of architecture to software project success, it follows that the architecture cannot be effective unless it is captured in documentation that allows the stakeholders to understand and use the architecture in the way it was intended. The approach does not assume a particular architecture methodology or documentation approach, although it was conceived in the context of ISO/IEC 42010 and the SEI Views and Beyond approach to documenting software architectures. Like both of them, our approach is centered on the stakeholders of the artifact, utilizing them in a focused, guided way to assure that the documentation carries sufficient quality to enable them to do their jobs. Our approach is not intended as a complete framework for architecture evaluation; rather it is meant to be used within such a framework, when one is available.

Language-independent standards

The trend in modem information technology standardization is to write standard specifications that are independent of any particular programming language. Some believe the standardization effort is thus provided with greater leverage--a single specification can be applied, more or less mechanically, to the various programming languages in current usage. This column takes a contrarian view to question the logic behind this trend. Despite efforts to define programming languages with a broad scope of applicability, it has become clear that no single programming language will support all the needs, real or perceived, of the information technology community. At various times, pi-oponenf~ of languages such as PUI, Ada, C, and even Lisp have suggested they are adequate for nearly all information processing needs; and in all cases, the marketplace has demonstrated otherwise by economically supporting a variety of languages for different application domains. In fact, the current trend in large information system development is toward multilanguage integrations, in other words, multiple languages implementing a single system. Standards organizations have reacted to the reality of a multilingual user community by encouraging the development of standards not specified in terms of a single programming language. Policy decisions made at various levels of both the American National Standards Institute (ANSI) and the International Organization of Standards (ISO) have directed working groups to develop base specifications expressed in a languageindependent fashion, plus a number of “bindings” explaining how the services provided by a particular specification may be obtained from a particular programming language. The approach has met with some notable successes. One example is the success of the X3H2 standards committee in specifying a standard for SQL.’ When the committee was formed, implementations provided a wide variety of functionality. However, aside from the issues of behavior, the various implementations used different syntaxes to embed SQL statements directly in the source language of the application programs

Aspects in Architectural Description: report on a first workshop at AOSD 2007

The First Workshop on Aspects in Architectural Description was held in Vancouver, British Columbia as a part of Aspect-Oriented Software Development (AOSD) 2007. This workshop report presents a summary of the topics addressed, contributions and issues raised, and workshop conclusions.

Automating the Ada Binding Process for Java- How Far Can We Go?

This paper describes an automated approach for generating Ada bindings from Java class files. We start with the set of Java features that require a visible Ada binding, and an Ada compilers definition of how to interface Ada and Java. We discuss how to obtain the Java definitions from the class file and then translate them into an Ada binding (using the GNAT binding approach). While it is possible to generate a technically complete Ada binding from the information in a Java class file (within the constraints of necessary support from an Ada compiler). However, we show that such a binding has significant limitations from a practical usability perspective.

HCSD Unit Development Process: Step-Wise Process Improvement

Hughes Canada has been involved with the development of the Canadian Automated Air Traffic Control System (CAATS) software since 1993. The program, originally estimated to be over a million lines of Ada code, has evolved from prototyping concepts and requirements to producing operational software. This paper describes the evolution of the procedures for software development. We explain the reasons behind the changes made to the unit development process, and show our movement from ad-hoc through qualitative to quantitative process enhancement, consistent with our transition from prototyping to production.

Information systems development in Ada

Benjamin M. Brosgol Brosgol Consulting and Training 79 Tobey Road Belmont, MA 02178 (617) 489-4027 (617) 489-4009 (FAX) brosgol@ajpo.sei.cmu.edu Robert I. Eachus The MITRE Corporation 202 Burlington Road Bedford, MA 01730 (617) 271-2614 (617) 271-2911 (FAX) eachus@mitre.org David E. Emery The MITRE Corporation 202 Burlington Road Bedford, MA 01730 (617) 271-2815 (6171 271-8208 (FAX) emery@mitre.org