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
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!
Yeah, like that's ever going to happen. How would we know how elite a programmer was if he didn't just hear a problem and then work like a maniac for a week and pull a rabbit out of a hat? We can just work out the problems as they appear in the code as it is being produced. Easy.
;P
Besides, a formal, methodical approach to software development is just so... arty! Nothing for the macho h4x0r to sink his yellowing teeth into. Real programmers just grab some wood and nails and start hammering. I mean, how many buildings can you name that were built on paper first?
I've got a bad attitude and karma to burn. Go ahead. Mod me down.
If you want to buy the book, go to the Bookpool site, much cheaper. Here is the link.
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.
There's a saying in certain UML circles:
"Shit doesn't get smaller if you draw an UML diagram of the bowel that produced it."
UML gets a bad reputation because most people think that because they (spent a fortune and) got Rational Rose they suddenly know something about program design and software architecture.
For the experienced developer UML is just another addition to the toolbox. They understand when, but much more importantly, when NOT to use it.
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
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.
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
Don't talk about things you know nothing about.
Screw you jack; I know something about this. Not everything, but enough to talk rationally.
Yes, of course you can get ridiculous in a desire to remove layers of abstraction, but that doesn't mean EJBs (especially Entity beans) might not be too slow and complex for their own good. Otherwise there wouldn't be so much talk about JDO.
"make it fully configurable" is part of the problem...sometimes you do get better turnaround doing a series of smaller, customized solutions to problems than making or utilizing some huge, everything-but-the-kitchen-sink platform. "But it's XML! Non-programmers can change the flow!" Frankly, for anything non-trivial you usually don't want non-programmers changing the flow.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
Why couldn't they fit it all into one class? It simplifies the UML, and you don't have to look in two different places for the code.