nach oben

2024 | Buch

Kapitel lesen Erstes Kapitel lesen

Software Architectures

Topics Usually Missed in Textbooks

verfasst von: Manfred Nagl, Bernhard Westfechtel

Verlag: Springer Nature Switzerland

Enthalten in: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Einloggen, um Zugang zu erhalten

Über dieses Buch

This textbook concentrates on processes, activities and results related to software architectures. It describes the separation of architecture artefacts corresponding to their nature, their logical or their modeling level on one hand and at the same time emphasizes their integration based on their mutual relations. Design or development processes demand for integration, as different artifacts must be elaborated, which are mutually dependent and need to be in a consistent form.

The book is structured in four parts. The introductory Part I deals with the relevance of architectures, the central role of the design subprocess both in development or maintenance, and the importance of the decisions and artefacts in the overall result. Another topic is the spectrum of views an architecture language has to offer, and that there are different architectures to be regarded, from abstract and static to detailed, technical, and specific. Part II then discusses “important topics” onthe architecture level. It deals with adaptability especially for embedded systems, with integrating styles/ pattern notations, with different reuse forms and how to find them, with the role of architectures for integrating different existing systems, and with reverse and reengineering of legacy systems. Next, Part III covers architecture modeling and its relation to surrounding activities, as well as architectures to surrounding other results. The single chapters are on transformation between requirements and architectures, architectures and programming, architectures and project management and organization, as well as architectures and their relations to quality assurance or documentation. Eventually, Part IV summarizes the main messages and presents open problems, both for every single chapter and across chapters.

Every chapter focuses on a specific problem it addresses, a question it answers, the attention it demands, a message it conveys, and further open questions it raises. The chapters are mostly independent, which implies a certain redundancy, yet it allows lecturers (and their students) to either use the book as the basis of teaching software architecture or design, or to just pick those aspects that need special attention in a more advanced course.

Inhaltsverzeichnis

Frontmatter

1. The Architecture is the Center of the Software Development Process

Abstract

The purpose of this chapter is to explain the specific role architecture modeling and the resulting architectures have in software development projects: The processes are only possible by extracting the essentials of the system and denote them separately on architecture level. The architecture is the most important collection of artifacts, as the architecture influences most of the results gained in the process in a more or less substantial way. The architecture not only determines the structure, the quality, and the clearness of the system to be constructed or maintained. It also influences the structure, quality, and clearness of the code, of quality assurance, documentation, and of project organization.

From this central importance of architecture modeling and the resulting architecture, we continue with further aspects as sketches: The architecture determines the adaptability of the system, the architecture is the key for project organization, the architecture determines whether maintenance is possible (also via reverse and reengineering), and it determines the level of reuse. All these further aspects are later explained in more detail and in own chapters.

Manfred Nagl

2. An Integrative Architecture Language Approach

Abstract

This chapter is on one hand a survey on /Na 90/ and newer results. On the other, it summarizes the integrative nature of the approach to architecture modeling presented there. Different views and aspects are brought together, which all are important, when building up or changing an architecture: the static part (how to compose components with connectors), the different paradigms and abstractions, which are used (locality, layers, object-orientation), bigger parts as subarchitectures and subsystems, and various patterns to be followed. Further and important aspects like semantics, concurrency, abstract connectors and their different realization mechanisms, distribution, and different styles are also regarded.

We follow the guideline, that if different artifacts are used, the relations between them must be clear and obvious. Furthermore, all fragments, artifacts, and documents - for architecture modeling as well as for other working areas of software development - must build up an easy to understand product model for the system to be constructed or maintained. Both ideas come from the architecture for buildings (standard views and building information model).

Manfred Nagl

3. Sequences of Architectures from Abstract to Details

Abstract

The architecture of a software system consists of different artifacts with hierarchy and other dependency relations between them. This architecture is developed in stages. It starts with an abstract and conceptual form and ends with a concrete form with many details, describing various technical topics of the shipped system.

This chapter deals with the specific question, how these stages of the architecture have to be organized. What is the order of these architectures and what are the relations between them? The order is connected to the methodology of the design process, to the properties of the resulting design (e.g. adaptability), and also the type of system to be developed. The underlying architectural language should be able to express these relations. Two examples are discussed, one from business administration and one from embedded systems

Manfred Nagl

4. Embedded Systems: Rules to Improve Adaptability

Abstract

Embedded systems have specific properties, which are consequences of the application domain, namely the close connection to the underlying technical system, the specific challenges of the development process, the mixture of persons involved in their development, etc. Thus, adaptability (portability, extensibility, and changeability) is more difficult compared to other types of software systems.

The chapter addresses the question, what we can be do to improve adaptability of embedded systems. We study different examples of embedded systems. A series of hints is given. Most of them are related to the abstract architecture, i.e. the first result of the design process. The hints are also helpful for other higher-level tasks, such as integration of embedded systems, developing families of embedded systems, finding opportunities for reuse, and alike.

