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.
I like the concept of UML, it makes it easy to abstractly define an entire program and then quickly put it together in either C++ or Java.
Unfortunately though, there are a lot of programmers that that UML and instead of having the simple links between the methods and classes, they have these jumbled messes because... well actually I don't know why. I am thinking it is because they don't want to spend the time writing quality UML and instead program something that works. (I know the feeling, I hate designing before programming, but you need to do that if you want to make it easier to support in the future.)
The key reasons for UML and advances is exactly that though. You (and others) need to be able to easily support your code in the future. If it is a jumbled mess of spaghetti code, or even worse if it is a complex mess of command made solely to speed up the code that very few will comprehend. Then you end up with a large problem. When something needs to be changed, it becomes incredibly difficult to decide how to do it.
I agree Java is pretty slow (it has sped up a bit over the years, but it still isn't optimal), but these OOP concepts of UML and properly designing easy to understand code should be applied over a need for speed. Hell, if you want to speed up the code a bit more, use C++.
I think programmers need to stop worrying about speed so much, and start to realize that these programs need to be easily workable and last. UML provides just one more way to keep them easily managable.
~ kjrose
Java and systems are getting faster. Consumer products in Java are not an unrealisitc expectation. The author of the book even says you don't have to follow the complete process - the book just uses 10 out of 100+ artifacts. You can pick whatever works for you. If you are pumping out similar products having an already-defined path helps instead of hinders. It depends what process you've got in place. For a small app things like doing the UI prototype will take a day or two at most - and you won't need any of the extensive data steps. Scale to what you really need, don't pick up a book or process and follow it through blindly.
This book is for projects made in heaven - i.e. the defence and NASA contracts where there are tons of money. Most development simply does not have the money or time share - it is unfortunately called the real world. The book is okay if the reader likes to escape to a new world order of unreality.
If you throw away the UML when you move to the next phase, then the UML step was mostly wasted. I can do everything UML does by writting and reviewing my header files. UML is great, if you keep it up to date with the program because you can see all the data on one page (11x17 poster) that you hang on the wall.
Class A has a pointer to class B, which has a child C, containing a pointer to class D, and that is how class A and class D fit in the whole system.
Remember the Mythical Man Month quote: (Which I cannot find offhand, but something like this) show my your logic, but hide your datastructurs and I will be mystified. Show me your datastructures and you will not need to show me the logic, it will be obvious. UML is a nice way to show the data structures -- if it is kept up to date
I like UML. Having a few posters on my wall that defined my data structures made the changes in my logic obvious. Even when UML had some lacks that it was still obvious what I needed to do. (The implimentation I used did not support an array, and I had one problem which required writing an array to hardware) However I was always printing out new posters because something changed. Worse, I had to keep track of a different one for each version of the product in the field. Still it is much clearer to have the essence of the header files all on one page, than scattered about in many different files.
(* I'm not very knowledgable about it, but it seems there isn't a clear tracable path from the use cases right down to the source code. It seems that UML results in work that is thrown away when moving forward in a project. *)
d =02/0 8/23/012255&tid=108 [remove spaces])
I am not sure exactly who the target audience is for UML. Managers? Developers?
I found the most important document is table scemas (DB layout). Whether it is represented as text (column dictionary) or an ER diagram does not really matter that much to me, although ER diagrams tend to skimp on details to make it fit on a single wall.
The rest of the stuff often covered in UML diagrams tends to be task-specific, so does not belong in a "global diagram" IMO. Then again, OOP tends to partitian things differently than relational-centric shops. (I won't start up another anti-OO rant, because we had plenty a week ago here at:
http://developers.slashdot.org/article.pl?si
Sometimes I use informal UI flow/state diagrams. If you get too formal, then you end up mixing high-level stuff with lower-level stuff and get a mess IMO. Save the low-level stuff for code.
Overall, it is important to keep the audience in mind when making such charts. You cannot fit everything for everybody for every viewpoint, so you must make some dicisions about the purpose of a given diagram or chart. (Unless you work for a place that requires them for no fricken purpose beyond burocratic rules.)
Table-ized A.I.
Managers and designers read "Design Patterns" and
not "K&R". Hey, if they can't hack "K&R", okay,
at least read "Mythical Man Month". The problem
is managing complexity. You *can* do it with
coding and re-factoring as you go along. Of course,
design is important and good design can lead to
good programs. Unfortuneately, good design
can also lead to bad programs. Pretty pictures
do not a good implementation make.