Just FYI, according to StatsCan (http://www.statcan.gc.ca/kits-trousses/cyb-adc1999/ecozone/edu04_0092f-eng.htm) lists the largest 1-day snowfall in Canada at 118.1 cm at Lakelse Lake, B.C., on January 17, 1974. Other sources (e.g., http://www.currentresults.com/Weather-Extremes/Canada/snowiest.php) list Tahtsa Lake, BC, receiving 145 cm of snow on February 11, 1999.
Both are far below your 8m statement...
Now snow drifts, especially against a building, will get much higher...
Well... I'm in Canada and I tried calling Canada last night (same town even!) and it did not work... Maybe there are still some glitches...
Re:Here is a really easy methodology:
on
UML Fever
·
· Score: 1
You are confusing modeling language with methodology.
In your example, steps 5 and 7-9 can be done using UML, either with a tool or on paper.
If you use a tool, it's also easier to modify your diagrams from steps 8 and 9 when doing cyclic development...
Re:Is UML really a language?
on
UML Fever
·
· Score: 3, Informative
Things are changing... Look at the Eclipse UML2 project (http://www.eclipse.org/uml2/).
There is an OMG standard for the serialization of UML model: XMI. And there is an OMG guideline on transforming the models: MDA.
Now, if only all tools adhered to the XMI standard as their main storage method... Although most can currently output some variant of XMI (although there's just too many right now).
But then again, this is all about tools. There is nothing that would prevent you from using the UML notation on a whiteboard...
Actually, if you look at recent Microsoft technical presentation, they are going towards a "whatever notation makes sense" rather than "UML everywhere".
That has always been a problem. But that is mostly because people do not know when to transition from UML to code. Let's face it, there are much better tools out there to develop code than UML tools as they currently stand!
With today's tools, and unless you have a very specialised application, using UML for writing code is ridiculous. As such, UML should be kept for use at the analysis level. If you are intent on using UML to generate code, you should ensure that you do so early enough that your model stays at a level of abstraction that is high enough not to be overly influenced by changes in the code.
Again, UML is just a tool in your toolbox and certainly does not apply all the time and does not preclude good coding techniques!
Re:Designs cast in Stone
on
UML Fever
·
· Score: 2, Informative
Actually, UML can also be useful for smaller projects, but used in a different way...
For smaller projects, you can use UML in a UMLAsSketch mode (http://www.martinfowler.com/bliki/UmlAsSketch.htm l). In this mode, all UML does is to allow for a common graphical "language" for expressing your ideas.
For larger project, you can move on to UMLAsBlueprint (http://www.martinfowler.com/bliki/UmlAsBlueprint. html).
For certain, very specific projects, with very well defined semantics, and very well defined transformations, you can move on to using UMLAsProgramminglanguage (http://www.martinfowler.com/bliki/UmlAsProgrammin gLanguage.html).
Note that I do not completely agree with where Fowler puts his markers in the continuum of the modes to using UML. I think, for example, that his UMLAsBlueprint is too close to his UMLAsProgramminglanguage. But this may be due to his propensity towards Agile methods.
One thing to keep in mind is that UML is a "language"! It is a means to express a software system. It is _NOT_ a panacea to all software development woes and it does _NOT_ replace good architecture practices! Anyone who thinks the opposite is doomed to failure (and anyone who improvises themselves software architect because they know UML doubly so!).
Re: Everything, including tools, in moderation!
on
UML Fever
·
· Score: 5, Insightful
Let's not forget that a pattern is a solution to a problem in a context. If the context does not match your situation, then don't use it - even if the problem is the same and the solution is attractive.
That's why Quebec did not suffer the outage. They have AC-DC-AC links to the States that insulates them from a lot of problems. If I remember correctly, it was a requirement of a contract to sell power (the US were tired of the outages created by Hydro-Quebec).
There is even a 600 Vdc line going directly from La Grande on James Bay to the US.
One problem with DC transmission is cost. Over long distances, it is cheaper than AC, but not over short distances. I don't remember where the break-even point is - it's been 20 years since I last designed a transmission line...
There was an interesting Twilight Zone episode (or some similar show) set in the future where artists had to have all their work checked before publication and could not publish if any part of their work was found as a part in a previous work.
You can well imagine that there weren't many artists left and that those left were turning into mental cases...
I know quite a few already replied, but I just wanted to give a coupld of examples of why electricity is dangerous...
I have a friend who was working on the electrical system on a boat. The system works with a 12 Volts battery. While trying to tighten a nut close to the battery, his hand slipped. The wrench touched one pole of the battery, which touched a steel ring on his hand, whith then touched the other pole. The contact must not have lasted a second, but the ring was red hot and he got a nice burn (and a permanent scar-ring).
The other incident, which may be more relevant, involved myself working on an 600V three-phase electic motor. I inadvertently touched two phases with my hand (yes, my other hand _was_ in my pocket) - that's about 347V p-p. My hand was numb and I could not use it for about an hour. I am _so_ glad that the current only went through my hand!
Believe me, I have _always_ been careful around electricity and I still got into trouble. Your luck _will_ run out.
I got a Zaurus and it's a cute little device and great for some demos I have done. However, for pure usability, I am now on my third Palm-based device. Batteries last longer, sync works better, and it is more portable (I don't have one of the monstrous Sony...).
I do like to hideaway keyboard on the Zaurus though...
RTFM...
With ClearCase snapshot views, you can put your "sandbox" on your workstation and they are available even if the network is down. That's what I do to bring work home on the laptop... Then I just have to update when I get back to the office.
The product was called ObjecTime Developer and, with the Rational Rose core, became the basis for Rational Rose RealTime.
ROOM is "Real-Time Object Oriented Methodology", which also happened to be the title of the book Bran published with Garth Gullekson and Paul Ward. You can find the book here.
Bran is currently employed by Rational (i.e., the fourth amigo) and still active in the UML specification world. BTW, a lot of the concept of ROOM that made their way in the Real-Time profile for the UML are making their way into UML 2.0.
Actually, this would not be acurate...
ClearCase MultiSite is used between Rational's development sites. ClearQuest MultiSite is used to track defects and requirements. RequisitePro is used by many product managers. The Rational Unified Process is also in use. Purify and Quantify are used by the development teams, PureCoverage by the QE team. And XDE is also in use.
How do I know? I work there...and use these tools almost every day.
Slashdot Mirror
Just FYI, according to StatsCan (http://www.statcan.gc.ca/kits-trousses/cyb-adc1999/ecozone/edu04_0092f-eng.htm) lists the largest 1-day snowfall in Canada at 118.1 cm at Lakelse Lake, B.C., on January 17, 1974. Other sources (e.g., http://www.currentresults.com/Weather-Extremes/Canada/snowiest.php) list Tahtsa Lake, BC, receiving 145 cm of snow on February 11, 1999. Both are far below your 8m statement... Now snow drifts, especially against a building, will get much higher...
Well... I'm in Canada and I tried calling Canada last night (same town even!) and it did not work... Maybe there are still some glitches...
You are confusing modeling language with methodology.
In your example, steps 5 and 7-9 can be done using UML, either with a tool or on paper.
If you use a tool, it's also easier to modify your diagrams from steps 8 and 9 when doing cyclic development...
Things are changing... Look at the Eclipse UML2 project (http://www.eclipse.org/uml2/).
There is an OMG standard for the serialization of UML model: XMI. And there is an OMG guideline on transforming the models: MDA.
Now, if only all tools adhered to the XMI standard as their main storage method... Although most can currently output some variant of XMI (although there's just too many right now).
But then again, this is all about tools. There is nothing that would prevent you from using the UML notation on a whiteboard...
Actually, if you look at recent Microsoft technical presentation, they are going towards a "whatever notation makes sense" rather than "UML everywhere".
That has always been a problem. But that is mostly because people do not know when to transition from UML to code. Let's face it, there are much better tools out there to develop code than UML tools as they currently stand!
With today's tools, and unless you have a very specialised application, using UML for writing code is ridiculous. As such, UML should be kept for use at the analysis level. If you are intent on using UML to generate code, you should ensure that you do so early enough that your model stays at a level of abstraction that is high enough not to be overly influenced by changes in the code.
Again, UML is just a tool in your toolbox and certainly does not apply all the time and does not preclude good coding techniques!
Actually, UML can also be useful for smaller projects, but used in a different way...
m l). In this mode, all UML does is to allow for a common graphical "language" for expressing your ideas.
. html).
n gLanguage.html).
For smaller projects, you can use UML in a UMLAsSketch mode (http://www.martinfowler.com/bliki/UmlAsSketch.ht
For larger project, you can move on to UMLAsBlueprint (http://www.martinfowler.com/bliki/UmlAsBlueprint
For certain, very specific projects, with very well defined semantics, and very well defined transformations, you can move on to using UMLAsProgramminglanguage (http://www.martinfowler.com/bliki/UmlAsProgrammi
Note that I do not completely agree with where Fowler puts his markers in the continuum of the modes to using UML. I think, for example, that his UMLAsBlueprint is too close to his UMLAsProgramminglanguage. But this may be due to his propensity towards Agile methods.
One thing to keep in mind is that UML is a "language"! It is a means to express a software system. It is _NOT_ a panacea to all software development woes and it does _NOT_ replace good architecture practices! Anyone who thinks the opposite is doomed to failure (and anyone who improvises themselves software architect because they know UML doubly so!).
Let's not forget that a pattern is a solution to a problem in a context. If the context does not match your situation, then don't use it - even if the problem is the same and the solution is attractive.
That's why Quebec did not suffer the outage. They have AC-DC-AC links to the States that insulates them from a lot of problems. If I remember correctly, it was a requirement of a contract to sell power (the US were tired of the outages created by Hydro-Quebec).
There is even a 600 Vdc line going directly from La Grande on James Bay to the US.
One problem with DC transmission is cost. Over long distances, it is cheaper than AC, but not over short distances. I don't remember where the break-even point is - it's been 20 years since I last designed a transmission line...
There was an interesting Twilight Zone episode (or some similar show) set in the future where artists had to have all their work checked before publication and could not publish if any part of their work was found as a part in a previous work. You can well imagine that there weren't many artists left and that those left were turning into mental cases...
I know quite a few already replied, but I just wanted to give a coupld of examples of why electricity is dangerous... I have a friend who was working on the electrical system on a boat. The system works with a 12 Volts battery. While trying to tighten a nut close to the battery, his hand slipped. The wrench touched one pole of the battery, which touched a steel ring on his hand, whith then touched the other pole. The contact must not have lasted a second, but the ring was red hot and he got a nice burn (and a permanent scar-ring). The other incident, which may be more relevant, involved myself working on an 600V three-phase electic motor. I inadvertently touched two phases with my hand (yes, my other hand _was_ in my pocket) - that's about 347V p-p. My hand was numb and I could not use it for about an hour. I am _so_ glad that the current only went through my hand! Believe me, I have _always_ been careful around electricity and I still got into trouble. Your luck _will_ run out.
I got a Zaurus and it's a cute little device and great for some demos I have done. However, for pure usability, I am now on my third Palm-based device. Batteries last longer, sync works better, and it is more portable (I don't have one of the monstrous Sony...). I do like to hideaway keyboard on the Zaurus though...
RTFM... With ClearCase snapshot views, you can put your "sandbox" on your workstation and they are available even if the network is down. That's what I do to bring work home on the laptop... Then I just have to update when I get back to the office.
The product was called ObjecTime Developer and, with the Rational Rose core, became the basis for Rational Rose RealTime. ROOM is "Real-Time Object Oriented Methodology", which also happened to be the title of the book Bran published with Garth Gullekson and Paul Ward. You can find the book here. Bran is currently employed by Rational (i.e., the fourth amigo) and still active in the UML specification world. BTW, a lot of the concept of ROOM that made their way in the Real-Time profile for the UML are making their way into UML 2.0.
Actually, this would not be acurate... ClearCase MultiSite is used between Rational's development sites. ClearQuest MultiSite is used to track defects and requirements. RequisitePro is used by many product managers. The Rational Unified Process is also in use. Purify and Quantify are used by the development teams, PureCoverage by the QE team. And XDE is also in use. How do I know? I work there...and use these tools almost every day.