While it is widely agreed that architectural simplicity is a key factor to the success of large software systems, it is not obvious how to measure architectural complexity. Our approach to measuring complexity is based on observation that large systems with a regular substructure are simple to create and maintain, whereas even relatively small systems created in an ad hoc fashion quickly become unmaintainable. This paper describes a system, called IAPR, that aids in architectural exploration and measurement by attempting to match patterns to an architecture. To do this, IAPR implements a heuristic form of sub-graph isomorphism—an NPhard problem—using the Constraint Satisfaction paradigm to limit the complexity of the problem space.

This paper presents a Software Engineering tool set for developing process-oriented Internet applications. This paper also presents experiences using this tool set to implement two industry quality business processes. These experiences provide practical Software Engineering principles for implementing Internetbased business processes: adaptable e-business connections, interconnected business-process-technology architectures, process-centric user interfaces, process conciseness and process personalization, and process branding.

Abstract not found

The application of a design pattern in an industrial context is frequently a much more involved task than is described the pattern description itself. In this experience paper we report on a number of problems encountered in the application of several common patterns in commercial software systems. The problems we examine range in nature from details of the runtime environment that hamper pattern implementation (Singleton), to the software upgrade process breaking a pattern’s promise (Abstract Factory), to the consequences of the tight source code coupling produced by pattern application (Facade). Our conclusion is that while design patterns are indeed useful in industrial software development, there are more potential pitfalls in this area than is generally realised. In applying a design pattern, more must be taken into account than just the design context into which the pattern fits; issues to do with the low-level runtime environment as well as the higher-level software architecture, software process and social environment also play a role. 1.