Showing posts with label software architecture. Show all posts
Showing posts with label software architecture. Show all posts

Applied Software Product Line Engineering Review

Applied Software Product Line Engineering
Average Reviews:

(More customer reviews)
The authors of this book represent an all-star lineup of the best of the best in the Software Product Line Engineering (SPLE) field. They do a great job of providing a snapshot of the current SPLE best practices in the industry today.
Each chapter is written by a different author, or team of authors. This leads to some different perspectives on SPLE. This works for this type of book, but it does provide a conflict in the points of view taken in certain chapters. If you have experience with SPLE this shouldn't be an issue because you will already understand what those different views are, but for someone with little or no experience this could cause confusion. I found none of the points of view wrong, just different. Different domains require, and provide for, different approaches.
I recommend this book to those that are experienced as a guide to the evolution of the topics covered, and to the beginner I would use it as a road map of topics you should learn more about in order to get the full understanding behind each chapter. Each chapter provides an excellent reference section.
I would suggest also reading the following books. They provide more information about the material covered in some of the chapters.
"Software Product Lines: Practices and Patterns" is mentioned several places in the book. It is key to getting a more in-depth look at the 29 practice areas and the patterns that help to apply them.
"Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures" goes in-depth into the use of Product Line UML based Software engineering (PLUS). UML and PLUS are mentioned several places in the book. PLUS is what I use when I build a software product line. I have created a UML stereotype in SPARX EA which you can download. Just google "UML STATIC MODELING IN PRODUCT LINE ENGINEERING (PLE) with SPARX EA".
The table of contents is below.
ORGANIZATIONAL AND MANAGERIAL ISSUES
Software Product Line Engineering: Overview and Future Directions
A Roadmap for Software Product Line Adoption
New Methods behind a New Generation of Software Product Line Successes
Evaluating Product Family Development Using the Balanced Scorecard Approach
Product Management for Software Product Lines: An Overview
METHODOLOGIES AND PROCESSES
A Systems Product Line Approach
Adoption of Software Product Lines to Develop Autonomic Pervasive Systems
Development of a Software Product Line for Validation
Environments
Building a Family of Compilers
Formal Verification and Software Product Lines
TECHNICAL ISSUES
Multiple-View Requirements Models for Software Product Line Engineering
Managing Flexibility and Variability: A Road to Competitive Advantage
Feature Oriented Analysis and Design for Dynamically
Reconfigurable Product Lines
Separating Application and Security Concerns in Modeling
Software Product Lines
Architecture as Language
INDUSTRY EXPERIENCES AND CASE STUDIES
Management and Financial Controls of a Software Product Line Adoption
Efficient Scoping with CaVE: A Case Study
Model-Driven, Aspect-Oriented Product Line Engineering: An Industrial Case Study
Evaluation of Design Options in Embedded Automotive Product Lines
Product Line in the Business Process Management Domain
I found the material covered to all be of great value. There are a lot of great case studies through out the book beyond the section of chapters that cover case studies. They help to take the practices covered from theory to reality.
My biggest pain point with this book is the index. It is just down right sad. I am not going to ding the book for something technical the editors missed. I have been very tempted to grab an electronic version to make up for its weakness', although I have not seen one for sale.
All in all if you are involved with Software Product Line Engineering at all, this is a mandatory read. Software Product Line Engineering is an evolving field and this book brings us up to date on the evolution of the field.


Click Here to see more reviews about: Applied Software Product Line Engineering

Over the last decade, software product line engineering (SPLE) has emerged as one of the most promising software development paradigms for increasing productivity in IT-related industries. Detailing the various aspects of SPLE implementation in different domains, Applied Software Product Line Engineering documents best practices with regard to system development. Expert contributors from academia and industry come together and focus on core asset development, product development, and management, addressing the process, technical, and organizational issues needed to meet the growing demand for information. They detail the adoption and diffusion of SPLE as a primary software development paradigm and also address technical and managerial issues in software product line engineering. Providing an authoritative perspective of the latest research and practice in SLPE, the text:Presents in-depth discussions and many industry / case studies Covers applications in various domains including automotive, business process management, and defenseOrganized according to the organizational, process, and technical aspects of software product lines within an organizationProvides the expertise of a distinguished panel of global contributorsEver-increasing global competition coupled with a fragile world economy means that the pressure is on for software engineers and software process improvement professionals to find ways to meet the needs of expanding markets-with greater efficiency and effectiveness. This book arms readers with the insight needed to harness the power of SPLE to increase productivity, reduce time to market, and to handle the growing diversity in the quickly evolving global marketplace.

