Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Rusty on February 14, 2002, 02:25:25 pm
-
When do you expect to offer UML 1.4 in EA? This is the only drawback I see with EA...and I love this tool after many years with Rose...EA wins Hands down in price and ease of use/functionality.
However Rose, System Architect, Describe, Together J, etc. are supporting UML 1.4 a tool that is a UML centric tool that is not up with the Industry current notational version is hard to 1. Use in my job as an Architect for fortune 50 companies and 2. Justify as a purchase within these corporations. Twice now I have proposed large purchases of EA for a large telecom giant and twice now the UML issue came up.
I realize that you are not a large corporate entity, however, just to let you know, my company spent well over a million dollars licensing Rose. EA was evaluated and liked by many programmers and also shot down by many because of the UML Notational Version.
I also run a company part time and we are useing EA despite the shortcomings, but it gets harder and harder to justify.
Regards,
Rusty
-
Hello,
We do have plans to support more and more of the features of UML 1.4. Specifically what parts of 1.4 would you like to see in EA, we have already included some of 1.4 in EA. We don't to say we support 1.4 until we are 100% compliant.
Paul Mathers
-
Rose for most of its life has not been fully compliant with the prevailing standard, and it has not done it any harm. It is true to say, though, that "no-one was ever fired for buying Rational" - not so for a little company's product. EA could do some significant damage if it were always fully compliant with the current standard. Very hard work but also, I suspect, very profitable.
Philip
-
I now run an architecture and strategy consultancy, previously I was Head of Architecture at 2 FTSE 100 companies. Both as a consultant and as an architecture manager, I have evaluated CASE tools.
Standards add value through consistency which aids learning and communication, and allows tools to communicate. EA has both these aspects covered.
In reality, beyond this the question of standards is (and should be) low on the list of priorities. The level of coverage in EA, Geoffrey's statement of intent and his record of delivery will satisfy most architecture managers.
EA is, in my judgement, significantly more productive than the other tools that I have used, its functionality is more accessible, and at about 5% of the price of the competition it is a no brainer to buy.
I guess the problems are likely to lie with some methods managers. Development and architecture managers should be swayed by the practical issues of delivering the right systems faster and to higher quality. This is where EA scores and is where an evaluation should focus.
-
Hi Alan
I agree it *should* be a no-brainer, but I doubt that it is. The bean counters would love it but they only get involved once the candidates have been decided by people who are quite often looking over their own shoulder. The unfortunate fact is that, like women in the workplace needing to be substantially better than their male counterparts to get promotion, a small company's products, if not unique, have to be very much better than those of the big boys. They need an edge, and in this case I think it would be being fully compliant, because nothing else is.
-
Alan, Philip,
Your comments are interesting. Let me restate that this tool is a consultants dream! It is part of my toolkit.
Did you know that the mapping of the human genome was accomplished using UML and the notation of choice, because no other notation could handle the complexity of the task?
But I have to disagree on some points that have been stated herein. Many architects are purests. We have to be! We are and should consider ourselves akin to our mechnical counterparts who have had thousands of years of experience to draw on; and who have a drafting standard notation. When you are designing a building you do not want your blueprints in many different notations and conflicting semantics. This is disasterous. Yet for years now our profession of software design has accepted just that.
Properly communicating complex relationships, structures, etc., in large and small corporations must be governed by standards must be top priority and key.
I cannot have a Group A producing diagrams in one version of UML and another group in a more recent version and arguing over semantics. I have been there myself. More recent versions clean up the shortcoming of previous versions just like software; and are therefore more desirable. Where a previous version of UML fell short the latest version should make up for it; and just recently I DID watch a manger get fired for purchasing alot of Rational product and not getting penetration because developers were opting for Together J and Describe due to simplicity and UML 1.4 compliance.
I agree that Rose itself has not been easy to use, 1.4 compliant and some other things. But I work closely with, and have friends at Rational. They are getting it and future versions will be easier to use and compliant. Rational ties tool, process, and notation together. If you examine the new approach to their Unified Process, you will see that Rose is getting overhauled in a big way. They have been getting bad press about Rose for years and they are finally stepping off their high horse and listening to developers. However this is not the point.
As a consultant and business owner who is an architect, I am mostly a fire fighter. I also mentor other architects and programmers. Since happening on EA I use it as my diagramming tool of choice. I absolutelty love it especially the price! I have licensed Describe (GD Pro), used Rose extensively, evaluated System Architect by Popkin and others. Again EA if it embraced (and I believe it must!) UML 1.4, to quote Philip, it "could do some significant damage if it were always fully compliant with the current standard."
Standards and methodologies are here to make software development faster, cheaper, and have a higher quality. For too long in this industry we have ignored good business software development practices and relied on PATCHES. I guarentee you that when I worked on life critical systems, we could not afford miscommunication in the form of a diagram or model. It is just good and professional to keep up or to make gains to get there...which EA has done. The most recent version of EA is much better that its previous versions.
Project success depends on first and foremont good communication, a standard of communication, effective easy to use tools, and a process to implement it all. Hybrid notation is not a good realization of communication.
The more compliant EA gets with 1.4 the more it will be adopted by larger organizations. Tools are part of the triangle of Process, Tools, and Notation.
On a lighter note, if this comes to pass and I have to purchase EA for 300-3000 dollars because it gets recognition...I'll kick myself!
Now to answer Paul (Sparx):
Mainly the iconization of notational stereotypes. I would like to se ethe ability to identify boundaries for use cases, and EA brough up to speed on Package, Subsystem, Model, Nested States, Classes, Composite Objects, Composition and Deployment . However, whatever you get it in EA and I'll use it to the degree I can. Thanks for responding!!!
Rusty
-
Hi people,
Just wanted to add a short note to reiterate that we are commited to making EA as compliant with the UML 1.4 standard as possible. A number of changes have already gone thru in the last build of EA that address some issues - and the next build adds even more. I have included a list of these at the bottom of this note if you are interested.
If anyone has 'high priority' item(s) or suggestions in this vein, perhaps they could email me ([email protected]) or post on this thread.
Thanks for all the support,
Geoff Sparks
Changes for Build 467 (to be released on 25/2/2002)
Interfaces now display with name in italics (abstract class)
Interface operations now display in italics (abstract operations)
Static attributes (Class feature) are now displayed underlined
Static operations (Class feature) are now displayed underlined
Nesting relationship added (to Logical and Rrelation toolbars)
Added custom drawing of <<model>> and <<subsystem>> stereotype icon as per UML specification
Abstract class names in package contents rendered in italics
Association end now displays Qualifier if set
Object instance now supports 'Role Played' as well as Name and classifier - <Name> / <Role> : <Class>
Added 'Iteration' element to Sequence diagram toolbar. Use to delimit iterative message passing
Inner classes linked with Nesting relationship instead of dependency
Changes for Build 465(current release as at 20/2/2002)
Abstract classes now denoted with italic name, rather than dotted border (UML 1.4 convention)
Display {ordered} constraint on association role end when IsOrdered checked
Abstract operations now displayed in italics (UML convention)
First association constraint now displayed as boolean expression on association link
Active Class (and Active Objects) now supported. Set Class to IsActive on Property/Advanced page. All instances displayed with thick border
Property dialog now renamed to Tagged Values dialog and moved to reference menu
Role changeability now displayed on association role end where applicabel .. supports {addOnly} and {frozen}
Added optional compartment for Responsibilities on some elements. Activate using the "Set Feature Visibility" menu option on element context menu
Added optional compartment for Constraints on some elements. Activate using the "Set Feature Visibility" menu option on element context menu
Added optional compartment for Tags on some elements. Activate using the "Set Feature Visibility" menu option on element context menu
Attribute stereotypes now display in class element
-
To be fully compliant with UML 1.4 (which I definitely think you should strive for), one issue you might still consider is removing the attributes from interfaces.
I quote from chapter 3.29.1 on page 3.51 in the UML 1.4 spec:
Interfaces do not have implementation. They lack attributes, states, or associations; they only have operations. [...] An interface is formally equivalent to an abstract class with no attributes and no methods and only abstract operations, [...]
If you think you need an interface with attributes then you are wrong. What you need is an abstract class.
You should remove this support, maybe by only offering the attributes to already existing interfaces, but it should not be possible to create new interfaces containing attributes.
-
Maybe trying to add an attribute should bring up a dialogue bpx indicating non-conformity in the same way as some of the links do when inserted incorrectly.
Ronnie
-
Hi,
Maybe I'm missing something here but to me there is a two-way street when it comes to "standards" (which I think are more like guidelines). For example, just because there are attributes "available" for interfaces doesn't MEAN that the user has to use them. This is part of that two-way street.
I can't tell you how many times a tool that was "compliant" with a standard actually hindered development because of some unique situation being experienced. Furthermore, I can't tell you how many times "standards" have lagged the needs of the community. Again, these are just "opinions" and whether EA is 1.4 compliant or not, users can circumvent any tool to achieve a purpose, thereby using the "standard" more like a guideline than a rule. What I love about EA is that I'm not hindered by strict interpretations on such rules and am left to use the tool that best suits the needs (which is the way it should be) rather than suiting the needs to fit the tool (which is the way it typically is).
Steve
-
Steve,
Without sounding like a hypocrite I agree but ONLY within this context. Tools should be standards compliant but allow for flexibility that is encountered with the unknown.
Again, when I started this thread (which is a hot thread by the number of views it has recorded so far) the objective was UML 1.4 compliance.
Communication cannot be left open to interpretation. Engineers who construct bridges are held accountable to following engineering standards. Building Architects and Engineers are held to standards. Open interpretation of notation is not implicit but explicit and it must be.
Case in point. Software constructed for an X-ray machine for calibration required the machine descend to the bed level and ascend a specified height for calibration. Great, the program was constructed but a fatal flaw was missed. The program faild to account for an operator's errant command with someone lying on the bed.
What were the requirements for the software? What was the notation used to model the software? Did the model convey an accounting for this condition? The issue when investigated boiled down to the improper specifications. But Why? Was it lack of communication? Was is misinterpretation? Specifications exist to enable clear and concise communication of "something." POOR EXECUTION OF STANDARDS AND SPECIFICATIONS HINDER. Not the standard or specification itself.
However, had the sensor been programmed to expect encountering the bed at a specific distance and if not then abort, the patient might have lived when the sensor detected a solid object at distance X rather than distance Y.
"But I write business software!" You say.
Again, I come back to communication. One language. So far I don't know of anyone that has sued Microsoft for its "bloatware", or "rebootware" or for hiding space hogging pulsating polygons renderings via Easter Egg in Excel. As Software Engineers and Architects we have been immune to the liability our counterparts at the other end of the spectrum have. A bridge fails, the Engineer's head is on the block.
A building collapses, the Engineers's head is on the block. It seems silly to even ponder the though of getting sued over a that server crashes and causes a load balanced cascaded failure effect because of a bad software design which was poorly communicated via model at design and specification, which subsequently causes a company to loose millions.
Only because it has not happened...yet.
So what 'am I rambling on about? The tool should be UML 1.4 compliant but allow the Engineer or Architect enough latitude to violate the rules when professional experience and judgement dictate. So in this I see your point.
But freedom does not negate the necessity of, or compliance with standards. By definition a specification is "a detailed, exact statement of particulars." The UML is a specification and not open to ones own interpretation.
Iron sharpens Iron! These comments are valuable and insightful.
Steve, thanks for responding! Hopefully I have not offended you or anyone else, as it is not my intent.
Rusty
-
Rusty
I agree in principle with what you say.
However, I think there are more important battles to fight than standards especially in large organisations. For example, getting people to talk one another is more important than using tools, using any tool is more important than using a specific tool, productivity and quality are more improtant than standards. All these are interrelated but we need get the priorities right and deliver better long term value to the organisations that we work for. While we discuss standards, someone has just won the business argument with Powerpoint!
Regarding the product, working towards the standards as they emerge is good enough for me. But, I want speed and flexibility first so that I can get on with the job rather than fight the tool. The story that EA has to tell is much bigger and better than the tired old standards arguments.
I also want EA to sell well so that the product can continue to grow. On this point, standards may be important. Maybe, others with experience of corporate procurement could give their twopenn'eth.
-
Rusty,
First, no offense taking so don't sweat it. Sometimes these philosophical discussions are good to air out threads of thought.
Second, I'm not sure using Engineers building bridges is a good comparison. Bridge building does really have legacy issues to deal with: you have point a, you have point b, you have a gap between, now connect the dots. If bridge building consisted of filling the gap between point A and point B AND using a piece of the OLD bridge then perhaps. The beauty of bridge building is that if a bridge is unstable, those engineers tear it all down and start from scratch. Try telling a supervisor of some legacy Natural or Cobol stuff and say, "It's not all that stable and we have to scrap it and start from scratch." Instead, we are typically told to kludge in stuff which causes our design and our toolset to never fit 100% (IMO).
As far as the XRay machine goes, it sounds more like a Business Analyst was not involved in the process to catch the construct in the functional requirements phase. That really doesn't have anything to do with UML 1.4; rather, poor execution on the part of the program manager.
This leads to the issue of poor execution of standards. Again, people are involved and no matter the "standard", we don't always stick to them. I can't tell you how many times, myself included, thought of a "cute" shortcut to the system to save whatever only to have it bite me in the end. That again isn't the fault of any one specific tool and whether a tool is "standard compliant" or not... it's a case of people by-passing it.
Let me offer this example of "standards" which causes problems. I worked on a product that was an object-oriented database and the buzz was to be OMG compliant. The group formulating the standard couldn't agree on the proper implementation and interpretation of class and instance methods. We had our philosophy and our customers needed them. So, we implemented what we thought they should be and our customer base was happy regardless of the product not being 100% compliant. We would have been screwed had we said "we have to wait to see what the standard is before we can act."
So what am I saying? Well, for one thing, people violate standards all the time for whatever reasons. Tools can never fit every situation, every standard, every convention... to me, it is an art and not a science, or at best, the artistic endeavor to being scientific. Finally, standards often lag the needs of the community and tools need to deliever the needs of the customers and not necessairly the needs of the standard. Yes, standards are a good thing in principle and often are subserviant (spelling) to a better business process within the development environment... a process that is adhered to within the all aspects of application development.
<whew> There's .02 worth... <LOL>
Thanks for the discussion... enjoying it!
Steve
-
Steve, Alan:
I think what I was attempting to say is that it was discovered that communications was the problem with the X-ray machine.
Now in the business software space, I come out of the life critical software sector. Aerospace software. Our code fails, people die. We adhered to standards religiously and did not diviate unless approved; which usually meant a rewrite of our specifications. We communicated in one language, were all on the same page with one well understood modeling language---and people lived. We found better ways and faster ways of doing our job, but did not implement them until they became approved.
The reason everyone thinks standards are good in principle (akin to saying in reality they do not work) is because we work in an industry that is focused on a fast buck, not software quality.
"Get it out there, we'll release patches later." However, times are changing.
The reason I used the bridge analogy is that as a consultant and FTE I have made my living TEARING down legacy systems and rebuilding them...for extremely large and visible companies.
As a Software Engineering Manager at one point in my life, I imposed strict adherance to standards across my team. We adopted and followed the Unified Process, used modeling tools that were compliant with the latest OMG specification. One language of communication. We were so successful that the corporation made the group the "standard" (pardon the pun) by which other software shops internally were measured.
However...we did diviate from our path when we had no other choice, but always came back to the main line as quick as possible.
Notation, modeling is communication. Had we had tools that produced models in UML 1.1, 1.2, 1.3, etc., we would not have been as successful.
I have come in and stuck my finger in the hole of bleeding systems where standards were dropped for business goals. Look at the Dot Gones? Most did not employ good standards or even attempt to follow an OO much less iterative process of development. I was there.
I guess if you let people debate standards none will adopt them because each person is thinking about how it impacts them. This is why one person should decide with input from many.
The point is a tool that supports UML 1.4 in its entirety so that communication of complex systems is captured correctly, and understood correctly by going to 1 specification and not 3.
Whew...
Rusty :)
-
Rusty,
I had to chuckle with one of your lines when I thought about it some:
"I guess if you let people debate standards none will adopt them because each person is thinking about how it impacts them. This is why one person should decide with input from many."
This is the Catch-22 situation... I _DON'T_ want one person deciding... we live with that situation every day at the moment.... Ellison, Gates, et cetera. The REAL trouble with committees is either the hidden agenda factor amongst the delegates OR, in the case with some IEEE stuff I've worked on, business interests lag down the development of real standards.
What I like to do is look at an adopted standard, look at my business practice standards, look at the tools that are of "best practice" (oh my gawd... I sound SO corporate with that last phrase), and adopt a strategy from there.
Steve
-
Not wishing to jump in for the sake of it, it seems to me that we are to a large extent violently agreeing.
Let's not forget that, not so long ago, everyone thought that 1.3 was the biz and berated those still using 1.2!
As the software industry becomes more mature and adopts 'traditional' engineering principles our standards will continue to evolve.
I think that Geoff and his team have got it right - adopt those bits of new standards as soon as possible where practical, and the remainder in due course. Better than sticking with 1.3 until 1.4 compliance arrives all in one go at some point in the future.
There is however another issue, whereby the rapid pace of change within EA makes it hard for large teams to be sure that they are all working on the same version. That subject may well be worth starting a separate discussion thread for.......
-
James,
Agreed on all your points.
With regards to the pace of EA changes, are you talking about making sure everyone has the same EA executables or EAP files?
In either case, I'm using CVS to assist in this and it seems to work out well.
Steve
-
Keeping both EAP files and executables in line is basic configuration management. The EAP files are development artefacts just as code is and should be under CM. The operational environment, eg the development toolset, should be managed too using standard deployment tools. There is an art to getting the balance between the level of control needed to ensure that the toolset is stable and giving developers the freedom to develop productively.
-
James,
"Better than sticking with 1.3 until 1.4 compliance arrives all in one go at some point in the future."
Agreed.
"Let's not forget that, not so long ago, everyone thought that 1.3 was the biz and berated those still using 1.2!"
Agreed. But this is NOT what I have been stating herein. Notational communication should be either alll 1.2, or all 1.3, or all 1.4 not a blending of some of this and some of that.
But as much as I would like to adopt a hard-line on this, for small software shops, this is an unrealistic approach. The object is satisfaction of your user base. As an Architect if I need to...say, use the web iconizations to stereotype my notation, but and have to wait for a specific totally compliant future build of a EA to do this, it does not help me in the present tense...which means I go find something that will. Like Steve has stated earlier, it is a Catch-22.
"As the software industry becomes more mature and adopts 'traditional' engineering principles our standards will continue to evolve."
Agreed.
"I think that Geoff and his team have got it right - adopt those bits of new standards as soon as possible where practical, and the remainder in due course."
Disagree conceptually but Agree in reality. Citing my explanation above.
"Better than sticking with 1.3 until 1.4 compliance arrives all in one go at some point in the future."
Agreed, but you contradict yourself here.
"There is however another issue, whereby the rapid pace of change within EA makes it hard for large teams to be sure that they are all working on the same version. That subject may well be worth starting a separate discussion thread for......"
Agreed.
What a discussion this has turned into! Gets the mental juices flowing!
Rusty.
-
Rusty,
Help me understand something here.... when I read...
"Notational communication should be either alll 1.2, or all 1.3,
or all 1.4 not a blending of some of this and some of that."
That might imply that 1.4 may drop some convention in 1.3 as opposed to merely adding on new notations. Is 1.4 dropping any 1.2 or 1.3 agreed-on notation? If not, then having 1.3 and adding 1.4 stuff as it becomes applicable to EA still would make it, in my mind, 1.4 and not a "blend". Additionally, if 1.4 is not dropping 1.3 standards, then you are merely waiting for those extensions specific to the new 1.4 standards which, as I understand, will evolve over time in the product. Or am I missing something here?
"What a discussion this has turned into! Gets the mental juices flowing! "
Sure does!
Steve
-
To add my €0.02, Java interfaces CAN have constants, which would be represented as static attributes in EA, so I for one definitely recommend we keep this in, even if there's no actual way of representing this in UML 1.4 if you were to be strict, it would seem.
http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#35470
-
Steve,
Sorry for the delay...innundated with changing requirements suddenly. But to answer your question...yes. 1.4 has "refined" some elements which actually change the semantics of the notation.
This has been brough up at least once that I know of.
Rusty
-
Rusty,
Thanks for the reply. Hope you are well.
Then this re-affirms my point about "changing standards" and the tools that reflect them. A standard, like a language, that keeps shifting it's own definition plays havoc on the principle of standardizing on a standard. It's kind of like skeet/trap shooting in a hurricane: nice idea to have the gun, the bullets, the clay bird... but try and hit it.
Steve
-
Steve,
I agree kinda. But don't you have to standardize on something? You standardize but enable enough flexibility to deviate only when necessary.
It is like the English language. We have a baseline for the language. New words and meanings are added as the human race matures. Old words take on new meanings as well. The word Gay in 1950s meant happy. Today however it means something totally different. But the way it is spelled and pronounced is the same. We also have some spanish, latin, french, and other languages mized in with the etomology of english but that does not mean we begin integrating with the english language pure spanish per se. We do not want Spanglish but English.
Same with UML. UML is a visual communications language and therefore will mature over time. Adopt 1.1, when 1.2 comes out adopt it in full..1.3, 1.4 etc. While there may be some changes, in the meanings of the notation, the notation stays the same. It is the capturing of the change in the meaning that is paramount.
Rusty
-
Hi guys,
Just thought I'd bring up something thats probably relevant to a few of the comments put forward here.
It has been pointed out, quite correctly, that UML 1.4 does not support attributes for Interfaces.
An attempt to enforce this UML restriction on Java users has caused some angry responses - so at the moment, in violation of the UML 1.4 syntax, Interfaces are allowed to have attributes (albeit static ones) in EA.
Interestingly, the XMI DTD version 1.1, produced from the UML metamodel permits Interfaces to have attributes thru the UML:Classifier.feature element. So when EA exports XMI for Interfaces with Attributes, these are valid according to the DTD.
But even -more- interesting is that the current draft proposal for UML 2.0 allows Interfaces to have attributes - bringing the UML definition of an interface more into line with things like Corba and Java.
So what is the consensus on this?
1. Syntactically (for UML 1.4) it is not correct.
2. Pragmatically, it is done all the time and is 'essential' in some peoples minds
3. At the XMI level (model interchange) it is actually 'legal'
4. Conceptually it appears 'correct' as is evidenced by the revision in the forthcoming UML 2.0 specification.
Hope this is of interest,
Geoff Sparks
-
Rusty,
Good question! Yes, you have to standardize to a point. Kind of reminds me a joke the R&D guy at CA once said in conference, "Guys, Shift Happens!". I have settled on that notion and that we here have standardized on those things that make sense to what we are trying to accomplish. This allows us to say what are our standards and use new ones that are applicable or ignore those that aren't. It also frees us from being so bogged down to such a degree where it feels that the tail is wagging the dog... i.e. the Standard is dictating the needs of the business. We have a small group that meets and if something new and is applicable, we implement it in our standards. If not or if there is no standard yet out there for what we are doing, we develop our own standard and publish it. <lol> I guess our standard is a aggregated sub-class of lots of "standards". :-)
Taking this further, Geoff points out a restriction (to some) about UML 1.4. Now, if we here choose that it IS important to have attributes available in interfaces and while that is NOT part of the "standard" but it IS the standard of the business, then I would want a tool that supports MY standard and not the other way around. This is where we, in IT, get so screwed up (IMHO) and where we get a bad wrap... it's the business need (to me) and not the IT need. This is why I want a more flexible tool than one that is so regidly set on a standard that has no monetary investment in our development efforts.
Great discussion by the way!
Steve
-
Steve, Geoff:
Absolutely! This is where the "flexible" part comes in. I agree and have with this aspect all along.
Now that we are all in agreement let me pose this question...is this the death of the UML 1.4 thread?
<LOL>
:)
Rusty
-
Sorry couldn't resist... may the thread die after this message :)
Steve,
I agree kinda. But don't you have to standardize on something? You standardize but enable enough flexibility to deviate only when necessary.
It is like the English language. We have a baseline for the language. New words and meanings are added as the human race matures. Old words take on new meanings as well. The word Gay in 1950s meant happy. Today however it means something totally different. But the way it is spelled and pronounced is the same. We also have some spanish, latin, french, and other languages mized in with the etomology of english but that does not mean we begin integrating with the english language pure spanish per se. We do not want Spanglish but English.
Same with UML. UML is a visual communications language and therefore will mature over time. Adopt 1.1, when 1.2 comes out adopt it in full..1.3, 1.4 etc. While there may be some changes, in the meanings of the notation, the notation stays the same. It is the capturing of the change in the meaning that is paramount.
Rusty
Welll... come on though, English language is defined by its usage, not some arbitrary standard, albeit over a time scale that is a lot slower than other standards (but then, UML would change a lot more slowly if 2 billion people in the world used it every waking moment of their lives :) Even grammar changes. The nounizing of verbs and verbizing of nouns are much more common in recent years to what it was. 'Yous' as plural for second person plural is increasingly common across the world. New words and vocabulary evolve even more rapidly with the internet. In other words, people run with it. Even 5 years ago, would you have had any idea what i meant by 'blog', 'spam', 'to text someone', etc etc sure I think you get my point.
Speaking of Spanglish, it's what's becoming increasingly common in Spanish. For instance there are two words for 'link' in Spanish: 'enlace' or 'vínculo' but here in Spain people just use 'link' as they do 'training', 'marketing', 'scope' etc. (A funny side is that people pronounce foreign brand names with a literal Spanish accent... like 'Oracle' for instance is pronounced 'orAH-kleh' and there was a time when I had absolutely -no- idea what they were saying until they wrote it down :)
New words are more often than not directly transplanted into other languages. It happened in English too, there are bundles of foreign words and concepts.
So I'm not so sure it's as clear-cut as that. I think it's ok to use these tools to communicate the intent of the design. You're not going to do sequence diagrams for every flow, only for core use cases for analysis (with Together actually, I've used the sequence diagram from code option to understand the method call stack, very powerful analysis tool).
My €0.02
-
Rusty,
Since we are in agreement, maybe this thread is finally at its conclusion... it has the dreaded "comparing to Together" impression now implanted which is a sure sign that it has concluded <lol>.
Cheers,
Steve