Development programs for software-intensive systems are increasingly attempting to employ object-oriented (OO) techniques and technologies - including OO design, the Unified Modeling Language (UML), and UML-based modeling and software development tools - in expectation of achieving greater flexibility, evolution, and productivity. However, these programs frequently experience a number of challenges when they insert OO design into their traditional practices. Unless both development organizations and acquisition offices make a thoughtful transition to OO design, they are likely to experience difficulties that may well endanger the anticipated benefits. This article describes some typical pitfalls of OO development and recommends a number of architectural practices that will help programs avoid or mitigate these dangers.

This report compares the Software Engineering Institute's "Views and Beyond" approach for documenting software architectures with the documentation philosophy embodied in agile software-development methods. This report proposes an approach for capturing architecture information in a way that is consistent with agile methods.

This article presents an overview of using a metadata-driven approach to designing applications. If the use of software frameworks can be defined by patterns, then metadata is the language used to describe those patterns.

This paper presents the Architecture Based Design (ABD) method for designing the high-level software architecture for a product line or long-lived system. Designing an architecture for a product line or long-lived system is difficult because detailed requirements are not known in advance. The ABD method fulfills functional, quality, and business requirements at a level of abstraction that allows for the necessary variation when producing specific products. Its application relies on an understanding of the architectural mechanisms used to achieve this fulfillment.

Systems exist to generate value for their stakeholders. Unfortunately, this ideal is often met only to a limited degree. Current development methods, such as waterfall, spiral, and agile often provide incomplete and inadequate direction to stakeholders, architects, and developers. Two essential concepts—value models and architecture strategy—are missing from many development processes; however, these concepts can be integrated effectively using the waterfall, spiral, or agile methods.

In the second of two articles, the authors describe how to develop business patterns based on business functions, data, and business components, and show how these can be used to engineer software systems.

More and more, systems engineers are turning to the Unified Modeling Language (UML) to specify and structure their systems. This has many advantages, including verifiability and ease of passing off information to other engineering disciplines, particularly software. This article describes a UML 2.0-based process that systems engineers can use to capture requirements and specify architecture. The process uses the UML exclusively for the representation and specification of system characteristics. Essential UML artifacts include use-case diagrams, sequence diagrams, activity diagrams, state-chart diagrams, and structure diagrams. The process is function-driven and is based heavily on the identification and elaboration of operational contracts, a message-based interface communication concept. The outlined process has been applied successfully at various customer sites. It is assumed that the reader is familiar with the basics of UML.

This technical report fits the Carnegie Mellon® Software Engineering Institute's (SEI's) architecture-centric methods into the framework of the RUP.

This article illustrates examples of combinations of the architecture-centric analysis and design methods and when the combinations could be applied during the life cycle.

This report examines the relationship between service-oriented architectures (SOAs) and quality attributes. Because software architecture is the bridge between mission/business goals and a software-intensive system, and quality attribute requirements drive software architecture design, it is important to understand how SOAs support these requirements. Interesting section that summarizes the positive and negative effects that using an SOA has on a system’s quality attributes.