Manfred Nagl

5. Architecture Styles: Do they Need Different Notations?

Abstract

Styles or patterns for software architectures look very different. Any of them seems to open a new world. We try to discuss the commonalities by tracing them back to the traditional approach for software architectures used in this book. We do this for some cases and hope that the reader is convinced that it can also be done for the remaining ones. We are sure that the discussion how to trace back can also be conducted for other approaches of ‘standard’ software architectures. As a result, we see that styles/ patterns, although looking different at first sight, have a lot in common with classical concepts.

In this chapter, we concentrate on styles. Tracing back a style notation N to a ‘standard notation’ N_S is done for three different modes: In some cases (example data flow) the notation NS is more detailed and delivers more accuracy than N. In other cases (event or distribution architectures) written down in a more technical notation, N_S is more abstract. Finally, N and N_S can be on a similar level of abstraction (N-Tier, Blackboard), but NS is again more precise. So, the answer to the question of the title is No \( \underline{and} \) Yes.

Manfred Nagl

6. Process Interaction Diagrams: More than Chains or Transport Networks

Abstract

Process modeling is a broad field of research in different application areas, especially in informatics. Corresponding notations (transport networks, etc.) usually contain sequences, splits and joins of processes. Between processes there are dependencies, which can have quite different semantics. These semantical relations are usually not explicitly expressed.

In this chapter, we focus on a notation for a process, which has different aspects influencing the process, not only the input. This allows to connect different processes in specific ways, making clear what purpose the connection has and, thereby, characterizing different kinds of dependencies between processes. This extended notation we call process interaction diagrams (PIDs). We can express standard interactions of processes more precisely and are also able to express nonstandard forms of interaction.

These diagrams can be applied in different domains, as mechanical engineering, informatics, etc. Interesting and complex interactions can be studied. The notation can be used for different levels of processes, as lifecycle level, project management of development teams, etc. The usual process notations are extended to express interactions like “a process creates a tool to be used in another process”.

Manfred Nagl

7. Characterization of Shallow and Deep Reuse

Abstract

Reuse in software development avoids to carry out the same processes again and again, thereby being more efficient, i.e. faster and producing less errors. We call such forms shallow reuse, as reuse is mostly in the mind of developers. Deep reuse means to change the development process remarkably, because upcoming knowledge makes more or less big parts of the development superfluous. Examples are that components and frameworks from former developments are used, steps are automated, etc.

In this chapter, we try to clarify the difference of shallow and deep reuse. Furthermore, we characterize the changes due to reuse on three levels: the new product with improved reuse, the change of the development process, and the new parts to be reused in the future. The notation for processes makes the changes and the dependencies of subprocesses more evident.

We take the multiphase compiler as running example. It is one of the best studied software products, a good example for the combination of theory and practice, and also of deep reuse.

Manfred Nagl

8. The Software Architecture is the Glue for Variety and Integration

Abstract

Whenever a software system consists of different parts – either how they are internally developed and structured, where they are located, when they were developed, which methodology or underlying concepts are used – the problem of integration of these different parts comes up. This chapter shows that the architecture of a software system is the right level to organize the integration and the architecture provides the essence of the glue for the integration.

We give different examples, which show the glue for different situations either in development or in maintenance, in different application domains, using higher or low-level infrastructures, for integration within a system or between a system and its environment, or for a framework applying reuse for its major application components. The ideas are applicable also in other domains outside software development and in the context of model-driven development.

Manfred Nagl

9. Reverse and Reengineering for Old Systems is Seldom Complete

Abstract

The chapter describes two different and practical reengineering projects – one for business administration and the other for mobile phone control software – on a textbook level. Underlying are three doctoral dissertations /Cr 00, Ma 05, Mo 09/. As the example projects are completely different, from the application domain on one side and from the structure of the systems to be reengineered on the other, we believe that the experiences we acquired are more than just two examples.

The chapter emphasizes that a complete reengineering of a system is rather rare due to pragmatic reasons. Therefore, we have to handle changes, which preserve the value of a big part of the system and at the same time offer the necessary and wanted extensions for improved functionality and quality.

Manfred Nagl, Bernhard Westfechtel

10. Process and Model Transformations on Different Levels

Abstract

This chapter consists of three parts. The first is on lifecycle processes and their relation to the working area graph model WAM. The second gives principal remarks on abstraction levels of processes, their products as partial results, and their integration to the overall configuration. The third part discusses, what development and changes mean on that configuration, and why transformations between results of different working areas are specifically important. In this chapter, we discuss those transformations, where the architecture of the system to be developed or changed is involved.

Altogether, the purpose of this chapter is the preparation for the following chapters 11 to 14. Finally, we shortly characterize these transitions/ transformations, which are discussed in these chapters.

