Kevin; Those references look very good!
Andregatti; I switched over to RUP/UML in 2000. I like them a lot; they are the mainstay of my practice. Even so, I still reach back to the old tools, or invent new ones, to cope with certain specific situations.
Both RUP and UML, as well as other methodologies and modeling tools, are advisory; stay as close to them as you can (both to keep everyone in sync and that there is a lot of thought and reasoning that went into their design that will keep you out of trouble), but, with knowledge and understanding, modify and extend them as appropriate to your needs.
Just for the sake of rigor, may I ask what you mean by
Real-time? In my working definition,
a Real-time system is one that reacts to domain related events in time to effectively control operations therein and thereby achieve the goals of the application within that domain. (Sorry, somewhere around here I have a less verbose definition, but that is the essence of it.)
By that definition, If the goal of a payroll system is to keep employees loyal and properly incented, it would appear that a payroll system that generates a pay check every two weeks could be considered real-time.
Of course, a two-week cycle time for an autopilot on a sail boat is not good, nor is a few seconds sufficient for a machine vision system that is inspecting parts as they fly through the center of a circular fluorescent light tube and making decisions to accept or reject the part.
My concern here is that the term
Real-time is often used by my clients as a synonym for
On-line interactive which is "a different kind of a horse altogether".
What are the cycle-time requirements of your proposed system?
