At first the book appears to be a good attempt at formalising the basic models used in software architecture but then progressively deteriorates. While initally accepting the book's definition of the concept of the "Module Viewtype", I noted a fundamental error in what the book defines as a "view". While the concept of a "view" is the major underlying theme of the entire book, what the book refers to as a view is actually what we refer to as a "model" in the standard software architecture nomenclature. A view in the standard IEEE definition is more elaborate than what a view means in this book.
It is very important for the would-be reader of this book to note that what is repeatedly refered to as a "view" in this book is not a view at all but a "model".
This book, widely referred to as "The Bible of Software Architecture Documentation" (understandably because it is a tome, it is huge), covers in detail what can be described as "modelling patterns", a topic that is oft not covered in software architecture books. The book attempts to take the scientific/formal approach to qualitative modelling, allowing software architects to go beyond informal box and lines and ad-hoc UML models. It is an "in depth" coverage of "qualitative models" of software architecture used primarily to describe software structures. It does not go into the "quantitative models" that are oft used to describe non-functional requirements or service-level agreements.
In all its glory it specifies 3 types of qualitative models:
1. Modules (which are static and represent code). In the final incarnation of modules, we have a concept of a "virtual machine" or Layers.
2. Components and Connectors (which are runtime components that represent processes).
3. Allocation (which are static and/or runtime in nature and represent the placement of modules and components into an "environment").
Chapters 1 to 5 catalog the entire set of qualitative software architecture models the book presents, which is a very basic set of models, not at all comprehensive for the size of the book and its reputation as a "Bible". Chapter 6, or "Advanced Concepts" is a somewhat incoherent chapter on modelling techniques, mainly philosophy and unsubstantiated opinions. In its prologue, in a disjointed section titled "coming to terms", it actually tries to reconcile its main flaw of definining models as views by referring to a concept of "Architectural Views" and then refers the reader to other books on the matter (e.g. the Rational/Krutchten "4+1" approach to architecture, the Siemens Four Views etc) which is just weird considering this is supposed to be a book on software architecture.
Take note: if you're looking to learn about "Architecture Views", this book is not for you. It refers you to other well-known books on software architecture. If you want to learn something about the basic models of software architecture, such as: module diagrams, pipes and filters, client-server, deployment diagrams, and not much else, read on.
There are a lot of problems with this book. The one that stands out the most is that *it isn't* going to teach you how to document software architectures. In fact, it will more likely confuse you which is really a set back, that is, you come off worse than you were at documenting software architectures than you were before you took in the "pearls of wisdom" laid out in this book. In chapter 3, while it is describing the "component-and-connector viewtype" it tells you that an ESB is a "connector". I had to LOL. An ESB is a system in its own right, a messaging system to be specific, not a connector. I can imagine it can be viewed as such, but it really isn't (a connector). The connector would be e.g. HTTP (with SOAP payload) or a JMS Topic, but, I digress. In chapter 4, it says you can use class diagrams to represent component types and instances (i.e. runtime components). I don't agree with this modelling advice. Classes are static constructs. You don't use static constructs to model runtime or dynamic components. I understand it might work, but it's hardly scientific. You can get away with it because well, it's only a "qualitative model". It doesn't have to be executable. It then totally goes off tangent by saying that you can't use UML component diagrams to model "components". Another LOL. Why? The UML component is the best standard notation we have for modelling components. Why would you use a class to model a component instead of a component?
As I've mentioned earlier, chapter 6 is not good, it's just a series of bad ideas. Their concept of a "view packet" is the same as a "viewpoint" in the standard nomenclature (i.e. IEEE). Their concept of a "viewtype" is actually "model type", having nothing to do with what other software architecture books refer to as a view. Total chaos and confusion here. They totally confuse the concepts of models and viewpoints. They spin off a lot of in-bred philosophy and it's just not good if you're on the path to being an effective software architect. Further on in chapter 6 (section 6.1.3.) it then changes the definition of a "view packet" from what most software architects would understand as "viewpoint" to what most software architects would understand as a "model". The author is totally confused. In chapter 6, tha author(s) try to describe modelling of the all-important Context Diagram. They say you can use UML use-case notation to document a Context Diagram. Wrong. Context diagrams do not embody functions, which is what use-cases are. Context diagrams are about the system's interaction with it's environment or "context", in fact, the opposite or inverse of use cases. Note: Use-case diagrams are NOT context diagrams. With use-cases, you are delving (or hoping to delve) into funtionality, specific implementation paths "in" the system. A context diagram is a "black box" of the system looking "out" of the system. At this point (end of chapter 6) you get the realisation that their whole approach to models (or "views" as they call it) is rather unscientific.
Miracles do happen, if you believe. So I kept on reading and chapter 7 is indeed one. It is titled "Documenting Software Interfaces" and if there's any reason at all to read this book, it is this chapter. A very educational chapter on documenting software interfaces. A salient and most powerful point of chapter 7 is that "interface specification" should not just include syntactic informatioan (signatures, API...) but it *must* also specify semantic information (behaviour). It gives the very good advice of including a seperate interface specification for each model you create in your software architecture. Figure 7.1 titled the "Element Interface Specification" is instructive. Also, Figure 7.2 titled "A classification of exceptions associated with a resource on an elements interface" is a priceless chart for thinking about the causes of bugs or exceptions in software when having difficulty locating the source of a problem. A priceless design tool in my opinion. If you buy this book, make sure to read chapter 7, it is an excellent and thorough chapter on documenting software interfaces.
Chapter 8 is not bad. It basically covers scenarios and sequence diagrams. Chapters 9 and 10 are wrap-ups of what has been discussed in the preceeding chapters.Chapter 11 is about "other views" which is somewhat hilarious because this book isn't about architectural views, however, chapter 11 will point you to other books or literature that do cover architectural views (i.e. the reason you bought this book titled "Documenting Software Architectures: views and beyond").
The End.
I do not recommend you buy this book except you want a very good take on documenting software interfaces (i.e. chapter 7). The book is fundamentally flawed for its purpose.
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
この商品には新版があります:
他の国からのトップレビュー
Sijuola Odeyemi
Glorified Incompetence.
2017年6月6日に英国でレビュー済みAmazonで購入
Mike Tarrani
Should be an establish standard for documenting
2002年10月7日にアメリカ合衆国でレビュー済みAmazonで購入
Dr. Gernot Starke
Höhen und (schlimme) Tiefen
2007年5月23日にドイツでレビュー済みAmazonで購入
Mark Liversedge
Could have been so much better
2003年12月17日に英国でレビュー済みAmazonで購入
Mr. L
Rich book that deserve to be read
2010年9月25日にアメリカ合衆国でレビュー済みAmazonで購入
