Software Architecture: Foundations, Theory, and Practice

by Richard N. Taylor, N. Medvidovic, E.M. Dashofy

Software architecture is foundational to the development of large, practical software-intensive applications. This brand-new text covers all facets of software architecture and how it serves as the intellectual centerpiece of software development and evolution. Critically, this text focuses on supporting creation of real implemented systems. Hence the text details not only modeling techniques, but design, implementation, deployment, and system adaptation -- as well as a host of other topics -- putting the elements in context and comparing and contrasting them with one another. Rather than focusing on one method, notation, tool, or process, this new text/reference widely surveys software architecture techniques, enabling the instructor and practitioner to choose the right tool for the job at hand. Software Architecture is intended for upper-division undergraduate and graduate courses in software architecture, software design, component-based software engineering, and distributed systems

Genres: Architecture, Programming, Technology, Technical, Software, Computers, Nonfiction

750 pages, Hardcover

First published December 1, 2008

Reviews

[Horia · Rating 2 out of 5]

This is a nice read for someone entering the software architecture domain. However, I would not recommend it as a reference book for a software architect without serious development experience for the following reasons:

- it tends to be a little to abstract (for a 700+ pages book I would expect to have at least an example for every concept)
- the "further reading" sections seem to be presenting the sources of the chapter (instead of giving useful/actual references to articles that would expand on the presented subjects)
- there's a compatibility matrix in the connectors chapter and it doesn't make any sense just by reading the text rendering it unusable
- some chapters are unconvincing (chapters about implementation or about security come to mind)
- sometimes it goes into detail to the code level and sometimes it stays at a very abstract (unpractical) level when making a point
- most of the times the recommendations/suggestions/guidelines are common sense (which is good in my opinion), but they are explained in too much detail which makes the reading boring.
- and another one... the assumption of the book is that you use sw architecture for big applications. And the examples are based on Lunar Lander? I doubt that one can explain every strength/weakness of architectural styles based on just that.
- and by the way... is the C2 style even used in practice???

[Alex Ott · Rating 3 out of 5]

Tedious book about architecture-related details, but not about how to create great architectures... Nothing new for experienced software developer...

[Barack Liu · Rating 5 out of 5]

464-Software Architecture-Richard Taylor-Technology-2008

Barack
2023/04/16

"Software Architecture", first published in 2008. This book covers all aspects of software architecture and how it serves as the intellectual core for software development and evolution. The book details not only modeling techniques, but also design, implementation, deployment, and system adaptation—and many other topics—putting elements into context and comparing and contrasting them with each other.

Richard Taylor, born in 1952, studied at the University of Colorado and is currently a Professor Emeritus of Information and Computer Sciences at the University of California at Irvine.

Table of Contents
1. The Big Idea
2. Architectures in Context: The Reorientation of Software Engineering
3. Basic Concepts
4. Designing Architectures
5. Connectors
6. Modeling
7. Visualization
8. Analysis
9. Implementation

Studying software architecture, that is, studying the composition of software, is similar to studying the composition of a building. It's just that buildings are tangible, and their structure is easier to understand intuitively; while the software is intangible, its structure is relatively more abstract. When we learn unfamiliar things, we often need to make analogies with familiar things, especially when we are learning intangible abstract concepts. A good software architecture is to software what a good engineering structure is to architecture. When we build a bungalow, the difference between good and bad architecture may not be obvious. On the contrary, good architecture may take more time to consider and design, and it may appear to be less efficient than bad architecture in terms of efficiency. But as soon as we try to build more complex software systems, the difference between good and bad architectures becomes apparent immediately. If you want to build a 100-story building, whether the building is stable or not has been decided when the design drawings have been completed and the ground has not yet broken.

Different architectures serve different design purposes. Just like houses, some houses are used for the purpose of living comfortably in daily life; some houses are used for the purpose of resisting invasion. The same goes for software design. And if we want to know the main purpose of the software, we need to know who our target users are. Only by clarifying this first can we clarify which functions are necessary and which functions are relatively minor. So entrepreneurship is like this. Who is the product that we invest time, energy, and money to develop, and who is willing to pay for it? Perhaps during school, what we did was more out of training considerations or personal preferences. But when we get out of the campus, we must start to make money for the purpose of doing things. Even if money is not the primary purpose, it must be the top three goals. It's like we need to know where the target is first, first have the target, and then shoot the arrow. Subsequent iterative updates are also based on the needs of target users.

