Re:I wrote a book on UML, but use it lightly
on
UML Fever
·
· Score: 1
I think the purpose of unifying modelling language is not to make everyone use every single pieces in it.
It definitely make sense to be working with only the highest value diagram type that work for you and the nature of the work you are doing.
Like you, my engineers and I worked primarily based on the same set of diagram types that you have mentioned, because it worked for us too. Often, we also like to go a step further to do IDLs and lower level class diagrams, and sometimes state diagrams, especially when dealing with CORBA.
Personally, I think the important thing is for us to produce good use cases, good general class diagrams, and good sequence diagrams all the time. Because for these, the reader of the diagrams will always appreciate. (though they do not know it, until they see a bad one)
Re:Don't confuse modelling and UML
on
UML Fever
·
· Score: 1
It is difficult not to confuse when the M stands for modelling, right?
But I understand where you are coming from. Modelling itself can be a pretty abstract concept and broad subject, especially when ones tried to unified it into some language. Or until it is applied to a specific subject, for example design patterns.
To some, modelling is as simple as drawing 2D boxes and making relationship diagrams.
To some, modelling is done in 3D and visualisation.
To others, modelling is when someone parades on stage, or something made from Lego.
Re:Designs cast in Stone
on
UML Fever
·
· Score: 1
Parent is exactly right:
Actually, I don't quite agree with your parent's (original) post. But I agree with what you said about being interface driven...
The original post suggested that a design flaw was spotted in the pattern(?), by _looking_ at the UML diagrams. And this actually illustrate one of the advantage of UML - spotting problem during design phase.
However, the original poster associate the design flaw with the use of UML. Because the UML designers refused to make changes. And I think this is the main problem - the problem is with
1. the poor design and
2. the uncompromising attitude of the UML designers.
If the programmer and designer aren't the same person, I'd argue that the project is already in trouble.
Not necessarily, I'd argue otherwise.
One of the way to make this work is to bring Xtreme Programming from coding to designing too.
For example, you design this side of the interface, I design the other side of the interface. And then, I implement this side of the interface that you had design, and you implement the other side of the interface that I had design.
So, you see, the designer and programmer are different persons, one design and the other code what was designed. And this can work pretty well actually.
Of course, for argument sake, this can still means that the programmer and the designer is the same person, since they are both working on the/same bigger thing/.
This also requires both parties (you and I in this case) to trash out any misunderstanding during designing phase, or during early stages of coding. And it will definitely help when both are versed in, for example UML.
Re:Boring, but true story
on
UML Fever
·
· Score: 3, Insightful
If it is a major design flaw discovered late, then this really sucks, especially if it is due to lack of foresights or experiences.. But hey, that is how we gain experiences.
Actually my experience tells me that UML can be very suitable for fast prototyping. And one of the lethal combination for success, in my opinion is UML+IDL+CORBA(Java)+eXtreme Programming.
It can be quite amazing how a prototyping team can churned out results, with the help of everything good, like generated skeletons, and stubs, and it helped us to get something very functional up and running, and then allows for subsequent iterative improvements that is almost transparent to the users, even changes implementation between C++ and Java. Of course, not forgetting dedicated engineers and everyone's commitment.
Before reading on, let me just say that I am a proponent of using UML/IDL/Design patterns. So..
One of the idea of UML is that this framework allows for people of different roles to converse in a common modelling language.
A business/product person will easily understand Use Case and high level sequence diagrams.
A product architect/designer is able to transform these use cases and sequence diagrams into "lower level requirements" - more sequence diagrams, state diagrams, and define the IDL interfaces relationships between interacting "boxes".
An engineer is able to take in these low level requirements, read the state diagrams and IDLs, create the component and class diagrams, and generate the skeleton codes for actual implementation.
From managing requirements point of view, UML is a good tool, provided that everyone in the food chain understand their roles and know how to create proper diagrams and read their counterpart's diagrams. (You cannot blame the tool if someone do not know how to do their work.)
In case someone misunderstood me, UML itself is not sufficient for software development, but with UML, the whole software development can be a much pleasant tasks.
Overall, (I think) UML does make my engineering team more efficient - you know when the first thing my fellow engineers do after opening a specification document is to look for some UML diagrams.
The article mentioned that it is "...no more an abuse than a viewer fast-forwarding a tape in his own home."
But this player sure sounds like skipping over a portion of the content, rather than "fast forwarding" over the content.
In my opinion, their analogy sounds grossly incorrect.
Re:mapping GPS while running/biking/hiking.
on
Running for Geeks
·
· Score: 1
On similar note... not as advance as using GPS tracker.
I had fun collecting the cell ids with my previous Nokia 9110 mobile phone using Cell Tracker (GPL), when I was jogging or cycling or travelling.
Each time a new cell was picked up.. it would go beep beep beep.. and at the end of my jog, I would have a list of cell ids that denote the path that I had covered.
(So all my jogging paths were denoted by a list cell ids, instead of a list of street names!)
When(If) they come out with a roadmap from AIX to Linux, THAT will really mean something, and will be a victorious day for both IBM and Linux I will look forward to.
It is not easy and takes a lot of will power to shed old baggages.
Quote BBC : Microsoft has a cash pile of more than $50bn, so even a fine on this scale - a record for the EU in an antitrust case - is unlikely to hurt it commercially.
How can the punishment serve a deterent, if the fine does not hurt??
It is a prerequisite to presume that the service chain must be driven with trustworthiness. The old folks who are illiterate must trust the messenger, and the sender must assume the delivery chain is trustable.
Imagine a powered-by-human ATM cash machine.
Normal mail has the implicit benefit of sealed delivery, until received by the receipient.
Slashdot Mirror
It definitely make sense to be working with only the highest value diagram type that work for you and the nature of the work you are doing.
Like you, my engineers and I worked primarily based on the same set of diagram types that you have mentioned, because it worked for us too. Often, we also like to go a step further to do IDLs and lower level class diagrams, and sometimes state diagrams, especially when dealing with CORBA.
Personally, I think the important thing is for us to produce good use cases, good general class diagrams, and good sequence diagrams all the time. Because for these, the reader of the diagrams will always appreciate. (though they do not know it, until they see a bad one)
But I understand where you are coming from. Modelling itself can be a pretty abstract concept and broad subject, especially when ones tried to unified it into some language. Or until it is applied to a specific subject, for example design patterns.
To some, modelling is as simple as drawing 2D boxes and making relationship diagrams.
To some, modelling is done in 3D and visualisation.
To others, modelling is when someone parades on stage, or something made from Lego.
Actually, I don't quite agree with your parent's (original) post. But I agree with what you said about being interface driven...
The original post suggested that a design flaw was spotted in the pattern(?), by _looking_ at the UML diagrams. And this actually illustrate one of the advantage of UML - spotting problem during design phase.
However, the original poster associate the design flaw with the use of UML. Because the UML designers refused to make changes. And I think this is the main problem - the problem is with
1. the poor design and
2. the uncompromising attitude of the UML designers.
UML as a modelling language, is innocent.
Not necessarily, I'd argue otherwise.
One of the way to make this work is to bring Xtreme Programming from coding to designing too.
For example, you design this side of the interface, I design the other side of the interface. And then, I implement this side of the interface that you had design, and you implement the other side of the interface that I had design.
So, you see, the designer and programmer are different persons, one design and the other code what was designed. And this can work pretty well actually.
Of course, for argument sake, this can still means that the programmer and the designer is the same person, since they are both working on the /same bigger thing/.
This also requires both parties (you and I in this case) to trash out any misunderstanding during designing phase, or during early stages of coding. And it will definitely help when both are versed in, for example UML.
This is unfortunate..
There are many reason why projects fail, so I do not want to speculate. But my favourite is Anti-Patterns in Project Management (review)
If it is a major design flaw discovered late, then this really sucks, especially if it is due to lack of foresights or experiences.. But hey, that is how we gain experiences.
Actually my experience tells me that UML can be very suitable for fast prototyping. And one of the lethal combination for success, in my opinion is UML+IDL+CORBA(Java)+eXtreme Programming.
It can be quite amazing how a prototyping team can churned out results, with the help of everything good, like generated skeletons, and stubs, and it helped us to get something very functional up and running, and then allows for subsequent iterative improvements that is almost transparent to the users, even changes implementation between C++ and Java. Of course, not forgetting dedicated engineers and everyone's commitment.
Before reading on, let me just say that I am a proponent of using UML/IDL/Design patterns. So..
One of the idea of UML is that this framework allows for people of different roles to converse in a common modelling language.
A business/product person will easily understand Use Case and high level sequence diagrams.
A product architect/designer is able to transform these use cases and sequence diagrams into "lower level requirements" - more sequence diagrams, state diagrams, and define the IDL interfaces relationships between interacting "boxes".
An engineer is able to take in these low level requirements, read the state diagrams and IDLs, create the component and class diagrams, and generate the skeleton codes for actual implementation.
From managing requirements point of view, UML is a good tool, provided that everyone in the food chain understand their roles and know how to create proper diagrams and read their counterpart's diagrams. (You cannot blame the tool if someone do not know how to do their work.)
In case someone misunderstood me, UML itself is not sufficient for software development, but with UML, the whole software development can be a much pleasant tasks.
Overall, (I think) UML does make my engineering team more efficient - you know when the first thing my fellow engineers do after opening a specification document is to look for some UML diagrams.
But this player sure sounds like skipping over a portion of the content, rather than "fast forwarding" over the content.
In my opinion, their analogy sounds grossly incorrect.
I had fun collecting the cell ids with my previous Nokia 9110 mobile phone using Cell Tracker (GPL), when I was jogging or cycling or travelling.
Each time a new cell was picked up.. it would go beep beep beep.. and at the end of my jog, I would have a list of cell ids that denote the path that I had covered.
(So all my jogging paths were denoted by a list cell ids, instead of a list of street names!)
weird...
Only funs allowed.
Serious discussion strictly forbidden!
Good idea if this helps to get us off channel surfing?
On the other hand, maybe all we need is just one channel - Slashdot.org editors reporting live on site...
Before link,
After link.
When(If) they come out with a roadmap from AIX to Linux, THAT will really mean something, and will be a victorious day for both IBM and Linux I will look forward to.
It is not easy and takes a lot of will power to shed old baggages.
If GO Penpoint software was open-sourced 14 years ago... as an attempt to counter Windows H agression...
I wonder what would the landscape of mobile computing be like today?
The EU Population in 2003 is 378,988,100 (estimate).
So it is about 1.311 EUR per EU inhabitant.
Not even a single trip bus fare.
How can the punishment serve a deterent, if the fine does not hurt??
It would be interesting to hear out to anyone that might have really tried such a combination - Xeon with let say 8MB RAM(existence?)..
"It blazingly fast.. but it ran out of memory during bootup.. using kernel 1.2.."
... to this service
It is a prerequisite to presume that the service chain must be driven with trustworthiness. The old folks who are illiterate must trust the messenger, and the sender must assume the delivery chain is trustable.
Imagine a powered-by-human ATM cash machine.
Normal mail has the implicit benefit of sealed delivery, until received by the receipient.
Videophone conferences? But do you see the video camera anywhere convenient placed? Can it really get so tiny?
Only 4 buttons shown - a little too few, imho. A simple digital watch have 4 buttons. Compromised usability?
The screen texture looks too curvy and silk-ed, which will prove irritating for pen based input. Maybe voice input all around? Have fun!
As a conceptual device, it looks good, but I'll bet its unpopularity if this device is ever actually put on store shelf.
Somehow, I feel that Dick Tracy will not look as smart if he was to wear this gadget.
Battery life is the important question, imho.
You don't want a waist PDA spec-ed out so good to be true that you have to carry the spare power source in your other pocket.
Looks decent.
With this, my good friend's band could have a revenue stream finally.
I thought the sun has set on the wrong side suddenly.
Oh.. you mean you are talking about the real planet Mars?
Precisely.. the sale of CDs(or records or cassettes for the matter) has everything to do with the talent of the artistes (and the marketing muscle).
The artistes must be good for the sales will soar.
A peripheral tool like file sharing is basically, just a peripheral tool.
since it cannot really do a lot (of damage) in the first place!
Anyway, a shell is just a shell is just a shell...
through the eyes of the thousand audience.
And the evil in the air fogging the dark ceiling.
Here in Mordor... the King will lead from the right of the stage, the "Paths of the Dead", and sweep the thousands Sauron army on the floor to dust.