Manfred Nagl

11. Transformation from Requirements to Architectures is not Automatic

Abstract

After we have discussed the relation of architecture modelling to all surrounding working areas, from requirements engineering to management in chapter 10, we go deeper now by investigating the specifics of the transformation from requirements engineering to architecture modelling. This is the most interesting transformation. In section 1 of this chapter, we summarize again the central role of the architecture and which problems still remain. Section 2 discusses, that the upper part of the architecture „can be derived“ from the requirements specification by the architect making interactive decisions. The lower parts more correspond to technical decisions. Section 3 addresses the transformation RE to AR for a classical requirements spec. In section 4, we study this transformation for an OO requirements spec; the ideas are rather similar. In both cases, we see that there are various possibilities for the mapping, such that the architect has to map interactively. Section 5 sketches the transformation for an embedded system, where even more technical details have to be regarded. Section 6 discusses the rare case that the transformation can be automated, which demands for a long period of gaining experience. This altogether explains the title of the chapter. Section 7 gives a summary and open problems.

Manfred Nagl

12. The Architecture is the Blueprint for the Code

Abstract

This chapter explores the relationship between architectural design and programming in the small. Compared to relationships to other working areas such as requirements engineering or quality assurance, the architecture and the implementation of a software system are coupled tightly: The architecture serves as a blueprint for the implementation of the software system to be developed. Essentially, the architecture defines the skeleton of the system that is complemented with code written by programmers. Accordingly, the conformance of the implementation with the architecture may be defined by a set of consistency relations. Finally, different variants of processes describing the coupling between activities in the working areas architectural design and programming in the small are elaborated and compared.

Bernhard Westfechtel

13. Architecture-Centered Project Organization

Abstract

Project organization is a working area that is concerned with the management of products, activities, and resources in software projects. Project organization is the only managerial working area in the lifecycle model used throughout this book, and is addressed by disciplines known as project management, software configuration management, or process management.

In contrast, architectural design belongs to the class of technical working areas. Like all other technical working areas, architectural design is controlled by project organization. Conversely, architectural design strongly impacts project organization, particularly with respect to implementation and quality assurance. Accordingly, we present a management approach that acknowledges the central role of architectural design, but also takes the importance of other working areas into account.

Bernhard Westfechtel

14. Quality Assurance and Documentation Related to Architectures

Abstract

In this chapter, we regard the connections of architectures to quality assurance and to documentation. Both are different, but the relations to architectures share some similarities. The study can be extended to all technical working areas (RE, AR, PS) and accompanying working areas (QA, DOC and PO). We restrict the discussion here mainly to architectures, according to the title of this book. First we make clear what we understand by quality assurance and by documentation. This is especially necessary for the term documentation, for which different definitions exist.

Different examples for documentation and quality assurance are given, in order to get an overview of how they are related to architectures on one side and on the other, what typical situations between documents, their increments, and subconfigurations exist. The detected similarities give arguments why both are discussed here. Thus, this chapter is not about documentation and quality assurance in general. It concentrates on architectures and there on the parts of the overall configuration corresponding to documentation and quality assurance.

Manfred Nagl

15. Summary, Lessons Learned, Messages, Open Problems

Abstract

In this chapter we sum up in four sections. The first deals with the messages, summaries, and lessons learned. This is done chapter by chapter. The second gives statements/ messages, which are valid for different/ all chapters. The same is applied to open problems: chapter by chapter in sect. 3 and across chapters in sect. 4.

Manfred Nagl, Bernhard Westfechtel

Backmatter

Titel: Software Architectures
verfasst von: Manfred Nagl
Bernhard Westfechtel
Verlag: Springer Nature Switzerland
Electronic ISBN: 978-3-031-51335-0
Print ISBN: 978-3-031-51334-3
DOI: https://doi.org/10.1007/978-3-031-51335-0

Springer Professional

Über dieses Buch

Inhaltsverzeichnis

Frontmatter

1. The Architecture is the Center of the Software Development Process

2. An Integrative Architecture Language Approach

3. Sequences of Architectures from Abstract to Details

4. Embedded Systems: Rules to Improve Adaptability

5. Architecture Styles: Do they Need Different Notations?

6. Process Interaction Diagrams: More than Chains or Transport Networks

7. Characterization of Shallow and Deep Reuse

8. The Software Architecture is the Glue for Variety and Integration

9. Reverse and Reengineering for Old Systems is Seldom Complete

10. Process and Model Transformations on Different Levels

11. Transformation from Requirements to Architectures is not Automatic

12. The Architecture is the Blueprint for the Code

13. Architecture-Centered Project Organization

14. Quality Assurance and Documentation Related to Architectures

15. Summary, Lessons Learned, Messages, Open Problems

Backmatter

Premium Partner