Enterprise Modeling with UML: Designing Successful Software Through Business Analysis (Addison-Wesley Object Technology) [Paperback]

The book is heavily based on a process/workflow-oriented view. There is very little guidance on the UML notation, and the models are all at Specification rather than Conceptual level, which means an OO solution is assumed at the outset. This is regarded as bad requirements practice.

I do not believe the Author is a Requirements Engineer, as RE is just not discussed at all, which I find quite remarkable as the book is about enterprise modelling.. This is reinforced by the bibliography, which has significant omissions.

Some of the UML models are open to criticism as to the application of UML semantics. The proliferation of discriminators without constraints or stereotypes, and of convoluted associations together with the lack of explicit design patterns, also made me wonder about conformance with accepted good OO practice, such as the LSP, OCP, DIP, etc.

I am particularly uncomfortable with using static modelling semantics for the dynamics of business process; Statecharts, perhaps the most powerful UML tool, do not appear in the book, nor do Collaboration Diagrams.

This is the workflow view, which is old-hat in the modern distributed component world of today, and can lead to an unrealistic view of the world by not being explicitly Business Event-driven (Events seem to be dismissed as 'artificial' on page 54!). An example in the book is an instance of a Sales Order Process which can go to a Cancelled state. In my opinion, cancelling a Sales Order is a totally separate Use-Case, instantiated by the discrete goal-oriented Business Event 'Customer Wants to Cancel Sales Order'. The design of this Use-Case could have many scenarios, and there may be other Business Events which cause the state of a Sales Order to go to Cancelled.

I prefer the view that Business Process is dynamically provided by Business Use-Case realizations, the objects being responsible for their states, with a control object being responsible for any ACID transaction requirements upon the Use-Case.

Overall, if you interested in a workflow framework, then fine; but if you are interested in using OOA/UML for static and dynamic modelling of your enterprise, especially with a view to specifying a robust component architecture which responds to goal-oriented Business Events, and is open to extension and change as your business grows, then I suggest you look elsewhere.

How do you model a contract? How do you model "purpose"? How do you model push and pull rights and responsibilities? How do you link these to the company's processes and entities? This book tells you how.

Rather than presenting a UML model of how an enterprise functions this book presents a comprehensive UML metamodel based on a "fractal" DFD-like decomposition of organization, purpose, process and flows.

The solution here is similar to the book "Java Modeling in Color with UML" use of domain-neutral component archetypes--only better if your goal is reusable code over several enterprises rather than a tuned one-off for a specific corporation.