Buy NowGet 14% OFF

Click here for more information about Applied Software Product Line Engineering

Read More...

Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives Review

Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives
Average Reviews:

(More customer reviews)
When it comes to the systems or software architecture, I subscribe to Tom Demarco's definition: "An architecture is a framework for the disciplined introduction of change." (http://www.systemsguild.com/GuildSite/TDM/Architecture.html). And while most of the job postings matching "architect" these days talk about the need for writing and testing code, there is a growing awareness in the industry that in order to build a resilient enterprise system an organization must look beyond design patterns and coding idioms. In addition to the technical challenges, building large enterprise system requires effort of many professionals during an extended period of time. This brings other non-technical risks into the picture.
This is one of the better books covering many issues that comprise System Architecture discipline in the light of their personal experience. The authors introduce us to an approach for partitioning architecture using Viewpoints (behavioral characteristics, e.g. Functional, Information, Concurrency, Development, Deployment, Operational) and Perspectives (nonfunctional aspects, e.g. Security, Performance and Scalability, Availability and Resilience, Evolution).
The first half of the book describes the discipline of Application Software Architecture, the second half contains two catalogs, one for Viewpoints and the other for Perspectives. Both catalogs describe concerns, artifacts (models), problems and pitfalls when focusing on a viewpoint or perspective.
I would qualify this book as a companion and reference for a beginner through intermediate level. It gives an excellent overview of what a system architect has to go through day in and day out to achieve success. The book contains a wealth of advice on what to pay and not pay attention to in any particular stage of the architectural development. The authors clearly speak from personal experience. Their examples are always to the point, although a bit sketchy with respect to details on techniques and artifacts and how to develop and use them. Considering the site of the volume, the authors did an excellent job balancing width and depth of coverage: trying to cover such a vast discipline in detail in a 500+-page book is not possible.

Click Here to see more reviews about: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives


Software Systems Architecture is a practitioner-oriented guide to designing and implementing effective architectures for information systems. It is both a readily accessible introduction to software architecture and an invaluable handbook of well-established best practices. It shows why the role of the architect is central to any successful information-systems development project, and, by presenting a set of architectural viewpoints and perspectives, provides specific direction for improving your own and your organization's approach to software systems architecture.

With this book you will learn how to

Design an architecture that reflects and balances the different needs of its stakeholders
Communicate the architecture to stakeholders and demonstrate that it has met their requirements
Focus on architecturally significant aspects of design, including frequently overlooked areas such as performance,resilience, and location
Use scenarios and patterns to drive the creation and validation of your architecture
Document your architecture as a set of related views
Use perspectives to ensure that your architecture exhibits important qualities such as performance, scalability, and security

The architectural viewpoints and perspectives presented in the book also provide a valuable long-term reference source for new and experienced architects alike.

Whether you are an aspiring or practicing software architect, you will find yourself referring repeatedly to the practical advice in this book throughout the lifecycle of your projects.

A supporting Web site containing further information can be found at www.viewpoints-and-perspectives.info


Buy NowGet 34% OFF

Click here for more information about Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

Read More...

Just Enough Software Architecture: A Risk-Driven Approach Review

Just Enough Software Architecture: A Risk-Driven Approach
Average Reviews:

