Ivar Jacobson developed Objectory as a result of 20 years of experience building real software-based products. The approach takes a global view of system. OOSE Background. É Originated in Sweden. É ” Object-Oriented Software Engineering A Use Case Driven. Approach ” by Ivar Jacobson, Magnus Christerson. OOSE is developed by Ivar Jacobson in OOSE is the first object-oriented design methodology that employs use cases in software design. OOSE is one of .
|Published (Last):||17 November 2006|
|PDF File Size:||6.56 Mb|
|ePub File Size:||3.91 Mb|
|Price:||Free* [*Free Regsitration Required]|
Even today this is a really great book. You might be turned off initially, as I was, by its rather broad coverage of the software lifecycle industrial processes, testing, etc Lvar, if you stick to it, you’ll find the real gold is in three key areas.
This is the first time I’ve encountered such a rational explanation. Instead of just saying that O-O makes code more resilient to change, Jacobson provides the reader with a “robustness analysis” process where potential future changes shape the organization of the code. Next is the introduction of three types of objects: Entity, Interface now called Boundaryand Control pg Along with these three types, advice is provided on when they should be used, and how code should be sliced up into these types of objects.
The concept of Control objects is very important to good object oriented design.
Object-Oriented Software Engineering by Ivar Jacobson
All the books I read during the early ‘s insisted on modeling the real-world only, excluding Interface and Control objects. This turns out to be quite difficult. Finally, Jacobson provides two excellent case studies which give you plenty to think about Chapters 13 and These case studies make the book still worthwhile today since anything that exercises O-O thinking is worth the time.
However, if you want to see a little more history and have two more case studies to think about, Jacobson’s Object Oriented Sofware Engineering makes a great companion volume. Pg 39 “design with building blocks” Building blocks are a design concept that enables the transition from analysis to implementation.
Each analysis object translates into a design block which may translate into more than one class in the implementation. Pg “block design” This is hardware-inspired software design. Similar to component-based design. Pg “blocks to handle the environment” OS wrappers are another kind of object that is recommended.
Object-Oriented Software Engineering – () | Ivar Jacobson International
The examples show how blocks lead to persistence frameworks and other complex, potentially reusable structures to support the implementation of an analysis concept. Are they still there? Jacobson argues throughout for use cases as the root of software design.
He calls it “use case driven design” pg Given that OOSC-2 is not a book about large-scale software architecture, one must think carefully about Meyer’s opinion. He gives three reasons why use cases are bad. Emphasize ordering Focus on how the user sees the system Favor a functional approach Emphasize ordering.
Throughout OOSC-2, Meyer stresses that it is important to forget about the sequencing of operations in a program since that will adversely affect the discovery of sensible operations for a class. One should think about the classes themselves and forget about how they will be used.
But, if you don’t consider how a class will be used, there’s no sense in creating the class. This thinking might be workable for entity objects, but it makes no sense for the control and boundary objects that must support those entity objects to keep them pure.
Focus on how the user sees the system. Meyer argues that since the system doesn’t exist yet, how can we possibly consider how it will be used? I don’t buy it. The whole point of coming up with use cases is to dream about how the system should be used. The emphasis is on the user where it rightly should be. The resulting use cases help make a system that matches the users needs.
Meyer is clearly hostile to the user throughout his book. Favor a functional approach. Here, I think Meyer has a point. The discovery of objects is pretty vague in OOSE, as is the discovery of operations on those objects via an interaction diagram. I never liked interaction diagrams. However, Meyer does not provide a suitable alternative that is applicable to large systems. Jacobson at least makes an attempt. He says that use cases should be avoided except by teams that have developed systems consisting of “several thousand classes each in a pure O-O language”.
Do I detect a bit of exaggeration here? This, unfortunately, is typical of Meyer, so it is hard to take him very seriously. Meyer is honest, however.
He lets us know that he formed this opinion based on seeing projects that abused use cases. I can jacobskn see that use cases could be used to justify falling back on old habits. This doesn’t mean Jacobson’s techniques are bad. It just means some people don’t understand them. Jacobson’s process is intended to support large-scale system design. Meyer’s process is oosw on low-level class design. I find Jacobson’s advice much more useful in practice.
While Addison-Wesley seems to be teasing us by listing a second edition of OOSE on their websiteI don’t believe this will ever happen.
There just isn’t a need for a second edition these days. It is the book where “Boundary” is first used instead of “Interface”. It only contains one running case study, an ATM machine. Jacobson will be unveiling his Essential Unified Process mid Hopefully this will yield a new book comparable to OOSE.
Jacobson’s Website – Find out what he’s been up to lately. Page 31, the case is made for having dynamic objects and information-carrying objects: Here are two good pro-O-O arguments that I’m prepared to buy.
First, O-O reduces the semantic distance between the problem domain and the code. This means a change to the data affects all of those functions. Encapsulation is intended to reduce this problem.
This book is not an jaobson to O-O, and Jacobson admits this, pointing the reader to other books for learning O-O. Pg System Architecture is detailed in the analysis model. Object design is in the design model.
Pg section 6. He proposes three dimensions: Behavior, Information, and Presentation. He then proposes three object types, Entity, Interface, and Control. While these object types each lean toward a single dimension, they are a bit blurry and may contain any of the three dimensions.
I’ve found my own variation on these 3-object patterns to be very helpful over the years, and further research could be interesting. Object-oriented development at Brooklyn Union Gas. IEEE Software, 10 1: Plus some other papers I’m ajcobson familiar with.
Need to focus on this as a source for research. Pp is wonderful. Worth the price of admission, and probably why this book was held in such high regard. This is a beautiful argument for why oo isn’t really that much better than function-oriented when it comes to stability in the face of change. This is refreshing as most oo books insist oo is so much better at ose with change when ivvar with func-o.
Then, Jacobson shows how the hybrid nature of EIC can help make some changes easier. I don’t really buy it because sometimes the difficult change is the correct change, while the easy change is wrong for the system.
As an example, we may want to implement a “credit interest” transaction. This will probably be different for each account, so creating a separate InterestCreditor object would make no sense. Instead, each account object would need to be changed. Still, the object-oriented vs. By the end of chapter 6, we have an overview of this industrial heavyweight OOSE development process. It includes use cases, a domain object model, an interface model, interaction diagrams, an analysis model EIC objectsand a design model blocks.
Pg The author keeps emphasizing that the analysis model must not be concerned with the implementation limitations.
Pg “Many other object-oriented methods, such as those of Coad and Yourdon and Boochfocus entirely on [problem domain] models Pg One control object per use case. This isn’t how I do it. I wonder what the code I develop at work would look like given this approach. The problem domain includes emulation of incredibly complex hardware devices containing their own very complex user interfaces.
Probably huge and unmanageable. Imagine the thousands of little “use case” classes.