UML 1.4

[Rusty]

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  

[sparks]

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

[Philip_Avery]

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

[Alan Inglis]

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.

[Philip_Avery]

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.

[Rusty]

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

[gsparks]

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

[TorbenKoch]

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.

[ronnie]

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

[Steve_Straley]

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

[Rusty]

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

[Alan Inglis]

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.

[Steve_Straley]

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

[Rusty]

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  

[Steve_Straley]

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