(More customer reviews)
This a broad and deep book on all things software architecture except the architecting process (for process, one recommended read is "Process Software Architecting" by Eeles/Cripps). Several readerships will benefit from "Just Enough Software Architecture":
- As an experienced IT architect, I do not necessarily agree with everything in the book (this does not come as a surprise, as architects have opinions). That said, I certainly learned a lot that I can apply immediately on my projects and some of the more provocative statements challenge me to leave my comfort zone (or at least consider doing so).
- Junior architects can use the book both as a tutorial and as a reference when/while growing in their profession.
- Developers with a "who needs architects" mindset (hopefully) will understand architects and modelers much better after having read this book, and appreciate the value of archtecture.
Things I liked in particular:
- Overall vision and message of pragmatism sent
- The risk-driven approach increases chances to get accepted both in agile development and in more traditional architecture communities
- There is a lot of practical advice e.g. in Chapters 10, 11 and 15
- The author is in command of a large body of relevant related work (both industra and academia) and puts them in perspective adequately
- Editorial quality: structure, figures, command of the English language (some words and expressions a bit be hard to comprehend for non-native speaker)
Some room for improvements (2nd edition?):
- Not all metaphors and analogies work internationally, e.g. not all IT people are sports fans that follow baseball or know what a rookie is
- The connection between parts 1 and 2 could be a bit stronger, even if loose coupling generally is a good thing; e.g., some more backward references
In summary, I'd say Just Enough Software Architecture is a highly recommended read for every architect in touch with development reality and every developer with a desire to build complex systems that will stand the test of time.

Click Here to see more reviews about: Just Enough Software Architecture: A Risk-Driven Approach

This is a practical guide for software developers, and different than other software architecture books. Here's why:
It teaches risk-driven architecting. There is no need for meticulous designs when risks are small, nor any excuse for sloppy designs when risks threaten your success. This book describes a way to do just enough architecture. It avoids the one-size-fits-all process tar pit with advice on how to tune your design effort based on the risks you face.
It democratizes architecture. This book seeks to make architecture relevant to all software developers. Developers need to understand how to use constraints as guiderails that ensure desired outcomes, and how seemingly small changes can affect a system's properties.
It cultivates declarative knowledge. There is a difference between being able to hit a ball and knowing why you are able to hit it, what psychologists refer to as procedural knowledge versus declarative knowledge. This book will make you more aware of what you have been doing and provide names for the concepts.
It emphasizes the engineering. This book focuses on the technical parts of software development and what developers do to ensure the system works not job titles or processes. It shows you how to build models and analyze architectures so that you can make principled design tradeoffs. It describes the techniques software designers use to reason about medium to large sized problems and points out where you can learn specialized techniques in more detail.
It provides practical advice. Software design decisions influence the architecture and vice versa. The approach in this book embraces drill-down/pop-up behavior by describing models that have various levels of abstraction, from architecture to data structure design.

Buy NowGet 37% OFF

Click here for more information about Just Enough Software Architecture: A Risk-Driven Approach

Read More...

Software Architecture: Foundations, Theory, and Practice Review

Software Architecture: Foundations, Theory, and Practice
Average Reviews:

