Slashdot Mirror
Developing Applications with Java and UML
Each chapter begins with a brief summary and a list of the goals. After reading the book through, both should be useful. Each chapter also closes with a 'checkpoint' that summarizes what has been covered in the chapter and what is to come.
The first chapter sets up the entire book by outlining some of the project problems encountered in software development. Once the author gets into development models, the Unified Process from Rational Software, a huge and detailed software process, is introduced. The book focuses on only using the elements that provide the biggest 'bang for the buck'. The Unified Process is the focal process of the book, but the Synergy Process is a free alternative, only lacking some additional guidelines and how-to's. A short overview of UML is covered, along with its' place is in the software process. He notes that a project that just uses UML in a vacuum without a sound process and plan will fail.
The second chapter briefly discusses the Java language alongside the concept of Object Oriented Programming. Experienced Java programmers could skip this section if they wished. The section is worth skimming as a lead-in to the explanation of how Java and UML are a good fit.
Chapter three, Starting the Project is the first time the book delves into the meat of how to structure a project. The example scenario that is followed through the book is introduced, and throughout the book real-world examples are used that relate to the sample project. Every theory in the book that is translated into some kind of example the reader can pull apart and examine.
Through the next few chapters use-cases and class diagrams are covered, leading up to building a user interface (UI) prototype. Personally, I've never used UML for anything but sculpting class diagrams for export. This is the point in the book where I started to see how the rest of the project is able to use UML and tie it all together. Being able to model the classes and easily export them is very powerful, but even more so when combined with the rest of the ways you can employ UML in your project.
The following chapters are much like the first few that began to talk about the sample project. There is no Java code until chapter 9, halfway through the book. This is not the book to get if you are only interested in how to use UML as a base to dump out some code.
Throughout the book the content remained interesting, and relevant. Do not expect to sit down and read it from beginning to end. There is a great deal of material covered and no topic that was inadequately explored. Using the sample project consistently throughout the process was invaluable, along with the samples and source code provided. Alongside the process, the real life anecdotes and comments provided were a welcome addition instead of an intrusion. The author is someone who's seen the mistakes that could be avoided. For example, an application with 70,000 lines of Java code that only contained two classes.
Having talked about the depth and detail of the book, this was also one of the bad points as well simply since it takes so long to get through. People already well experienced in running a project with similar phases will find it much faster reading. The other issue is the expense of the tools and products involved. Rational Rose, the Rational Unified Process and WebLogic are rather expensive products. Thankfully there are alternatives that he mentions in the book, and others as well. Visio, the Synergy Process and Tomcat are all possible alternates. Surprisingly, Tomcat is used in his example setup.
I had left the rating at 8 throughout most of my reading while considering the positives and negatives. However, when I finished the book I bumped the rating up to 9 simply because of the wealth of information I learned. Anyone aspiring to run a team project with Java should read this book. In the corporate arena, most of the battle is not the code, but understanding what the users want and what will be created. Following any kind of process will improve the result, even if only a few key elements are used.
Chapters:
1. The Project Dilemma
2. Java, Object-Oriented Analysis and Design, and UML
3. Starting the Project
4. Use-Cases
5. Classes
6. Building a User Interface Prototype
7. Dynamic Elements of the Application
8. The Technology Landscape
9. Data Persistence: Storing the Objects
10. Infrastructure and Architecture Review
11. Constructing a Solution: Servlets, JSP and JavaBeans
12. Constructing a Solution: Servlets, JSP and Enterprise JavaBeans
Appendix:
A. The Unified Project Plans
B. The Synergy Process Project Plan
C. Estimating Projects on the Basis of Use-Cases
D. Sample Project Output
E. BEA WebLogic Application Server
You can purchase Developing Applications with Java and UML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Surprisingly, Tomcat is used in his example setup.
Surprised? Most Java developers use Tomcat for a servlet app server (not a full blown app server, but you can have that if you tie-in JBoss). Tomcat is great for development if you aren't dealing with EJBs.
Most Java developers I know use Tomcat before an app server is chosen so they can get stuff working, and will stay with tomcat unless the customer has a license for an expensive appserver or they are using EJBs.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
If you want to buy the book, go to the Bookpool site, much cheaper. Here is the link.
And consumer software written in Java? Nope.
Ever used JBuilder?
D/L JBuilder 7 from borland. Yeah, your thinking its in C++, or at least mostly in C++. The whole thing's written in Java.
Java in consumer products have been invaiding, and you've thought it was C++ the whole time...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
EJBs, when deployed in a J2EE-compliant EJB container provide a lot of services that would be difficult or time consuming to write yourself. Plus, there's 1000 books about the standard. You get transactions handled automatically, across any number of data sources, you get Object-Relational Mapping and all that that brings. You get connection pooling. You get a lot of stuff that you wouldn't want to write yourself. Plus, it's all remote, so you can have business logic stored in one place, with clients accessing it remotely, and always being in sync. This way you can write multiple client types (web, swing, pda) that all use the exact same business logic.
Yes, it can make simple things difficult, but it mostly makes difficult things simple. If you are creating a large system, you do NOT want to be hacking ASP, PERL, PHP or some other roll-your-own architecture, especially if you have a lot of engineers, not all of whom are senior programming Gods who can behave themselves in such wild-west environments (i.e. most serious projects).
http://www.naildrivin5.com/davec
UML came about slightly before Java, and was itself developed as a common notation for existing practice - hence "Unified Modelling Language." The people behind UML used to push their own, incompatible notations.
UML itself encapsulates two basic techniques - use case driven design (modelling requirements almost entirely in terms of user actions) and OO design. I don't know about use cases, but OO was in it's infancy in the early 70s, and a usable OO environment (Smalltalk) existed by 1982. C++ came along a few years later.
It is designed for large systems, not Hello World applications. It is also designed as an architecture to direct development. I'd like to see you whip up database connection pooling and transaction management across any number of disparate database servers in a short amount of time and make it fully configurable.
I mean, by your logic, you don't need to rely on any standard or any pre-build system, because you can roll your own. Why use TCP/IP? I'm sure you can roll your own network protocol without all the "overhead" of the IP headers. I mean, to send one byte of data with TCP/IP requires 64 bytes!
Don't talk about things you know nothing about.
http://www.naildrivin5.com/davec
I've been told by people at TogetherSoft (maybe it was just marketing bull) that they use Together and Feature Driven Development (developed by Peter Coad) to develop the Together products.
cheers
Java programmers do it with