News: Borland Announces Role-Specific Together Modeling Solutions
Borland today announced the release of three role-specific Together modeling solutions, which will help form the visual design component of the company's Software Delivery Optimization (SDO) vision.
- Posted by: Jake Ginsky
- Posted on: October 25 2004 16:59 EDT
The release of Borland Together Designer 2005, Borland Together Developer 2005 and Borland Together Architect 2005 will introduce a collaborative product set, optimized to help architects, designers and developers work seamlessly across teams. The products will begin delivering elements of Borland's SDO vision, which aligns teams, technology and processes to maximize the business value of software. (The first iteration of Borland's SDO platform, "Themis," expected to be available in the first half of 2005.)
Borland Extends Benefits of Modeling Across Software Development Teams
- Together tools have been nice but... by Steve Benigan on October 26 2004 12:28 EDT
- Too expensive and too complicated by Michael Mattox on October 28 2004 04:08 EDT
Together tools have always been good but too cost prohibitive for most places... or rather too risky to buy into because they don't contain the "R" word.
Together Eclipse Edition is lacking in many respects leaving Architect as the only viable option... but it's discouraging that it isn't based on something like Netbeans, Eclipse or even IDEA.
I can't help but think this announcement is in reaction to IBM's upcoming toolset based on Eclipse. The press release doesn't contain any substance other than their cry, "We're not quite dead yet"... which is good for users of Together who are still wondering what Borland is doing with there wonderful tool.
I can't help but think this announcement is in reaction to IBM's upcoming toolset based on Eclipse.
JSR-198 better get its sh!t together soon, or industry will settle on Eclipse as the de facto standard for dev tools.
I doubt JCP 198 will be implemented. The equivalent could appear in the form of Eclipse domination.... meaning if Eclipse becomes pervasive, the goals of JCP 198 will have been achieved ;0)
I remember when TogetherJ was owned by Together. There was one version and the different "roles" were in the tool itself, not separate products. Why complicate things?
Also, Borland continues the policy of releasing new versions just to milk the upgrade cow. I'm suprised there is still any milk left.
We purchased 3 copies of Together complete with Premium support shortly after Borland took them over. What we got for our premium support was a different splash screen and a new license manager. The support even ran out just in time for Borland's apologetic offer to cross grade TCC licences.
UML from code is a unique and wonderful idea, possibly on a par with the usefulness of automated refactoring tools. But the money spent and the ensuing dry spell for features has left a bitter taste...
Well, if the goal of UML is to impress naive customers, non-coding 'architects' and other managerial camaraderia, then yes, it's perfect idea. Diagrams with hundreds of classes that no one could understand or even read look very cool. Ever seen/understood sequence diagrams that Together creates for decent 40-line method?
OTOH, if you want to use UML to communicate design ideas, only hand-drawn UML will do - where a human being decided what is relevant and to be shown on the diagram, and what has to be omitted. Along with a lot of plain English narrative.
And by the way, can anyone honestly confess that UML <-> code reverse engineering really (==not for toy projects) works? Does any senior developer use that 'implement design pattern XYZ' thing? Is there any value of expressing 1:N relationship between two classes as List or Map attribute?
Diagrams with hundreds of classes that no one could understand or even read look very cool.
Together could easily fix it by offering a identifier/class/package filter. The user could quickly pick a subset of details to hide.
Ever seen/understood sequence diagrams that Together creates for decent 40-line method?
Again, filtering would easily fix this problem. It would be nice if Together could breakpoint and single-step sequence diagrams. Or imagine instance diagrams of the heap's graph. Together's greatest deficiency is its lack of an executable model.
Does any senior developer use that 'implement design pattern XYZ' thing?
Is there any value of expressing 1:N relationship between two classes as List or Map attribute?
Yes, having relationships codified as properties can be useful. It speeds development and increases readability. That is why EJB exposes relations as properties.