(More customer reviews)
Software Architecture: Foundations, Theory, and Practice is a landmark text that will become an essental introduction to the discipline of software systems architecture. If you are a student, tester, manager, methodologist, developer, or simply an architect, and want a holistic understanding of what real software architects think software architecture is and why it matters, this is the place to start.
I bought this after Roy Fielding (of REST and HTTP fame) mentioned it on the rest-discuss mailing list. Roy is one of the industry's top architects, and I wasn't disappointed. The book is timely - architecture is coming to be accepted as an important activity, especially for distributed, and large scale systems. What many people don't realize is that drawing pictures, writing documents no-one reads, meta-modeling, and pontificating on "concerns" are not software architecture. Software architecture is about introducing constraints via principled, objective design to achieve particular system properties. Architecture is difficult and exhausting work, but done well can offer immense value to users and stakeholders. This book, along with Rozanski and Woods' "Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives" makes that explicit.
The book is unapologetic about software architecture's standing in the industry. SAFTAP positions architecture as the primary design activity for software - not development, not requirements analysis, not testing, not methodology, but architecture. That will make for interesting debate.
My single criticism of this book is that it does not do enough to treat user experience (Ux) and informatics as architecturally significant, but not enough to take away a star. I'm hoping a future edition will rectify that.
Some noteworthy chapters in the book (there are 17 chapters in all):
* The Big Idea: explains what architecture is and why it matters. The building metaphor (often heavily criticised in the industry, see the excellent "Software is not Bricks" by Raganwald) is dealt with calmly and then put to one side.
* Architecture in Context: explains how architecture fits into the overall lifecycle and process of software systems.
* Connectors: this is one of my favourite chapters. The concept of a connector is vital to a software system, but is rarely if ever discussed in programming or engineering texts.
* Modeling: probably not what you think. This chapter emphasizes communication, clarity and disambiguation over notations and diagrams.
* Implementation: programmers hate the quip "implementation detail", but in truth many things in a system are just that and it does not mean they are unimportant. This chapter covers those details and why they matter.
* Deployment and Mobility: good architects understand that a systems have a life well beyond initial delivery, which is where most developers, managers and stakeholders tend to focus attention. This was one of favorite sections as the running system simply doesn't get enough attention in most projects today.
* Applied architecture and Styles: covers some examples of architectural styles, notably REST and SOA, which are certainly the best known architectures in my part of the industry.
* Designing for non-functional properties: many non-functional concerns don't start to matter until the system is deployed and there isn't always agreement among technical specialists over what's truly important. If you are technical specialist this should help you articulate the cost/benefit of looking at the "unfeatures" of a system.
* Security and Trust: software is increasingly distributed, and increasingly a super-system of components interacting over the Internet and Mobile Networks. So it's good to see a text that makes security a first order concern and not just a non-functional ones.
* Domain Specific Software Engineering: I'm trained as an industrial designer where the notion of common modular components with standard interfaces acting as a platform for product development is a known Good Thing in domains such as the automotive and consumer electronics industries. This chapter gives a good overview of modular design focusing on the software product lines approach. The example given is from Philips, but it could as easily have been from Toyota.
* People, Roles and Teams: software architecture, like other architecture disciplines, has a strong social dimension. This chapter explains how the architect role fits into an organisation and where they can add value and exert influence.

Click Here to see more reviews about: Software Architecture: Foundations, Theory, and Practice



Buy Now

Click here for more information about Software Architecture: Foundations, Theory, and Practice

Read More...

Documenting Software Architectures: Views and Beyond (2nd Edition) Review

Documenting Software Architectures: Views and Beyond (2nd Edition)
Average Reviews:

(More customer reviews)
Software architecture really is unlike any other aspect of its design. The architecture has deeper meaning and larger scale than any other aspect, and can't be discussed in the same ways.
This book opens that discussion. Among the "architecture" books I've read lately, this is the only one to offer concrete advice on describing, presenting, and analyzing archtiectural features of a system. It identifies a number of documentation types and variations. It also identifies a number of different readers - developers, future architects, users, etc. - and addresses their different documentation needs.
The authors use a little UML, but not a lot. For one thing, standard UML works at too low a level for architectural discussion. Classes, and even hierarchies of class inheritance are such fine-grained entities that architecture gernerally won't address them. Instead, the authors offer a number of diagramming styles of their own. For once, I agree with the need for non-standard notation.
Even so, I think they under-utilize the existing standards in favor of their own terminology and notation. They could have used a UML profile for lots of the discussion. It would have had to be a new profile, however, not just a force-fit of the real-time profile. They also under-used the existing architecture standards (IEEE/ANSI, DoD, NASA, and more) in favor of their own discussion. Maybe their approach can be used in any of those frameworks, but that should have been more explicit.
I see only one major flaw in this book, the assumption that a software system's architecture describes the program delivered to a customer. That's way too narrow. A large system includes things like test harnesses, debug instrumentation, application-specific QA tools, and user documentation of many kinds. Those can be major undertakings of their own. They are intimately tied to the delivered software, and may constrain the actual product.
On the postivie side, this book offer an extensive real-world case study. That probably doubles the book's value, by putting a concrete face on the otherwise abstract discussion.
There are two ways to use this book: you can agree with it, or think about it and disagree with it. If you really think about it, though, you get it's full value whether you agree or not.
In other words, you can't lose by reading this book.

Click Here to see more reviews about: Documenting Software Architectures: Views and Beyond (2nd Edition)

