1.2　Problems with architecture-centric approaches

Engineering [18] is the systematic application of scientific knowledge in creating and building cost-effective solutions to practical problems in the service of mankind. Software engineering [18, 140, 137] is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems. Generally speaking, software engineering researchers seek better ways to develop and evaluate software [135]. They are motivated by practical problems, and key objectives of the research are often quality, cost, and timeliness of software products. “One man's magic is another man's engineering” (Robert Heinlein). Engineering design is much more routine than innovative [134, 137]. It depends upon the existence of a mature discipline, such as standard notation for recording and communicating designs, established procedures, published processes, design standards, small number of unit operations, widely disseminated handbooks, etc [137, 88, 116].

Software architecture has grown in importance to be a key discipline within software engineering [137, 115, 16]. Architecture-centric development directs on developing large, complex systems in a manner that facilitates robustness of products, economy of the development process and rapid time to market. It focuses on the construction of more abstract architectural elements, or, models, but not the program source code. A model is a reduced representation of the system, from a given viewpoint [23]. This enables designers to abstract away unnecessary details and concentrate on the main concerns and problems of the system. The model is coarse-grained enough so that the design of complex systems can be represented in an easier understandable form than the actual system. Besides helping understanding complex problems and solutions, the model communicates understanding between designers and developers. It can be also used as a guide to implementation.

One of the key issues in software development, like in all other engineering areas, is to ensure that the product delivered meets its requirements. Another key purpose of models is to allow the reasoning about important properties of the software before actually building it. Developers can manipulate the models in significantly more sophisticated ways than they can code. Model-based analysis such as model checking and simulation takes place at the early stage within the process of software construction, thus ensuring the quality of the system already at the modeling level. Besides, testing is often used in software engineering for validating properties.

To support architecture-based development, software architecture modeling languages [92, 36] and their accompanying toolsets have been proposed to provide notations for specifying and analyzing the architectural models of software systems. Modeling languages (Fig. 1.2) provide abstractions that are adequate for modeling or specifying a large system, while ensuring sufficient detail for establishing properties of interest.

Figure 1.2　The architecture-centric approach

Refinements (Fig. 1.2) are the basic steps in the architecture centric software development process. Starting from an abstract description of the system, stepwise refinements yield more and more concrete specifications that should finally be directly implementable on a machine. For example, an abstract or a conceptual architecture is generated from user requirements, which mainly covers core functionality components. Later, a more concrete architecture is created that integrates non-functional requirements like security concepts and design specific aspects. In general, a conceptual architecture is smaller and easier to understand, while a concrete architecture reflects more design or implementation concerns.

“Architecture is design, but not all design is architecture.” [36] That is, many design decisions are left unbound by the architecture and are happily left to the discretion and good judgement of downstream designers and implementers. The architecture establishes constraints on downstream activities, and those activities must produce artifacts – finer grained design and code, that are compliant with the architecture, but architecture does not define an implementation.

Architectural style (Fig. 1.2) is an important concept in the software architecture area. A critical challenge for software engineering is to capture system designs and reuse established design knowledge when building new systems. One way to do this is to define an architectural style for a collection of related systems. Indeed, the use of patterns [100] and styles of design is pervasive in many engineering disciplines. An established shared understanding of the common forms of design is one of the hallmarks of a mature engineering field [137]. The architectural style of software engineering determines a coherent vocabulary of system design elements and rules for their composition. Styles are often developed systematically to solve difficult architectural problems at the conceptual level. Most styles originate when novel classes of software systems are being designed or existing systems are being adapted to unforeseen circumstances and/or environments. They are formulated and evolved to consistently repeat successes and avoid failures from previous projects. New architectures can be defined as instances of specific styles. By structuring the design space for a family of related systems a style can, in principle, drastically simplify the process of building a system, reduce costs of implementation through reusable infrastructure, and improve system integrity through style-specific analysis and checks.

Both software architectures and middleware technologies focus on helping the development of large-scale, component-based system, but they address different stages of the development lifecycle. Software architecture is an abstract model of a system that highlights the system's critical conceptual properties, while middleware enables the system's realization and ensures the proper composition and interaction of the implemented components. Some researchers are trying to coupling architecture modeling and analysis approaches with middleware technologies [94, 90, 44]. For example, some architectural styles such as client-server and event publish-subscribe style can be used as a reference on the abstract layer for middleware development, therefore a middleware is a realization of an architecture style.

However, mobility has created additional complexity for computation and coordination. This makes the current architectural approaches and techniques hard to use [10]. The current architectural approaches have been designed for traditional distributed systems without consideration of mobility. They offer only a logical view of change; they do not take into account the properties of the “physical” distribution topology of locations and communications. It relies on the assumption that the computation performed by individual components is irrelative to location of the component, and that coordination mechanisms through connectors can be always transmitted successfully by the underlying communication network. In order to support mobility, the architectural and modeling approach needs to be adjusted.