Murray Silber is a Developer and Instructor who discovered Java began 4 years ago. He has spent the last two years at Working Technologies where he is a senior Java Developer/Instructor and an Enterprise Java Architect in the making. He has an obsessive fascination with Software Analysis & Design methodologies and is also involved in the development of Java training material. He is a Sun Certified Java Programmer and also is a Certified Technical Trainer.
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.Use Case Driven Object Modeling with UML-Theory and Practice
| Author(s) | Doug Rosenberg & Matt Stephens |
|---|---|
| Publisher | Apress |
| PubDate | January 2007 |
| Reviewer | Murray Silber |
One Minute Review
Positives
Negatives
|
Sections
Intent & Audience
Have you ever read a book that spends chapter after chapter describing the use of a technology, only to find that, finally, there is a chapter on best practices, and you realize : "Oh, THATS how it should be done"? Well, this book is NOT one of those books. It sets out to answer that famous, or infamous question : How do you get from Use Cases to code? To answer that question, the authors implement a minimalist, use-case-driven, Object Oriented, UML based process called ICONIX, which takes you from use cases to working, maintainable code in as few steps as possible, but without cutting essential corners.
They do so by making use of a 'Top ten Guidelines' approach to each step in the process. Each chapter begins with this guideline, implementing each of the tips en route to providing a workable solution to a problem domain.
This book is aimed at both the novice Object Oriented Analysis and Design (OOAD) practitioner , who will learn how to use an excellent methodology correctly, as well as the experienced practitioner, who is looking to plug a use case driven process into their methodology.
Relevance of material
By making use of an Internet Bookstore case study throughout the book, the authors demonstrate, in practice, the theory of getting from use cases to source code. Various exercises of different types will challenge you, whether you are a novice or have experience with OOAD. Just when you thought it was safe to move on, deliberate mistakes on some of the diagrams will force you to take a second look, ensuring a deeper understanding of the subject matter. At the end of your journey, you will have a working, maintainable project that has been built using the principles laid out in the book. This book is not a 'Learn how to draw UML diagrams book', and the authors never make that claim. Knowledge of UML is a prerequisite for the book.
Chapter highlights
With the exception of chapter 1, all chapters are structured as follows:
- The theory behind the topic, explored using a 'Top 10' Guidelines approach, which ensures that you 'do it right' from the beginning.
- The topic in practice, made up of a series of exercises.
- A summary of each chapter.
Chapter 1: Introduction to ICONIX Process
This chapter introduces the reader to the ICONIX process. Each of the steps in the process is introduced, along with an outline of its corresponding top 10 guidelines. Excellent use of diagrams, and the innovative use of a second color (red) assist with visualization of the process, as well as setting the tone for the rest of the book.
PART 1: REQUIREMENTS DEFINITION
Chapter 2: Domain Modeling
Describes what a domain model is and why we should start with Domain Modeling and not with Use Case Modeling. An interesting chapter, whetting your appetite and preparing you for the rest of the process. Guideline #4: "Use the Domain Model as a Project Glossary", discusses an often neglected part of a project's documentation, and offers an effective approach to eliminating ambiguity from the word go.
Chapter 3: Use Case Modeling
This chapter is loaded with eye-openers with respect to writing Use Cases and challenges a few of the established approaches (with good reason). Guideline #4 : "Write the Use Case in the context of the Object model", describes one of the most critical aspects of writing effective Use Cases and, along with the rest of the guidelines and exercises, ensures that you move on to the next chapter with the knowledge that your Use Cases WILL be MUCH better from now on. As the title states, the process is Use Case driven, and, as such, is a critical component of the project that you are working on.
Chapter 4: Requirements Review
The authors start this chapter by describing why we need a Requirements Review. The theory of the review process is then discussed, and as with the other chapters, is followed by the practical application of the theory. The format of the practical exercise is a walk through of a conversation between the Analyst and Reviewer. This conversational approach makes what can be a tedious, but vital step in the process, an absorbing read.
PART 2 : ANALYSIS, CONCEPTUAL DESIGN, AND TECHNICAL ARCHITECTURE
Chapter 5: Robustness Analysis
The transition from analysis to design begins with this chapter. Robustness Analysis is the process of tying your use cases to the objects in your domain model which helps you 'drive' object oriented designs from use cases.
The authors describe Robustness Analysis as taking place in the "murky middle ground" between analysis and design. This transition is handled by making use of a robustness diagram. The robustness diagram (not a UML diagram) ensures that your Use Cases are written in the context of your domain model, and is an object picture of a use case.
All too often there is information lost in translation and Robustness Analysis seeks to minimize this. You need to spend some time working through this chapter. Practice makes perfect, and I would suggest that you become very comfortable with the concepts presented in this chapter before moving on. I must also extend my gratitude to the authors for introducing us to Enterprise Architect, a modeling tool that has implemented rule checking for the robustness diagram, and is a pleasure to use.
Chapter 6: Preliminary Design Review
Preliminary Design Review (PDR) ensures that your robustness diagrams, the domain model, and your use cases are synchronized. This chapter starts with a hypothetical conversation that discusses why we should be doing a PDR.
"For each use case, make sure that the use case text matches the robustness diagram, using the highlighter test", is just one of the ten excellent guidelines offered to ensure that your PDR is done correctly. The practical example is described using a conversation between the Analyst and Reviewer. Working through some of the other use cases while following the conversation will assist in honing your skills. As with chapter 4, this chapter describes one of the milestones of the process and ensures that you are ready to move on to the detailed design
Chapter 7: Technical Architecture
This chapter describes the technology specifics of the system we are developing. The authors say that we should start thinking about Technical Architecture(TA) during Robustness Analysis (chapter 5) and it should ideally be finalized once you have completed Robustness Analysis (although this chapter is not a "standard ICONIX method" for creating architecture).
The internet bookstore case study in the book is built using the Spring Framework, which is introduced in this chapter. What is particularly interesting about this chapter is that the authors introduce us to the flip side of the top 10 "do's" by listing the top 10 Architectural Errors (the "dont's") commonly made.
PART 3 : DESIGN AND CODING
Chapter 8: Sequence Diagrams
We all know what a sequence diagram is, how they look and how to draw them. But do we really know how to draw them CORRECTLY?
The revelations just keep coming! Another excellent chapter, this time providing us with a comprehensive 'how-to' do sequence diagrams. Not a UML lesson on sequence diagrams, but rather, a discussion on sequence diagram semantics, as well as best practices, ensuring that your diagrams accurately reflect your use cases. Guideline #2: "Prefactor your design on Sequence Diagrams" discusses why its better to do your refactoring in the sequence diagram and not in your code. Spend some time here, absorb the words of wisdom and be enlightened.
Chapter 9: Critical Design Review
Another review chapter, this time focusing on three important goals :
- Ensuring that the 'how' matches up with the 'what' that are specified in your requirements.
- Reviewing the quality of your design.
- Checking for continuity of messages, ensuring that you can always tell which objects are in control.
Guideline #4: "Make your programmers 'sanity check' the design" will be music to the ears of all developers, and is another of those 'slap yourself on the head - thats how it should be done' moments. The authors describe Critical Design Review as as a vital part of the Iconix Process, an important milestone that takes place between detailed design and implementation. And how right they are!
Chapter 10: Implementation: Getting from Detailed Design to Code
This chapter discusses how we translate our design into code. The top ten guidelines are all vital, and will ensure that your translation is completed correctly.
Two of the guidelines stand out:
- "Focus on Unit Testing while implementing the code." - The importance of unit testing cannot be ignored and the authors have dedicated a large portion of Chapter 12 to unit testing.
- "Don't over comment your code" - make your code largely self commenting, it just makes it easier to maintain, simple as that.
We see the implementation of the database in the case study, and a couple of the use cases are translated into code. Appendix B, which describes the Spring specific implementation details will assist here.
Chapter 11: Code Review and Model Update
"You mean I have to review the code, too? Why? Isn't working code enough?"
The importance of code review cannot be underestimated, and the authors discuss this at length here. The differences between code review and code inspection are also discussed. A conversation, this time between a Reviewer and Programmer, walks us through the code review of the internet bookstore case study. Issues such as updating the model are also highlighted here. Ignore this chapter at your own peril.
PART 4: TESTING AND REQUIREMENTS
Chapter 12: Design-Driven Testing
This chapter starts by looking at some of the theories of Design-Driven Testing (DDT), as well as describing different kinds of testing. The chapter then provides a quick introduction to JUnit, with some code examples and a section on how to write effective unit tests. We revisit the internet bookstore case study and look at implementing unit testing. This is done by creating unit tests for the controllers from the robustness diagrams for a couple of the use cases.
The chapter then focuses on Test-Driven Development (TDD) and, unless you are a user of TDD, then it would be advisable, as the authors put it , "sit back and enjoy a nice cup of tea". The chapter concludes with another of the list of "dont's", this time a 'Top 10 Design-Driven Testing Errors' . An essential chapter, and my first and only gripe about the book. I feel that more attention could have possibly been given to unit testing out of the TDD context, as the Iconix process is not dependent on TDD. An appendix on TDD might have been more appropriate. (You can guess that I am not a practitioner of TDD).
Chapter 13: Addressing Requirements
Not a core part of the Iconix process, due to the fact that each company has a different strategy for handling requirements, this chapter was intentionally held off until the end of the book. Having said that, the authors believe that if you take the ideas presented in this chapter to heart, you will find that your customers will be more satisfied with what you deliver.
Guideline # 8: "Avoid dysfunctional requirements by separating functional details from your behavioral specification" describes why you should keep your functional requirement statements separate from the use case text. "Intermangling", as the authors so deftly describe it, use case scenario text with requirements prevents the use case from being written in an unambiguous way and being written in the context of the object model.
A discussion on Requirements Allocation and Traceability follows , and the chapter then demonstrates how to organize requirements in Enterprise Architect.
PART 5 : APPENDIXES
Appendix A: What's new in UML 2.0
Appendix B: Spring Bin
Rating
This book is expertly crafted, providing a highly enjoyable, often insightful reading experience. Whether you decide to adopt the ICONIX process, or are just looking to improve your OOAD skills, this book is for you. An excellent buy, I highly recommend it.
| Relevance |  |
|---|---|
| Readability | |
| Overall | |
Resources
ICONIX Process home page
Internet Bookstore Project source code
Enterprise Architect software modeling tool.
Spring Framework
JUnit
Purchase Use Case Driven Object Modeling with UML-Theory and Practice on Amazon and help Javalobby.