"This new edition is brighter, shinier, more complete, more pragmatic, more focused than the previous one, and I wouldn't have thought it possible to improve on the original. As the field of software architecture has grown over these past decades, there is much more to be said, much more that we know, and much more that we can reflect upon of what's worked and what hasn't—and the authors here do all that, and more." —From the Foreword by Grady Booch, IBM Fellow

Software architecture—the conceptual glue that holds every phase of a project together for its many stakeholders—is widely recognized as a critical element in modern software development. Practitioners have increasingly discovered that close attention to a software system's architecture pays valuable dividends. Without an architecture that is appropriate for the problem being solved, a project will stumble along or, most likely, fail. Even with a superb architecture, if that architecture is not well understood or well communicated the project is unlikely to succeed.
Documenting Software Architectures, Second Edition, provides the most complete and current guidance, independent of language or notation, on how to capture an architecture in a commonly understandable form. Drawing on their extensive experience, the authors first help you decide what information to document, and then, with guidelines and examples (in various notations, including UML), show you how to express an architecture so that others can successfully build, use, and maintain a system from it. The book features rules for sound documentation, the goals and strategies of documentation, architectural views and styles, documentation for software interfaces and software behavior, and templates for capturing and organizing information to generate a coherent package. New and improved in this second edition:


Coverage of architectural styles such as service-oriented architectures, multi-tier architectures, and data models
Guidance for documentation in an Agile development environment
Deeper treatment of documentation of rationale, reflecting best industrial practices
Improved templates, reflecting years of use and feedback, and more documentation layout options
A new, comprehensive example (available online), featuring documentation of a Web-based service-oriented system
Reference guides for three important architecture documentation languages: UML, AADL, and SySML


Buy NowGet 31% OFF

Click here for more information about Documenting Software Architectures: Views and Beyond (2nd Edition)

Read More...

Designing Concurrent, Distributed, and Real-Time Applications with UML Review

Designing Concurrent, Distributed, and Real-Time Applications with UML
Average Reviews:

(More customer reviews)
This book provides a practical method to apply the Unified Modeling Language (UML) to design concurrent and distributed software for large systems. While many books have been published to explain the details of the UML notation, this book provides a method, COMET, to approach software design through application of a practical subset of the UML notation. The book contains numerous, extensive case studies and provides pragmatic, useful guidelines to identify distributed subsystems and concurrent tasks from a UML analysis model. The approach described represents a unique and valualbe contribution by the author of this text. Finally, because this book is intended mainly as a text for software design courses, I consulted with a few students who have used this book in a graduate-level software engineering course. All of the students were favorably impressed with the content, clarity, practicality, and detail contained in the book.
Prior to the publication of this text, a software design course based on UML could only be taught using a UML text together with a separate software design text. In this text book, Dr. Gomaa has integrated material from UML and software design in such a form that a software design course can now be taught with this text alone.

Click Here to see more reviews about: Designing Concurrent, Distributed, and Real-Time Applications with UML

In this book, renowned real-time software expert Hassan Gomaa adapts UML to the unique needs of the concurrent, distributed, and real-time applications -- helping developers leverage the powerful flexibility, reliability, and time-to-market benefits associated with UML. Gomaa starts by reviewing the key issues and concepts associated with analysis and design of distributed and real-time applications -- focusing not only on standard object-oriented concepts such as information hiding, classes, and inheritance, but also specialized issues such as finite state machines, concurrent tasks, and real-time scheduling. Next, he introduces the COMET (Concurrent Object Modeling and Architectural Design) Method, a UML-based object-oriented analysis and design method specifically created for concurrent, distributed, and real-time applications. The book presents detailed structuring criteria that assist the designer at every stage of the analysis and design process, and offers exceptional insight into dynamic modeling, concurrency, distributed application design, and performance analysis of real-time designs.Gomaa concludes with several detailed case studies covering a broad range of applications, including systems for banking, e-Commerce, cruise control, factory automation, and more.

Buy NowGet 20% OFF

Click here for more information about Designing Concurrent, Distributed, and Real-Time Applications with UML

Read More...