Structures are often traceable, and some of the classic structures will be handed down to form a certain paradigm. Also, take architecture as an example. When we mention carved beams and painted buildings, Gothic buildings, and skyscrapers, most people will have a certain picture in their minds. Although these particular pictures are not identical, they do share some major similarities. And these different people can conceive pictures with common characteristics just based on a noun, which is actually a paradigm. If we want to propose our own paradigms, we must first be familiar with the classic paradigms of our predecessors, unless we are gifted. This is why we always emphasize a solid foundation. The so-called foundation is to have a deep understanding of the classic paradigms of the predecessors and to be able to make horizontal and vertical comparisons. A low-level understanding may be a half-knowledge of specific paradigms, half-understood. The second level of understanding may be that the existing paradigms are very clear and familiar. And the third-class state is probably already able to create a new paradigm by itself.

It is easier for us to have a stronger intuition about whether a building structure is good or not, because we have been exposed to buildings since childhood, so we naturally have this sensitivity. But for the judgment of software architecture, this intuition is not obvious. The main reason is probably that we see too little. The so-called feeling is actually the subconscious mind that tries after the accumulation of experience reaches a certain level. The more we see, the more we feel, and the more accurate and powerful a sixth sense we develop about the subject. Since software architecture is abstract, our understanding of it must first be based on the ability to understand abstract concepts. It is true that we can visualize abstract concepts as much as possible through diagrams and other means, but in general, the ability to understand abstract concepts is still the cornerstone. Therefore, we should not only look at the existing classic paradigms but also strengthen our ability to understand abstract concepts.

Another powerful tool when studying software architecture is standardization. After we abstract an entity into a module, we should use it in a unified and standard way, which is the interface in the software system. That said, even when we have tens and hundreds of thousands of modules, we still pretty much only have to remember one way to use them. When we look at various professional fields, many terms, norms, and protocols are defined in them. These standardized definitions are to allow different groups of people to do things under the same rules at different times and in different places. Under a framework, collaboration according to the rules of the framework is actually the same as the organizational structure of society. If any human organization wants to function, it must have norms, so that people can be organized. A good organizational structure can make this group more powerful as the number of people increases. With an immature structure, when the number of people participating in the system becomes larger, the power of the collective may be reduced instead.

When we refer to software architecture, we need to understand that no single line of code can represent this architecture. The collection of all these codes is logically organized together. The logic that organizes them is the architecture. To build a high-rise building, you have to look down from a high place and overlook the whole picture so that you can forget the details and only keep the shape. The understanding of architecture should be two-way. When we read through all the code of a project, we must be able to dig out the details in our minds and think about how the system is organized. And when we look at a design drawing, we must be able to imagine the general details, which modules, objects, and methods may need to be used.

There are more than a dozen common classic software architectures alone. We need to understand, what are their applicable scenarios, when are they suitable for use, and what are their advantages and limitations. This comparison is conceptual. We also need to be able to extract from actual examples to identify the architecture used in this example. Given a known system, it may not necessarily be a standard architecture as defined in the concept, we need to be able to capture the essence of this model. In the end, our goal should be to design our own architecture, because all learning must ultimately be used to solve problems. On the premise of known problems, we need to be able to design a system by ourselves, and we should have the ability to work in these numerous architectures. Choose the architecture you think is appropriate, and you must be able to instantiate the standardized architecture in this specific problem.

[Mehnna]

https://www.goodreads.com/book/show/6...#

[Jennie · Rating 2 out of 5]

I think this was the first textbook that I ever had to read entirely through for class. Lots of theory.

[Rojin Rg]

jkk

[Eugene Hlyzov · Rating 4 out of 5]

Great theory book about software architecture. It would be fair to exclude "Practice" from the title though.

[Mohammed Morab · Rating 5 out of 5]

Hope i can find what i am looking for in this book

[Kev · Rating 5 out of 5]

This is the best book available on software architecture.

[Masum Hussain]

thanks

[Amal Tahri · Rating 4 out of 5]

Any software architect, or alleged to be, must read this book.