Rating: 
Summary: Good for new business modellers
Review: Being relatively new to business modelling in the eCommerce arena, I purchased this book with the aim of guiding me to a consistent diagramatical notation/methodology for functional requirements. Whilst many customers are still more comfortable with the old flow chart and DFD, I was able to at least apply some of the principles behind the notation. I showed someone else in our workshop sessions and they took the details so they could purchase their own copy. I have compared notes with a few others and find that they either have the book or have at least seen it. I would recommend this to someone in the same situation as I was - relatively new to business modelling, yet not naive wrt analysis and design methodologies. For those who are old hands it might still be worth a look.
Rating: 
Summary: Room for improvement, but not all bad
Review: Considering that that the "UML Toolkit", although now dated, is a useful book, I was expecting quite a lot from "Business Modeling with UML". However, it seems like the authors couldn't make up their mind about what to focus on. The core of the book, the Eriksson-Penker business extensions, make up for a mere twenty pages of the book, and the rest of the book is spent discussing various patterns, business rules and the UML in general. Many of the subjects discussed are based upon earlier works, and treated a bit too lightly, imho. Similar to just watching the highlights on sportscenter, it just doesn't tell the whole story. There are also a number of (minor) syntactical errors in the chapter dealing with OCL, which somewhat confuses things for the reader. Despite this, not all is bad with the book. The E-P Business Extensions are useful, and their creation of four business views (similar to the 4+1 view of software architecture) is indeed a good one. The book also fills a void in the UML and RUP, which is well needed, so by all means, take a look at it.
Rating:
Summary: Room for improvement, but not all bad
Review: Considering that that the "UML Toolkit", although now dated, is a useful book, I was expecting quite a lot from "Business Modeling with UML". However, it seems like the authors couldn't make up their mind about what to focus on. The core of the book, the Eriksson-Penker business extensions, make up for a mere twenty pages of the book, and the rest of the book is spent discussing various patterns, business rules and the UML in general. Many of the subjects discussed are based upon earlier works, and treated a bit too lightly, imho. Similar to just watching the highlights on sportscenter, it just doesn't tell the whole story. There are also a number of (minor) syntactical errors in the chapter dealing with OCL, which somewhat confuses things for the reader. Despite this, not all is bad with the book. The E-P Business Extensions are useful, and their creation of four business views (similar to the 4+1 view of software architecture) is indeed a good one. The book also fills a void in the UML and RUP, which is well needed, so by all means, take a look at it.
Rating:
Summary: Not particularly useful
Review: I am looking for a book that would be able to flesh out proper business processes utilizing well defined modeling language/framework. Although UML is extremely useful for software development, the author's work did make its case stand with me on UML's usefulness as business process modeling tool.The examples are too simplistic and the suggested modeling diagrams are far too cluterred for a business personel to understand.(Cluttered diagrams on a simple example) The book would be better if it had a growing case study and used real world examples and diagrams.
Rating: 
Summary: Very high level, often inconsistent
Review: I enjoyed the concepts, and the book is actually very readable. But when it came time to start applying the techniques my tune changed a bit. If you are using a simple drawing tool (like Visio or similar) to render your UML diagrams, then this book may be helpful to you. If you are using a more sophisticated tool like Rational Rose, then I think you will have difficulty creating the necessary business extensions and stereotypes. (Is that a criticism of the book or of Rose - you decide). Another criticism is that the authors appear to have made themselves readily available for questions and additional info, but in fact this is not true in my case. Also the the URL that is provided on page xix (in the introduction), which is supposed to contain additional examples and articles is no longer available. I hate that! It appears as though the authors have left this book behind them, so perhaps you might as well to. If you are in the inception phase of a business modeling initiative and you are using Rational Rose, then I would not recommend attempting to apply the techniques in this book with that toolset.
Rating:
Summary: Excellent ideas, excellent read!
Review: In this book, Eriksson and Penker (E-P) define UML extensions for describing business processes. Here's a summary of my interpretation of thier ideas: Processes are generally modeled using UML activity diagrams. A "process" is shown as an Activity stereotyped as <<process>>. The <<process>> activity is also given a new icon and a set of tagged values. I think the icon was added to make buissness developers feel more at home. Instead of a retangle with rounded corners, it looks like a big arrow. Four base types of objects are shown in a process diagram: Goal, Input, Output and Resource objects. "The input objects are resources that are transformed or *consumed* as part of the process..." An input object may become an output object with a state change, but this is not always the case. Sometimes input objects are consumed. E-P say "An output object can be a completely new object created during the processes or it can be a transformed input object". Another quote: "During its execution, the process interacts with other resource objects, objects other than the input and output objects, that are just as vital. These objects carry information required by the process or they are resources responsible for executing the activities in the process, such as people or machines.". Output objects flowing from one process can become input objects or resource objects flowing to another process. Goal objects define a set of rules for controlling the process. A process diagram is drawn with input objects to the left, resource objects below, goal objects above and output objects to the right of each process symbol. Object flows (dashed arrows) are used to connect the objects to the processes. Just as in standard UML, <<process>> Activities can contain sub <<process>> Activities and Activities. Non-process Activities being automic. The State of an object can be shown with standard UML syntax. A description on the use of "swimlanes" in activity diagrams is also given. Classes of objects and their associations are provided by standard class diagrams. E-P also describe the use of sequence diagrams and state diagrams in a business modeling context. They even provide a meta-model for thier Modeling extensions! The book also describes another type of process diagram that they call an "assembly line" diagram. It appears to be a process diagram that utilizes Packages to represent resource collections. I believe that Eriksson and Penker stayed within the UML standard and in fact thier extensions don't appear to be that "extensive". Mostly some stereotyping, some tagged values and an icon. The second half of the book is dedicated to design patterns for busineess development. But many of these patterns could be very usefull to you. They also show how to provide object constraints using OCL and provide a pretty decent UML primer. One thing that is bothering me about the process diagrams it that they do not show object collaboration very well. I think that the contractual message passing between objects needs to be shown with informational interface objects rather than parameter lists. I'm withholding judgement at this point. After all, the business models they are describing will never be translated into code, but rather business forms and process documentation and executed by people and not computers. They do however, give a method for creating software system models for automating part of the business system. All mistakes, misconceptions and missuse of terminolgy in the above description of Eriksson and Penker's book are my own. Adios,
-Andy
Rating:
Summary: Excellent ideas, excellent read!
Review: In this book, Eriksson and Penker (E-P) define UML extensions for describing business processes. Here's a summary of my interpretation of thier ideas: Processes are generally modeled using UML activity diagrams. A "process" is shown as an Activity stereotyped as <<process>>. The <<process>> activity is also given a new icon and a set of tagged values. I think the icon was added to make buissness developers feel more at home. Instead of a retangle with rounded corners, it looks like a big arrow. Four base types of objects are shown in a process diagram: Goal, Input, Output and Resource objects. "The input objects are resources that are transformed or *consumed* as part of the process..." An input object may become an output object with a state change, but this is not always the case. Sometimes input objects are consumed. E-P say "An output object can be a completely new object created during the processes or it can be a transformed input object". Another quote: "During its execution, the process interacts with other resource objects, objects other than the input and output objects, that are just as vital. These objects carry information required by the process or they are resources responsible for executing the activities in the process, such as people or machines.". Output objects flowing from one process can become input objects or resource objects flowing to another process. Goal objects define a set of rules for controlling the process. A process diagram is drawn with input objects to the left, resource objects below, goal objects above and output objects to the right of each process symbol. Object flows (dashed arrows) are used to connect the objects to the processes. Just as in standard UML, <<process>> Activities can contain sub <<process>> Activities and Activities. Non-process Activities being automic. The State of an object can be shown with standard UML syntax. A description on the use of "swimlanes" in activity diagrams is also given. Classes of objects and their associations are provided by standard class diagrams. E-P also describe the use of sequence diagrams and state diagrams in a business modeling context. They even provide a meta-model for thier Modeling extensions! The book also describes another type of process diagram that they call an "assembly line" diagram. It appears to be a process diagram that utilizes Packages to represent resource collections. I believe that Eriksson and Penker stayed within the UML standard and in fact thier extensions don't appear to be that "extensive". Mostly some stereotyping, some tagged values and an icon. The second half of the book is dedicated to design patterns for busineess development. But many of these patterns could be very usefull to you. They also show how to provide object constraints using OCL and provide a pretty decent UML primer. One thing that is bothering me about the process diagrams it that they do not show object collaboration very well. I think that the contractual message passing between objects needs to be shown with informational interface objects rather than parameter lists. I'm withholding judgement at this point. After all, the business models they are describing will never be translated into code, but rather business forms and process documentation and executed by people and not computers. They do however, give a method for creating software system models for automating part of the business system. All mistakes, misconceptions and missuse of terminolgy in the above description of Eriksson and Penker's book are my own. Adios,
-Andy
Rating:
Summary: A very good guide to business-level modelling with UML
Review: One of the weaknesses of the Unified Modelling Language is its relatively limited support for modelling at the Enterprise level, especially to accurately model business processes. The UML purists believe that everything should be reduced to Use Cases, while these authors recognise that much more is necessary. The book covers five quite distinct topics:
1. An introduction to business modelling and UML, explaining the problems the authors want to help solve, and describing each of the relevant techniques of UML,
2. A proposal for a group of extensions to UML (using that language's own established extensibility mechanisms) so that that it can better model business processes,
3. A description of the variety of views and models which will be required to establish a comprehensive understanding of the business, or at least part of it,
4. A repository of "business patterns", which you can use to model the business,
5. A comprehensive worked example. Each of these is quite detailed. In particular, the book contains probably the best introduction to the Object Constraint Language (OCL), and its use to model business rules, that I have read anywhere. The sections on how to do business modelling are also very good, as are the introductions to the relevant UML techniques. The "Eriksson-Penker extensions for business modelling" are important because several UML-based case tools have now implemented them as an emerging standard for business process modelling with UML. If you want to fully understand how these work, this is the book to read. The business patterns are more of a "curates egg". Some are extremely useful, and others innovative which could easily solve your problems where there is an accurate match. That said, some are less good and seem to state the obvious, although with patterns it is always difficult to know if you are judging some harshly simply because you are so familiar with them and other readers will get more value. Some of the pattern explanations are a bit repetitive, and the "examples" often sound very artificial, but overall they are useful, and a single one which solves a real business modelling problem for you will justify the rest. At over 400 pages, some of which is occasionally slightly slow and ponderous this is not an ideal book to read from cover to cover. But it is definitely one to study, focusing on whichever topic is most relevant to you at any time, and I can happily recommend it.
Rating:
Summary: Interesting concept, great work on business modeling
Review: Sometime ago I have been wondering if somebody will try to bridge the gap between business modeling (the one used by consultants) and software engineering. It would certainly make it easier for people to understand and explain business operations. This book is an application of the UML into the realm of business modeling. It is very good in the sense that it explains and goes through the patterns that form business models. The introduction on UML is pretty short and concise, so if you are new to it try using "Applying UML..." book to get an introduction. Be prepared to sit down and spend some time reading, since the material can be a little bit daunting to try to understand and remember all the patterns available. Overall, I wish I had this book for Systems Analysis instead of the outdated software engineering books that we used.
Rating:
Summary: Good Book
Review: The authors effectively present the concepts related to the modeling of the business. Keep in mind that the scope of the book is much borader thans the tradiotional modeling for building computer information systems.
|
