Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

Developing Applications with Java and UML 117

Posted by timothy from the use-a-keyboard dept.
BShive writes "Developing Applications with Java and UML focuses on building and modeling industrial-strength Java applications. The book takes you step-by-step through a product lifecycle and software process. You do not need to know UML or OO Design, as both new and experienced Java developers will benefit from reading this book. It is highly focused on process, so developers will have to put aside the 'jump in and code' attitude." Read on below for the remainder of his review.
Developing Applications with Java and UML
author Paul R. Reed, Jr.
pages 463
publisher Addison-Wesley
rating 9
reviewer Ben Shive
ISBN 0201702525
summary Developing Applications with Java and UML focuses on building and modeling industrial-strength Java applications. The book takes you step-by-step through a product lifecycle and software process.

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.
This discussion has been archived. No new comments can be posted.

Developing Applications with Java and UML More

Developing Applications with Java and UML

Comments Filter:
  • Good review. The book's topic is pertinent to those companies that are implementing system software, stuff that's going to be around for decades. For the rest of us working on consumer software, this kind of thing doesn't help much at all.

    Sure everyone likes to say that architecture is the most important phase because from architecture comes all other activities. However, when the timelines are short and ship dates are measured in months instead of years, having a serious system in place hampers more than it helps.

    And consumer software written in Java? Nope. This book is totally aimed at those banks and other large-scale business systems.
    • I don't see in what respect the Java language combined with UML is not used for consumer software.
      Of course, if you enter into the J2EE world (EJB and stuffs), it's different, but I think this book could be really interesting at a consumer software development level.
      All that is a matter of project scale, but its use is interresting in both cases.
    • I agree wholeheartedly with this assessment. I've never worked on a product with a long enough future life cycle to warrant the ENORMOUS overhead of UML design. And the cookie cutter code produced by the tools (which is often cited by users of them as a justification) is typically bloated and overgeneralized. In the real world, I'll pass
    • 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.
      • You can build cocoa applications using the apple development tools that are native. Plus, the jvm on apple runs faster than any other platform I've tested on (linux, windows, solaris, os 9, os x).

        Just my 2 cents.
    • 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...
      • A better example would be the phone applets that run on systems like i-Mode here in Japan. Though they may be written in Java, the likelihood that they need extensive UML architecting is very small.

        I'm not saying that a lot of things aren't written in Java. One of my favorite websites is in the process of being reprogrammed in Java. But the stuff that trickles down to end users is almost certainly not Java and almost certainly didn't require a rigid process to get there.
      • 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.

        Borland might use Java to write JBuilder, but did they use RUP or Rational Rose? I don't think so.

        I heard from the teacher on courses of Rational University that Rational uses neither RUP nor Rational Rose to create their software.

        After a couple of year of my own experience I am very careful with RUP - it does not fit every project. OOP either. If you feel the same - try FAD: A Functional Analysis and Design Methodology [ukc.ac.uk].

    • >>And consumer software written in Java?

      what about Limewire, a popular filesharing program ?
    • The book's topic is pertinent to those companies that are implementing system software, stuff that's going to be around for decades. For the rest of us working on consumer software

      You make it sound as though the majority of programmers are working on consumer applications. I don't have figures by my side to qualify this statements, but I'm sure the opposite is true.

      Sure everyone likes to say that architecture is the most important phase

      It's not necessarily a phase! You don't need to do all the design before you start cutting code. Remember that UML is a notation, not a process like the Rational Unified Process, eXtreme Programming, etc.

    • I think that besides the usual BS that spews from many a development manager as relates to requirements, features, timelines, task assignment, goals, etc. there is also a sort of dual personality that exists within the top rungs of not just the companies and organizations (customers) involved, but actually on the development team itself. Meaning: that this problem occurs sometimes without direct cause by higher ups in the chain (the suits, if you will).

      Obvious Guy pointed out how there is the idea of good design first then implementation, but in reality it is much different. However, lets not accept that attitude and practice anymore than we would accept the regular practice of someone robbing your house when you leave during the day and saying it was simply 'a sad reality we must learn to live with.' I have sadly worked for some of the worst managers and development teams that you can get... these people make disorganized and pr0n addled teenagers hacking together a toy look like the giants in the industry as far as coordination, collaboration, actual planning and consistency are concerned. This problem of short time delays ends up forcing horrible hack jobs that we call proof of concepts, which predictably leads to being told to turn it into a formal prototype with only about a month, then told there that said prototype is now the system once we use the 2 months to harden it. Those time periods include the testing and documentation as well. Result? Most often a very hard coded, fragile, spit and bubblegum system that only causes massive heartache and money to maintain, extend and adapt not just a year later but often immediately following release. (most often because of adaptations to particular environments, platform settups, security requirements, etc of various end sights) When questioned on this, the pavlovian response of the decision makers is that the needs dictated this and they "could not" wait. Its been my experience that this is either an outright lie or is just extremely poor judgement. Consider how a project could be hurried up like this and end up a mess, yet when you look at the actual tasking orders that led to the project it clearly states (well clearly for bureacrats) that this is an advanced proof of concept to be fleshed out and refined before being adopted officially. Hmmm, does that mean that they want crap that takes 2.5 times the original development effort to turn into a useful and robust? (extensible, maintainable, efficient, buzz buzz buzz)

      I put this under the category of 'never learns from mistakes' as this happens so regularly yet so many on both sides (especially on the user side) complain about the lack of interoperability, extendability, and integration worthiness of these projects. So, to make a long post short... (too late, I know) what kind of book, cbt, cute PowerPoint slide, or dancing furry vendor mascot will get the point across the program managment and self labled 'system engineers' that it is both cheaper and more productive in the mid to long term to really plan, design and implement an actual piece of engineering rather than these hack jobs held together by dirty bandaids and mucous. I know that as an integrator it would make my job easier :) As a customer of various products though, I would be extremely happy and of course its not like I never have to maintain, much less develop in an environment that while contains talented programmers is not held together by anyone (or any ideology) that will coordinate, motivate and lead everyone to a satisfying conclusion. Actually its been so long sense I have been able to say, "Yeah I worked my tail off but we did our best, produced some impressive results and can be proud of the work we produced" Hmmm, lets check Monster.com now :)

  • Another coffee book to place on the shelf ... oh goody!
    • I hope people will remove coffee-coloured glasses, open their eyes, open their mind, begin to see and start to think. Then the time for real programming languages and real design techniques will come. Meanwhile I recommend to read the following books: I've just been tired from java problems since the bigining of Java waiting when Java will be improved finally up-to the production quality and it's still not there.

      So, still keeping some Java projects, I've decided to try something else. First I've tried was Python, which I used for while in OS automation scripts, but now I've tried to use it for a bigger scope: "servlets", UI, JMS-like messaging, XSLT, text processing, RDF, and finally in some AI stuff using FP, which is poor in Python, but at least it is there. By the way, OOP in Python is also far away from being perfect. It is slow on massive calculations, although it is fast enough for script -based OS automation, UI, "servlets" and XML processing (but not on huge files). it is dynamically typed and it has lazy evaluation - both very important features for messaging. Python is less known, comparing to Java, but its community is not really tiny as Perl and other *n*x hackers usually know Python.

      After Python I've tried Erlang, Oz, OCaml, Haskell. I think Erlnag is ready for distributed messaging and for OS automation. The others are not - the lack of libraries. Although, each of them, Oz, OCaml and Haskell, has a very great potential if some big corp will do support. Any of these three may need just 10% of Java marketing to collect a crical mass and become recognized.

      Before Java I had an experience also in C, Perl, Scheme, Lisp and Tcl, in few projects each. C is very "crashy" in you hands if you don't use it every day. Tcl does not handle well big enough apps. Perl is a "write-only" self-obfuscated lang. The only choice left is Lisp and Scheme. Lisp is very power for big standalone apps, Scheme is convinient for being embedded somewhere.

      So, in the finals I've got Python, Erlang, Scheme and Lisp. Not a bad choice.

      Coming back to UML. It does same help for Python programming as for Java. As for Lisp/Scheme and Erlang, I think that things like UML are too primitive to fit. On serious languages you need a serious math, and usually diagram is just an iluustration in the math article, not a whole article.

      So, if you tired from kid pictures get the math in your hands :)

  • UML, good concept. Never implemented right. (Score:3, Insightful)

    by MarvinMouse ( 323641 ) on Thursday August 29, 2002 @09:39AM (#4163295) Homepage Journal
    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.
    • 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.

      Because what is "jumbled" to person A may not be "jumbled" to person B. "Mess", "Spehgetti", "Jumbled", etc. are rather subjective things. The instustry is lacking decent metrics right now, so disagreements are popping up all over the place.

      Software engineering is a dark-grey art (as apposed to a black art). As soon as one realizes this, things will start to look different.

      I know what works well for me, but other people think differently. I realize that I am not going to convince most others to like what I like ('cept maybe a few on the border). Perhaps it is more important to get like-minded people on teams than almost anything else, otherwise everybody will spend all their time trying to make others think like them or trying to explain their different thought processes and reasoning paths.

      Or, make it a hierarchy where the cheif dictates his/her favorite approaches to the others and the others have to live with it.

      • The instustry[sic] is lacking decent metrics right now, so disagreements are popping up all over the place.

        Your ignorance is only out weighed by your ego.

        Metrics for OO Software Engineering have been around for years. Just because you have never heard of them does not mean they do not exist. If you spent as much time reading as trolling perhaps you would already know this.

        Here are a few links to be going on with: http://www.dacs.dtic.mil/databases/url/key.hts?key code=66:101&islowerlevel=1

        Software engineering is a dark-grey art (as apposed to a black art). As soon as one realizes this, things will start to look different.

        The siren call of hacking and the fundamental difference between an amateur craft discipline and a professional engineering discipline. Let me guess; Self-Taught! The oxymoronic mantra of the incompetant.

        Take your ignorant trolling elsewhere.

  • Tomcat is a surprise? (Score:5, Informative)

    by FortKnox ( 169099 ) on Thursday August 29, 2002 @09:40AM (#4163303) Homepage Journal
    Surprisingly, Tomcat is used in his example setup.

    Surprised? Most Java developers use Tomcat [apache.org] for a servlet app server (not a full blown app server, but you can have that if you tie-in JBoss [jboss.org]). 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.
    • Damn straight, why go with a full EJB container when all you need is a servlet engine.
      Tomcat is the best engine. Resin is supposed to be faster, but it's not. Under heavy heavy load, both cope slightly differently, with a slight edge to resin. Though resin does give weird errors sometimes under heavy load.
    • As a Java developer, I guess I have the rare honor of mentioning that I'm using Tomcat as a servlet engine. The company that I work for uses a servlet engine that was written internally. We also have our own servlet-based templating language that works quite well

      In the future, when I need a servlet engine for my own personal use, I'll probably give Tomcat a try. I've heard good things about it. I'll just continue avoiding JSPs, though. ;)

      • what the hell was I thinking? I left out a very crucial word... here is the corrected sentence:
        As a Java developer, I guess I have the rare honor of mentioning that I'm NOT using Tomcat as a servlet engine.
  • Paul Read's book is one of the most applicable, thorough, and "practiceable" UML books to date (and I have read a lot of them). One of the concepts that was a real breakthrough for me was the event list/table. There always seemed to be a step missing in the transition from a client requirements document to use cases, and the notion of the event list was it. A number of projects I've worked on have suffered from the use cases being far to granular, resulting in a nearly unmanageable number of them. The event list serves as the perfect tool for eliminating this problem.

    While the sample project is not unnecessarily complex, it provides the level of detail necessary to apply RUP and UML to just about any Java project. Furthermore, most UML books fail to move beyond the theoretical level and provide concrete examples. This is not the case with Java and UML. This book is written in a style that is easy to read and will have you familiar with the concepts and applying them to your own projects in a matter of days.
    • Warning, the post above is copied verbatim from a comment on Amazon. There are other posts in this thread that are also copied verbatim, by other users. Somebody is trying to 'spike' this slashdot review... (some randome text here so I can post the same comment)
    • The parent says: ...focuses on building and modeling industrial-strength Java applications

      And then: You do not need to know UML or OO Design...

      Forgive me while I laugh up a lung.

  • put aside the 'jump in and code' attitude (Score:5, Funny)

    by ArcSecond ( 534786 ) on Thursday August 29, 2002 @09:47AM (#4163353)
    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.

    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? ;P
    • How would we know how elite a programmer was

      Disclaimer: I did catch the sarcastic tone of your comment.

      I followed up on the ICFP competition announcement in /. yesterday, and looked at the 2001 ICSF winner's write-up [harvard.edu]. Haskell Carrots took the first day and a half of a 72-hour competition "thinking about the algorithm before writing any code". They look pretty 'l33t to me.
      • They look pretty 'l33t to me

        And me too. I was implying that truly elite programmers think about things deeply, then design, and THEN code. I have just noticed a tendency for geekdom to promote "seat of the pants" design. Which is right up there with improvisational interpretive dance with mimes.

    • The problem is ... (Score:1, Insightful)

      by Anonymous Coward
      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.
      • It isn't up to the managers and designers to make sure the implementation is a good one. That is up to programmers. But the programmers CAN'T make a good piece of software out of a bad spec and bad design. That's like making a good movie from a bad script. I don't care WHO you cast, it is doomed from the start. Ditto s/w dev.

  • Bookpool (Score:3, Informative)

    by Anonymous Coward on Thursday August 29, 2002 @09:47AM (#4163354)
    If you want to buy the book, go to the Bookpool [bookpool.com] site, much cheaper. Here is the link [bookpool.com].

  • What I'd like to know is, did all these people who come up with all these new methodologies only decide to think these up after Java was created? In other words, why weren't these methods ... and all the toolkits and such that are also mentioned ... introduced earlier? Why now? I mean, was it the fact that the Java language came out, or did it just take them this long to figure out these things? Some of these methods could have been useful in 1982, or even 1972, for example. But if the people who thought it up weren't even in college by then, I guess that could explain it.

    • 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.

      • UML is not older than Java. UML is a amalgation of different modeling notations, namely Rumbaugh's Object Modeling Technique (OMT) and Grady Booch's "Clouds". No one liked the clouds... UML looks more like OMT if you ask me.

        Anyway, Java came out in what? 1994, 1995? UML wasn't final until at least 1997.
      • Geee... I thought UML was created to make money selling Rational-Rose and UML books!

        I find it to be overly tricky as a graphical tool - at least if you use a lot of it. If you don't build big class hierarchies (and usually you shouldn't), javadoc lets you find the hierarchical information just fine, and it stays up to date as the code changes.

        My favorite graphical device, as another poster stated, is the Entity Relationship Diagram, which captures the data heart of the sorts of projects I do.

        OTOH I have a friend who works for a company that uses UML from one end of a project to another and thinks it is wonderful and produces a very efficient development environment.

        Oh well...

  • UML (Score:3, Interesting)

    by Anonymous Coward on Thursday August 29, 2002 @10:09AM (#4163525)

    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.

  • had to throw this one out there. (Score:1, Funny)

    by Anonymous Coward
    As I was installing VS.NET the other night (flame me, whatever, some projects have to use it, part of my gig) I browsed throught the old EULA for shits and giggles. I came to a part about java as I was skimming, and it caught my eye, so I slowed down to read that entire section. It said something to the effect of "Java is not fault tollerant and should not be used to create applications for/including life support systems, weapons sys, Hazardous Materials systems, etc..."

    Just thought that was a little funny. Shall we use VB instead for out nuclear tracking systems?

  • I've looked at UML, saw its array of different diagram types and wondered if there are better alternatives.

    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. For example, if use cases really help in capturing requirements, why can't the work spent capturing requirements be directly applicable to the next stages of development (i.e., the requirements work drops right into the next stage without needing to manually recapture the requirements in the next stage)?

    Is UML really more efficient than I think it is, or are there better notations out there that can further streamline the path from requirements to coding?

    • Re:UML vs. the rest... (Score:4, Insightful)

      by bluGill ( 862 ) on Thursday August 29, 2002 @11:06AM (#4163936)

      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. *)

      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?sid =02/0 8/23/012255&tid=108 [remove spaces])

      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.)

    • It has to be remembered that Use Cases are customer-centric. They are intended as a semi-formal communication medium which can be understood by customers, analysts, designers and developers.

      As such, a system which realises a Use Case may look nothing like the Use Case.

      On the other hand, an Object Oriented application is often best designed to mimic the "real world", so your objects and methods tend to drop straight out of a use case.

      The usual technique is to take your annotated UML diagrams and pick out the nouns and verbs for each Case, filter them down to a minimal set, and those are (more or less) your objects and methods.

      This still involves recapturing though, but this is unavoidable. It is dangerous to think in objects at an analysis level - you tend to make invalid assumptions without even realising it. e.g. A developer is a salaries employee and a cleaner is a wage earning employee. Now, where do you put the contact developer ...?

      Because you can't capture the objects along with the requirements, you must identify object candidates from the requirements, and determine a suitable design in which they will interact correctly according to the actions/verbs/messages indicated by the requirements.

      Then you have to consider everything that the users won't like, the managers will add because it may be useful, and the beancounters will strip. Ew, bad image.

      UML is a descriptive language for the entire software process. It crosses domains for which there are no direct mappings ... and if there were, customers would be putting in Use Cases and getting out software, with MicroRational/RationalSoft Inc. in between.

    • I think that you may have missed the connection between the different sets of diagrams in UML.

      The use-cases don't stand by themselves. They just happen to be arguably the most high-level view of the application, and the closest to the process of answering the "what does the client want?" question.

      The connection between the Class Diagrams and the Use Cases, from my point of view, is formed by the Sequence Diagrams. Each Sequence Diagram solves a Use Case through communications between entities from the Class Diagram.

      The Sequence Diagrams translate quite directly to source code, and connects the source code to the Use Cases and therefore to the client's requirements.

      Of course, that's assuming an ideal world where the requirements were correctly collected through the magic of Use Cases in the first place. More likely, by the time you get to Sequence Diagrams something is clearly terribly wrong and you have to correct the Use Cases and recollect requirements, etc.

      The value of the Use Cases is not so much, I think, "making clear the requirements", but having a structured way of getting those requirements linked to the source code when you finally get them right.

    • 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. For example, if use cases really help in capturing requirements, why can't the work spent capturing requirements be directly applicable to the next stages of development.

      From what I know, you can't do a full "UML design" without a CASE tool like Rational Rose. It doesn't appear directly on the diagrams, but you can specify relationships between diagrams that (I guess :) could make looking around the design really convenient.

      For instance: you have feedback from a user, you need to change something. You figure out which actor the user is, then look at all his use cases and modify one or more. You then follow the tracability diagram to the realisations of those use cases - and you know which classes need modifying.

    • It seems to me that what you are complaining about is the fact that the solution doesn't just pop automatically out of the problem description.

      "are there better notations out there that can further streamline the path from requirements to coding" is another way of saying, "I can draw a UML diagram, but I still need to think, isn't there some other way of doing it that cuts out the need to actually think entirely".

      Well, no, there isn't. Furthermore, there never will be. I could say a lot more about this, but I won't. http://www.melloworld.com/Reciprocality/r0/index.h tml might give you an idea where I'm coming from, but frankly I doubt it, I think you're probably beyond help.
      • woah, when did i turn into such an asshole, mmm grouchy today
      • "are there better notations out there that can further streamline the path from requirements to coding" is another way of saying, "I can draw a UML diagram, but I still need to think, isn't there some other way of doing it that cuts out the need to actually think entirely".

        No, this isn't it at all. I'm just wondering if there is a way to capture requirements effectively (hard thinking intact) and have the results of that analysis in a form that can be dropped into the next phases of development. I'm not looking for magical solutions; I'm looking to cut out some of the redundant manual labor and the unnecessary buzzwords and fluff inherent to CASE tools.

        Avoiding the issue by calling me "beyond help" does nothing more than make you look like an arrogant prick.
  • On a related note, what do people think of EJBs?

    EJBs (especially entity beans; session beans (especially stateless ones) are ok, though for 90% of uses regular java classes and static classes could do the same thing) seem to be the antiperl in some respects; it makes the easy jobs difficult and the difficult jobs impossible.

    • Re:EJBs (Score:4, Informative)

      by GusherJizmac ( 80976 ) on Thursday August 29, 2002 @11:04AM (#4163914) Homepage
      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).
      • What of that do you really need? It seems like there are some pretty easy ways of getting connection pooling and transactions (maybe not declared in XML files) without that. Even clustering is simple if you can get your firewall to route the same people to the same machine, and if not, you just have to be a little overhead.

        Given that a "Hello World" session bean takes about 6 or 7 different files, it's hard to believe it's making life simpler.
        • Writing "Hello World" type programs isn't really what EJBs (and J2EE) are good for. You have to do something larger scale to really benefit from them. Have to admit that the number of xml configuration files one has to write sometimes seems overwhelming. Luckily there are tools (such as XDoclet, don't remember the URL, sorry) around that make life easier in that respect.
          • It's a lot more than that. EJBs don't have anything to do with connection pooling. What they do pool is themselves. They are inherently single-threaded, so you get a pool of them, which the container controls. More work needs to get done, more EJBs are dynamically instantiated. You do get automatic transactionality, that's a nice benefit, but as others have said, it's not a really difficult thing (though the rules relating to locking and concurrency options are handled nicely in deployment descriptors instead of code).

            You also get built-in support for security (again, thru deployment descriptors). And of course, Entity EJBs give you a persistent data structure, essentially a table row, in which you provide no database-specific code.

            Whoever said clustering is easy simply isn't paying attention. The routing part is the easy part, but what about stateful information, like a user's http session? That needs to be replicated so that when one server goes down, a backup has a copy of what was going on in his session. Sure, you could back it up to the database, but that's a DB hit every page click or so. Session replication is not a trivial problem to solve. This is why you pay big bucks for J2EE app servers, among other reasons.

        • Re:EJBs (Score:3, Informative)

          by GusherJizmac ( 80976 )
          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.
          • 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.
      • Yeah! Instead of solving the problem and implementing business logic just stuff it into some inflexible transaction-driven model written in a language composed of multiple idiosyncrasies of its authors, and call it a solution.

        It's yet another one-size-fits-all solution for people that can't design their way out of a wet paper bag -- it is for software development what "wizards" are for system administration.
      • If you are creating a large system, you do NOT want to be hacking ASP, PERL, PHP

        That's in a theory, if there is no legacy system. A practive is more complicated, as usually. You've got a legacy system, you have to integrate with, and that system use a mix of languages, protocols, layers and architectures.

        Sure you can create a layer of EJB components interfacing with the legacy stuff and hardcoding the logic of both new and old systems.

        Personally I prefer XML to deal with such interfaces - XSLT wherever pipes work and SOAP when it crosses a network. And if new system can be design based on XML - fine, let it all be XML (XSLT or SOAP) - one system, one maintenance, one set of required skills and tools. Besides, with XML I feel much more comfortable when I verify both logic and data consistency. And I don't care what languages are integrated if they support XML (most of modern lang do).

        As for EJB... I don't like it. I don't like how Sun handle EJB specs and I don't like how Sun handle Java specs. It might be better organized than some open source lang (like Perl), but it doesn't appreciate my creativity.

        Besides, when I need a distributed system with several big app servers and lots of remote PC clients and embedded agents then I cannot use EJB everywhere, I don't have enough RAM/CPU for it everywhere. In such a case I am initially forced to choose something that will work everywhere. Here I come again with XML, processed by Java in app servers and by C/C++/Python/Perl/VB on remote clients/agents.

  • Just want to mention ArgoUML [argouml.org], a Opensource UML tool. Then I wanted to ask, if anyone of you has already worked with UML in combination with PHP and MySQL. I've just started modelling my database along the UML profile for data modelling and like it so far. I hope to generate some code from it, but there are still quite a few sources to write...
    • (* Then I wanted to ask, if anyone of you has already worked with UML in combination with PHP and MySQL. I've just started modelling my database along the UML profile for data modelling and like it so far. *)

      Most PHP and MySQL shops are not into OOP that much (I did *not* say all). There is not much info out there on non-OO UML diagrams besides ER diagrams. The industry ignores those who think OOP is a pile of tangled, rigid, bloat-producing hype-crap and don't want to use it. Too bad there is not a publisher which specializes in closet OOP haters. (Well, I am certianly not in the closet on that one :-)

      Non-OOP software engineering is virtually ignored by the press and publishers, yet *many* shops still willingly ignore OOP or only pay lip-service to it in order to sound in-style.

      (oop.ismad.com)
      • Most PHP and MySQL shops are not into OOP that much (I did *not* say all).

        At the moment, I'm just interested in one pilot customer for such a product, and I think I have one...

        There is not much info out there on non-OO UML diagrams besides ER diagrams.

        The OMG papers on data modelling are great. I just had the problem, that all my PDF readers lose most of the images! But I could reproduce most of the info, I guess..

        The industry ignores those who think OOP is a pile of tangled, rigid, bloat-producing hype-crap and don't want to use it. Too bad there is not a publisher which specializes in closet OOP haters. (Well, I am certianly not in the closet on that one :-)

        I think the word has to be spread bottom up. Don't wait until IBM tells you, how to do it right. The latest data modelling paper is from May and it's good enough so I could start a model for a auction site. I want to create SQL plugin for ArgoUML to generate code for it. If you are interested in any form of collaboration, drop me a mail at a_rueckert@gmx.net
  • Is it possible to use UML concepts with Fortran 77? Now that is a book I would buy.
    • Fortran is procedural not oo; so no UML
      • (* Fortran is procedural not oo; so no UML *)

        Although UML is not *purely* for OO, it is biased towards it.

        Like I say in the PHP message, the industry is currently biased toward OOP dispite the fact that many shops reject many OO concepts and show no signs of changing that aspect.

        Non-OO'ers are nose-thumbed. Well, I finger OO in return. Get some fricken real OO evidence instead of brochure babble and we might just change.
  • This book has the advantage that it lays things out step by step. Even when there is not enough time to follow through a full design process, having the knowledge well laid out in your mind when you do your quick design is an immense help. With most books seeming to jump that "middle step" that everyone is expected to know, this one plants it right in the middle making it easy and clear to follow.

  • Sounds useful... (Score:2, Interesting)

    by eaeolian ( 560708 )
    First off, a congrats on a detailed, quality book review. This sounds like a valuable reference for people working in this environment.

    Speaking from experience, I can tell you that using UML and Java together can be a very rewarding (and timesaving) experience, so I applaud this book's direction. Whatever methodology you choose, I feel that software impelementation is only going to get better when companies realize that time spent doing discovery and design is as (or frequently more) important than the time spent coding. My current contract is just now learning this, the hard way...

  • Not for 99% of projects (Score:1, Insightful)

    by Anonymous Coward
    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.
    • (* This book is for projects made in heaven - i.e. the defence and NASA contracts where there are tons of money. *)

      NASA has money to burn? (Rocket pun not intended.) I don't think so. Perhaps you really meant "good at wasting money". IOW, it is the output process and not the input process.

      UML diagrams can certianly turn into a money pit if you are looking for ways to increase your staff and look big and busy.

      Perhaps a project that fails that has tons of diagrams to show for it will not look as bad if it fails and all the walls are empty. IOW, it is a manifestation to the superficial types that "at least we gave it a good effort".

      It is yet another technique in politics-heavy orgs to fail yet not look bad.

      I am waiting for the book, "How to bullshit your way to the top in IT". There is one about contractor scams and trickery, but I don't remember the name of it right now.

    • Re:Not for 99% of projects (Score:2, Insightful)

      by MarkX ( 716 )

      Disclaimer: I haven't read this book, but I have read many in the Addison-Wesley series on UML, RUP, etc.

      Can't agree with you at all. Once you have more then a handful of members on a development team a process of some type is necessary. Otherwise you have people wandering off doing their own thing and duplicating work, or contravening major design principles.

      I have personally used UML and a modification of the RUP process for projects under $50,000. My team delivered these projects under tight time and budget constraints. Without the ability to design ideas and document them ahead of time I feel we would have wasted significant time and blown the dead lines out of the water. This doesn't fly with clients.

      Unfortunately some people, mainly clients, think creating diagrams of the system is busy work. I've found the easiest way to deal with that is to share the diagrams with clients and explain them as you go. This works good with activity diagrams that illustrate business processes. This helps catch errors in our perception of what the clients want before any code is commited. Once you explain that to the client they are generally sold.

      The other things is unless you have a process of some type you are bound to forget things. Things will slip through the cracks. Things will get off radar. A process and UML help keep things organized.

      So, I would say that the real world requires something like the Rational Unified Process once yet have more programmers than fit in a VW Bug, or you get over a handful of classes.

      MarkX

  • RUP, IMHO comes short when it comes to developing software that is really valuable to end customer. Check out the demo [rational.com] here. RUP wants to divide the whole s/w development process into stages and proceed in a systematic fashion where progression into one stage completely disqualifies the previous stages. The problem is that most of the times the customer never really understands what is possible and what really is required to address a business and/or process need. Which really translates to improper requirements. This is also the cause of user dissatisfaction because by the time s/w arrives the business needs/environment may have changed or shows symptoms of the same. This is very disconcerting to the end customer for his time and expenditure.

    This is why Extreme Programming [extremeprogramming.org] is a bit more applicable to what we know about s/w development, how much can we communicate to the end user, how can we make it easier for developers to let users participate in all stages of development.

    That said, I actually like UML a lot. The use cases work in larger contexts while class diagrams work in narrow contexts i.e. 2-4 people can really understand what you are trying to communicate. The sequence diagrams are priceless, because even managers can follow some of it. I like to combine class diagrams with a design pattern [GoF] applications.

    Rational now has an extreme programming plug-in [rational.com]. That very statement makes me run in the opposite direction. XP is often compared to Open Source, where users really know what they want and the whole process is more conversational rather than a contract that's been handed off to a developer.

  • The article mentions Viso, and rational rose both of which are expensive windows programs. So does that mean cash strapped geeks are forced to use a windows box, download a crack and use that? No. There are good alternatives that are free and don't need windows. The first one that comes to mind is Gnome's DIA [gnome.org].

    To quote Gnomes web site "DIA is a drawing program, designed to be much like the commercial Windows program 'Visio'. It can be used to draw various different kinds of diagrams. In this first version there is support for UML static structure diagrams (class diagrams), databases, circuit objects, flowcharts, network diagrams and more."

    Another option is Argo UML which is also free and programmed in java Argo [tigris.org]

    • I use Dia whenever I want to draw a UML diagram. I wouldn't, however, use it if I ever had to do a full UML design. CASE tools (as opposed to drawing programs) give you a whole bunch of valuable navigation facilities, a higher degree of error checking etc.

      Argo looks quite nice :)
  • The problems with UML tools is that they [sometimes] generate skeleton code out of your models, and then you go in and fill in the "meat". However, if you change the model then either you lose your changes (i.e.: the meat you put in after countless hours of effort) or you have to forget about changing the model with the tool and do changes yourself.

    So what I think we need is some form of tool that always matches the model to what you're programming. More or less like what IDEs do when you're designing a GUI while the write code automatically to represent the GUI, while allowing you to change the GUI code and have those changes reflect in the GUI design itself.

    With a tool like that, it could also be possible to generate a UML schema from your own spaguetti code, and then change the model visually, with the net efect that the tool would refactor your classes, method calls, variable names, and packages to match the model.

    And of course, with a such a tool you could (and should for all new projects) start with the UML in visual mode, and then fill in the specific code.

    Note that I've seen countless tools that claim to do this, but none of them really give you enough freedom to make changes on the code or in the model.
    • Take a look at SAND [epinova.com], which is an approach to enterprise app development that solves most of these problems by making heavy use of code generation. Unlike most projects where the code is generated up front and then modified by hand, SAND puts code generation into the build cycle of the product so the code and model are always in sync (if you're going to complain that this makes the build take longer, don't. Trust me, it's better this way).

      There's an open-source implementation of SAND called Sandboss [sf.net] that's getting off the ground; while it's still missing pieces, it's rapidly becoming functional (most of the generators are in place already, so take a look). The prepackaged version is out-of-date, so look at the CVS tree.

      Right now there's no UML-to-SAND tool or any kind of visual editor, so you'll have to spec your objects as you go. It's a lot easier than it sounds.

      Disclaimer: I'm working on sandboss because it kicks ass. I used a previous incarnation at my last job, and it saved literally man-years of development.

    • The last time I had access to rational rose (about 3 years ago), it handled this just fine.
      It generated special comments, between which you but "the meat". When you changed the model, it kept the meat.
      If you deleted a method, it gave you a warning and would keep the meat code for one cycle. If you ignored the warning twice, the code from the deleted method was gone.

      But if you were carefull, it did not have the problem you describe.
      I would have kept on maintaining the design/code this way if only it had been able to emit the DLLEXPORT between the keyword "class" and the name of the class (this was C++).
      Since the code in question had to be packaged in the DLL, I had to quit using
      the "forward engineering" code generation.

      But if you were not doing a C++ DLL, you should not have this problem.
    • Together/J from together.com just does that.

      angel'o'sphere

  • Two classes? (Score:4, Funny)

    by anonymous_wombat ( 532191 ) on Thursday August 29, 2002 @01:33PM (#4165145)
    For example, an application with 70,000 lines of Java code that only contained two classes.

    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.

  • Well it looks like I'm going to be buying another book. I've been looking for a good way to document object-oriented programs for a LONG time. I've heard about UML and browsed a few web pages but just didn't really understand it well enough to see it's value. Maybe this book will get me through the learning curve.

    Could someone who really understands UML tell me if it will handle documenting object-oriented programs that use third party objects? For example, if I code something using Borland's Kylix, I may not have the source code to some of the components that I'll be using. How does one effectively document in this situation?
  • Compare this [amazon.com] and this [slashdot.org]

    This [slashdot.org] is copied from Amazon as well.

    Someone else noticed that, but his comments got buried in level 2 of this thread. (so I'm aware, that my posting is redundant, but hopefully someone will mod this up and warn people).

    Remember: Never take slashot or amazon ratings too serious.

Slashdot Top Deals

An adequate bootstrap is a contradiction in terms.

Close