I was so taken aback by the comments on this volume that I could not resist a retort. First, SEI transformation methodologies are abstract by intent. They are not how-to methodologies or roadmaps for composing class structures, web sites, or a coding guideline standard. The ATAM is immensely valuable for collecting and rating architectural drivers from stakeholders using a very novel approach to tradeoffs. We actually augmented the process with Force-field analysis templates to speed up the tradeoff process. Also, OAR is designed as a guideline to harvesting and rehabilitating pre-existing system components not for a detailed analysis of a systems component code-base. Again, this is not a coding guide for those of us who are new to the architectural profession and are thinking in code-modelling terminology. Last, (but of greatest concern), is the use of SEI transformation methodologies for plotting logical and physical design. They are not intended to be used for this level of design work. (One might compare this to the misanthropic notion of using BPMN to design a network topology). Other than possibly CBAM, these are also not cost modelling methodologies. Comparing COCOMO II to CBAM is paramount to comparing an abacus to an accounting algorithm for future value. Sorry if I stepped on any toes...off the soapbox.

Скачать книгу бесплатно (pdf, 12.80 Mb)

---

Читать «Software Architecture in Practice (2nd Edition)»