Object-Oriented Design Quality Through Architectural Structures Walter Kriha, Daniel Kesch, Stephan Pluess SYSTOR AG Lautengartenstr. 6 4002 Basel Switzerland E-mail: {walter.kriha, daniel.kesch, stephan.pluess}@systor.com August 26, 1997 We argue, that a better understanding of the properties of OO system design is obtained by structuring its architecture. This can be done along several criterias. Today, analytical, logical and sometimes even physical structures are common for modelling a large systems design. We claim, that there exists other important structures, that in part conflict with each other. In order to improve OO design quality, we seek to make these software structures transparent, to explain their need to be considered early-on and continoulsy in the design and development process, to describe their interactions and impacts upon each other, and to use these structures to rate an OO system design. The paper presents these software structures as a set of architectural structures to be considered when designing, implementing, and evolving a large system's architecture in order to improve and challenge its design. 1. Introduction A large software project can span many developers, several layers of management, and sometimes even multiple geographic sites and source code bases. The architecture of such a system will not only be reflected in the logical structure of the application, but also be expressed in other underlying software structures that most often are in conflict with each other. A reason for the failure of a lot of software projects - even or especially object- oriented applications - lies in the disregard of these software structures and their interactions with each other. More often than not, an application is specified after a initial OO analysis and design cycle, and then programmed accordingly in a programming language such as C++. However, the development team usually realizes upon execution of the software that the promises of the OO methodology does not hold true: The logic of such an application may be right, but the software's underlying architecture did not realize the properties of a large system that we would consider appropriate. Thus good architectural design has a major impact on the success of a software system. On the other hand, a software architecture is invisible, implicit, and often hard to visualize. As an emerging discipline, there is a growing body of work addressing the codification of architectural expertise. For example, Kruchten's 4+1 View architecture model [1] seeks to describe a software architecture as a model composed of up to four views or dimensions. We motivate the intention behind the set of architectural structures presented in this paper as 1) a pragmatic enhancement to the existing body of work in the field of software architecture, 2) as a hands-on approach for practitioners when designing the architecture of a large system and 3) as a simple instrument to assess a projects design quality. Section 2 of this paper presents an overview of these architectural structures and describes their impacts and dependencies upon each other. Section 3 links the architectural structures to the software development and design quality assurance process. Section 4 provides a conclusion and offers an example of what could be a product of the consideration of these architectural structures. Our current and future work will define a catalog of these architectural structures - including their motivations, responsibilities, collaborations, consequences, and potential implementations -, provide experience reports from each of the authors' projects, include rules of thumbs and techniques, and setup a heuristic to rate a OO system design based on its instantiated structure dependency graph. 2. The Architectural Structures Of A Large System 2.1 Architectural Structures: An Overview We claim that a large system can be decomposed into several categories of software structures. The ten most important structures of a system's architecture we consider today are: 1. Analytic Structure: Its main purposes are two-fold: 1) the decomposition of a large system into a set of key abstractions, and 2) the consideration and weighing of all other architectural structures and the consequences of their impacts upon each other. 2. Logical Structure: It addresses the factorization of the problem domain without regard for physical components. The logical structure defines the identification of generic constructs within the system's architecture. 3. Physical Structure: It addresses the issues surrounding the physical entities of the system and their relationships with each other. It serves to define the decoupling and componentizing of physical entities within a multi-developer environment (for example, a multi-module application versus a monolithical application). 4. Social Structure: It defines how the development team is to be organized and how the roles within the team are to be distributed with regard to know-how and experience. 5. Reflective Structure: It captures the self-describing aspects of the system in terms of meta-data, team know-how, or an interface and implementation repository. 6. Extension Structure: It encompasses everything that is needed for the system's customization and extension. 7. Usage Structure: It determines how the developer's use what and when and how reuse is to be implemented. 8. Source Code Structure: It governs how the development team's entire code base is managed and administered. 9. Generation Structure: It defines the automatic construction of the system, its parts, and its configuration. 10. Run-Time Structure: It defines how the system is to be set running and how it is to behave over a period of time. 2.2 Are The Architectural Structures Real ? Speaking from our own experiences, architectural structures are: 1. invisible 2. difficult to explain and to visualize 3. dangerous for a project if they are ignored (aside from their invisible quality) Nevertheless, the structures described inherently exist within a large system design. They should constantly be discussed and taught since they are the only overall structures that provide a system overview and reflect a system's design quality. In the context of motivating a system's architecture, we use the following working definition to position the described architectural structures: an inherent ordering of the parts of a whole into an organized arrangement. At least under this definition, the consequences of an organized arrangement of a software system into architectural structures is real. These structures give us four problems to solve within an system's architecture: 1. How do we find these structures and explain their consequences ? 2. How do we make them explicit, i.e. programmatically and visually ? 3. How do we render their relationships also explicit and programmatically and visually determinable ? 4. How do we determine and improve the system's design quality based on these structures? The next section presents an attempt of visualizing the set of architectural structures in the context of a multi-dimensional dependency diagram, and explains the relationships between these structures. 2.3 Visualizing Architectural Structures And Their Dependencies 2.3.1 Understanding the Diagram The diagram is a multi-dimensional decomposition: We look at a system's architecture - equally a complex structure as well as a complex process - from different point of views in the domain of large systems design. All the mentionned architectural structures are equally important: The weight of a structure may vary, but you will not be able to abstract it away through some secret "process" that brings the structures into a nice and convenient order. Quite contrary, the interconnections between these structures will be with you throughout a large system development. When instantiating the diagram for a real-world problem, you will see that the problem touches several of the architectural structures at the same time. The structures are not meant to create fixed boxes; they are no final division of a large system's architecture. Essentially, they should remind you about aspects that have been important in developing large systems. So do not waste too much time arguing about, if certain aspects belong to this or an other architectural structure. Rather, uncover their consequences to other pieces of the system and make sure you do not forget them during development. 2.3.2 The Architectural Structures Dependency Diagram The following diagram depicts the set of architectural structures and their dependencies upon each other. Down arrows symbolize the impact of an architectural structure upon another; mutual dependencies are indicated with a single arrow on each end of the dependency. The annotations on the diagram's edges describe the key aspects of a structural dependency upon another. (see attached diagram) When building the analytic structure based on the client's requirements, you should already focus on the resulting software product as well: the consequences (or importance) of defined hotspots (for example, extensibility, physical structure, and reusability) must be determined-in a first iteration-for all the structures within the overall design of the system. We call this weighing. At this point, the social structure should be addressed in order to define the know-how needed for the following design phase, to uncover potential conflicts such as skill and technology shifts, changing working conditions, and organizational issues among the client, end-users, and the IT staff. The logical structure is derived from the analytical structure in an obvious way. The identified key abstractions and generic constructs will be used to specify the extension structure. Also, the business part of the reflective structure should be available at this point. In addition, the logical structure influences the physical structure, since you cannot transform the resulting business object model (BOM) into an implementation object model (IOM) in a trivial way most of the time. The design of the physical structure requires detailed know-how and experience of the target and implementation environment. Input must be provided from the social structure, for example, in terms of considering the number of developers involved and decreasing the resulting dependencies in order to minimize compile-time; the extension structure, for example, in terms of modeling extension concepts and mechanisms. Since the physical structure determines the components, their collaborations, and the chosen implementation technique, the run-time structure (in terms of which components will be used when, where, and how), the source code structure (in terms of managing the component source code), as well as the reflective structure (in terms of providing run-time component information) will all be influenced. 3. Architectural Structures And The Software Development Process We argue that during any comprehensive software development process, it becomes vitally important to consider the set of architectural structures and their impacts upon each other early-on and continously during the development process. The following principles guide us in linking the set of architectural structures with the software development process: 1. Simultaneousness / Parallelity: Domain analysis and software design have strong impacts on each other. Therefore, the consideration of the architectural structures within the development process needs to happen in parallel and not in a chronological, sequential fashion. Moreover, this should happen early on, ideally during the analysis phase, or at least during the logical design phase. 2. Completeness: Not all the architectural structures have to be implemented within a system's architecture, but they should all be considered within the development process early-on. 3. Weighing: With respect to user requirements, a weight should be assigned to the importance of a particular architectural structure within the context of the system's architecture. This enables us to instantiate the structure diagram and use it as target diagram. 4. Constant Tracking: As the development process progresses, the state and the importance of the architectural structures for the system's architecture should be tracked constantly. This will enable the development team to derive a OO system design rating - a measure of the quality, completeness and the tractability of their efforts. 5. Definition of Mechanisms: For each architectural structure under consideration, the development team should be able to define mechanisms that render transparent the implementation of this structure. Their combination leads to a concise description for the underlying architecture and the development process. Ideally, the by-product of this meshing of the architectural structures, the software development process, and the user requirements could be a hand-book for the development of the software system. It will tell the development team, for example, how the source code should be structured; how the software is to be extended; how the work of each developer can be decoupled from the work of the other developers, aso. 4. Conclusion The consideration of the set of architectural structures defined in this paper augment the software development process by making transparent properties within the architecture of a large system that are usually invisible, difficult to explain, and hard to visualize. In this sense, architectural structure are not design patterns [2]; rather, they are structures of a larger granularity in whose implementation design patterns could be used. The architectural structures enable designers and implementers of large systems to decompose the system's requirements into several categories of structures, and consequently to derive a system architecture that is sophisticated, comprehensive and of reliable quality. 5. Authors Walter Kriha, Daniel Kesch, and Stephan Pluess are all project architects for SYSTOR Corporation in Switzerland. The have been developing applications and architectures for large banking projects for several years. 6. List of References [1] Kruchten , P., Software Architecture & Iterative Development, RATIONAL, Rev. 9, July 27, 1994, Vancouver B.C. V6P 5H2 [2] Gamma, E., et. al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Publishing Company, Reading, MA, 1995