No abstract available.

The presence of a solid architectural vision is a key discriminator in the success or failure of a software project. This tutorial examines what software architecture is and what it is not. It discusses and illustrates how to describe architecture through a set of design viewpoints and views and how to express these views in the UML, in the spirit of the new IEEE Standard 1471:2000:Recommended practice for architectural description. The tutorial shows of how architectures drive the development process and how to capture architectural design patterns using the UML. It is illustrated by several widely applicable architectural patterns in different domain.

Modern software development processes, like the Rational Unified Process, prescribe an iterative approach to software development. A fundamental assumption of an iterative process is that system requirements don't have to be completely understood to commence development. At first glance the assumption that one can start developing a system without completely understanding its requirements seems paradoxical. However, upon closer inspection requirements can be divided into many categories, one of them being "architecturally-significant requirements". It is the understanding of these requirements, the associated development risks, and the system architecture that drive the early iterations of system development.

The presence of a solid architectural vision is a key discriminator in the success or failure of a software project. This tutorial examines what software architecture is and what it is not. It discusses and illustrates how to describe architecture through a set of design viewpoints and views and how to express these views in UML (Rumbaugh et al., 1998), in the spirit of the new IEEE Standard: Recommended practice for architectural description. The tutorial shows of how architectures drive the development process and how to capture architectural design patterns using UML (Unified Modeling Language). It is illustrated by several widely applicable architectural patterns in different domains.

With the maturation of this field, companies are now in a position to describe, package, and reuse application architectures. This is exactly what Rational Software is trying to do for what we call solution stacks. A solution stack is defined by the selection of a problem domain, a deployment infrastructure, a development infrastructure, and various project characteristics. For such a point in the development space, it seems possible to pre-build an entire application framework capturing the key architectural decisions for that application. The talk will describe how we can approach that task and what the outcome may look like.

The term business component has become a prominent buzzword in the IS professional lingo. Component based software engineering promises to be the next breakthrough in controlling the exploding complexity and cost of systems development and maintenance. However, there is no agreed upon model that defines what these components are, how they fit into the overall OO domain, and how they relate to systems architectures. There are also very few, if any, software frameworks developed to support construction of systems from business components. The paper first introduces a business component model and then describes a particular software framework. The framework has been developed at System Software Associates and supports construction of system from software components implementing well articulated and reusable business concepts.

The authors explore object-oriented reuse from several perspectives, covering process, methods, technology, architecture, tools, patterns, frameworks and experience. The theme is: objects are neither necessary nor sufficient for effective reuse, but are extremely important if done right.>

The paper describes an approach to software reuse which is under development and evaluation at Andersen Consulting. Instead of restricting reuse to just code, we are exploring reuse of architectures that include component interfaces, interconnections between components, and platform configuration. The approach assumes that first a desired architecture is chosen and tailored according to the constraints at hand. Then, appropriate components are retrieved from a repository, subjected to restricted modifications if necessary and "glued" together following the architectural guidelines. Finally, a version of a system is automatically packaged from the selected components and the architectural specifications. The paper presents the approach and some initial experiments in the design of an interface specification language and an environment in which modules can be interconnected and their interface specifications used to determining the integrity of the connections.>

Abstract This paper provides a framework for considering the problems of re‐engineering transaction processing systems. Such systems are key components of most modern business operations, and their continued enhancement is crucial for competitiveness. The paper grew out of a study of software re‐engineering problems and practices carried out by Andersen Consulting at several major companies in the telecommunications industry. It describes some of the practical difficulties found in re‐engineering transaction systems, especially the problems caused by the need for an incremental approach and the difficulties of re‐engineering in parallel with the continuing evolution of the operational system. This paper presents a model of the maintenance and re‐engineering processes showing the main activities that are needed and the data flows among them. Existing tools for re‐engineering are then analysed against this model to identify gaps and potential for further tool development. Finally, there is a brief discussion of the very stringent personnel needs of software re‐engineering projects.

The automated recognition of abstract high-level conceptual information or concepts, which can greatly aid the understanding of programs and therefore support many software maintenance and reengineering activities, is considered. An approach to automated concept recognition and its application to maintenance-related program transformations are described. A unique characteristic of this approach is that transformations of code can be expressed as transformations of abstract concepts. This significantly elevates the level of transformation specifications.>

An approach is described that applies a transformation paradigm to automate software maintenance activities. The approach to code-to-code (horizontal) transformation is based on a high-level understanding of the programming and application domain concepts represented by the code. A very unique characteristic of this approach is its use of concept recognition, the understanding and abstraction of high-level programming and application domain entities in programs, as the basis for transformations. A program transformation tool has been developed to support the migration of a large manufacturing control system written in COBOL.>

The special problems of software re-engineering and technologies and approaches that specifically address these re-engineering problems are considered. Particular attention is given to approaches for analyzing and abstracting the functionality of old code, converting software to work with new languages or dialects, translating large systems, defining appropriate roles for the user of highly automated tools, and identifying the automatable steps in a large-scale project to re-engineer assembly language code. An attempt is made to indicate on the basis of actual experience what aspects of the re-engineering process seem to be most amenable to automation and what productivity gains can be expected.>

Summary form only given. The BAL/SRW is a set of software reengineering tools developed to help an analyst recover the design of an assembly program. This is achieved through a series of abstractions, which effectively collapse program functionality into progressively higher level concepts. The BAL/SRW does not automatically transform the assembly code into a different format, but provides tools for an analyst to uncover and document the program logic. The design recovery process begins with a surface analysis which provides the analyst with information characterizing the overall program complexity and information about the context in which the program executes. This general information can be used to estimate the re-engineering effort and make project management decisions. The outcome of the design recovery process is a graphically oriented program design, constructed by the analyst. The BAL/SRW has its own program design editor, which is a structured program definition tool.>

In this paper, we address issues related to the reengineering of large-scale software systems. The key to the software re-engineering activity is the ability to recover (re-engineer) lost or otherwise unavailable information concerning specification and system design decisions from the information available in the existing system source code. Subsequently, a forward engineering step may reimplement and possibly upgrade the existing systems. This paper describes the underlying princi- ples of a knowlkige-based Software Re-engineering Environment (SRE) which is intended to provide high-level support to various software maintenance and re-engineering activities.