Hi Linus,
Java reveng support in general needs to be updated. It doesn't support most
of the syntactic sugar added in Java 5 (generics, annotations, enums, etc).
And since Java 5 was EOL'd in Sept 2004, we're currently woefully behind.
Inner class support is also missing from reveng and is not supported in the
class diagram (I recently added an issue for that).
I would imagine that once these issues are addressed, then both approaches
would be able to make use of them.
<slightly off topic rant>
I don't necessarily believe that all documentation should be visible in the
diagrams. Although, it might be nice to be able to preview documentation, in
the same way that you can preview code generation. I think historically the
reason that most of these types of issues have had little attention is that
the majority of ArgoUML's users probably just use it to create class
diagrams. There are a couple of different philosophies behind using UML:
- Use it just for class diagrams. These types of users typically export
diagram images, and put those images into Word, PowerPoint or Wikis. They
don't generate code from their models, and thus don't bother to document
classes, interfaces, methods and attributes. Their main concern is creating
an image that communicates their design.
- Use the activity & state diagrams. These are primarily business
analysts who are trying to understand a business process and ultimately what
they want to generate is a document that shows where software is needed to
support that business process.
- UML power users (I tend to lump myself into this category, although I'm
probably not the best example). My feeling is that if you're taking the
time to create a model you should be able to generate multiple artifacts
from it. Use cases should be documented with paragraphs of text that
actually describe the use case, along the lines of Alistair Cockburn's
definition of a use case. Test cases that prove the use cases, (basically
use cases with a <<Test Case>> stereotype, should be useable as the basis
for a test plan and you should be able to generate a traceability matrix. It
would also be nice to be able to mark use cases as <<Tasks>> and have those
tasks generate JIRA/bugzilla issues -- similar to what you get in Eclipse
Mylyn. If I create a deployment diagram, I should be able to generate
META-INF/services files, web.xml files (for web apps), Maven POM files, etc.
When I generate code I should get something that accurately reflects the
language I'm working in. To me the model is the most valuable part of the
exercise, and I should be able to generate enough artifacts to jump start my
development process. After getting design approval I should be able to
generate code, and unit tests and start implementing the design immediately.
I think that in most cases, developers have been using ArgoUML to support
the first bullet point. Ultimately, I'd like to be able to show people in
regulated industries (like the pharmaceutical industry, biotechs, defense,
telecoms, etc) that they can produce a lot of the artifacts that the
government requires of them and accelerate their software development
efforts at the same time. In order to do that, accurate reveng and code and
artifact generation are key pieces of that vision.
</slightly off topic rant>
Regards,
Mark
On Thu, Sep 1, 2011 at 10:11 PM, Linus Tolke Tigris <[email protected]>wrote:
> Hello Mark and Bob and all...
>
> This is a very interesting discussion on the distinction between Notation
> and Code Generation/Reverse Engineering.
>
> From my experimenting with 0.32.1, it seems that the code generation for
> Java does not include documentation of parameters to operations in the
> source tab or in the generated source so this is one of the first things
> that should be added to achieve this. For SQL and C++ it is not included
> either but for PHP4, PHP5, and CSharp it is included.
>
> I also can't get updating from edits in the diagrams to work for the Java
> Notation. It works for the UML Notation.
>
> If we implement the on-diagram editing that Bob is advocating, that would
> mean to improve the Notation to work better with java, allowing also
> documentation of attributes, operations and parameters. The question is how
> and if documentation shall appear on the diagram. I assume some hovering/F2
> solution will be necessary not to fill the diagram.
>
> Implementing the possibility to edit and then reverse engineer directly
> from the source tab is also an interesting option with some challenges that
> has been identified.
>
> The biggest challenge is probably to get the two approaches to use the same
> implementation so that we don't have to implement this parsing twice for
> every language. I am not sure how far the work with Notation by Michiel has
> come in this area.
>
> /Linus
>
>
>
> Den torsdagen den 1:e september 2011 skrev Mark Fortner:
>
> Hi Bob,
>> How would this work if you were editing the code in an IDE and re-imported
>> it into your project? Wouldn't that still break references in your model?
>> Wouldn't you expect it to break those references?
>> I guess in that case when you generated the code you would end up with
>> code that wouldn't compile but could be easily fixed. One possible solution
>> to that would be to support simple refactoring, like method renaming and
>> method signature changes, but that would probably take longer to implement.
>>
>> My thought is that something like this would be small enough in scope that
>> someone could implement it in a weekend and contribute something that makes
>> modeling easier. At a first pass though, it would be useful simply to
>> support green field modeling with this.
>>
>> Mark
>>
>> On Thu, Sep 1, 2011 at 9:31 AM, Bob Tarling <[email protected]>wrote:
>>
>>> On 1 September 2011 17:11, Mark Fortner <[email protected]> wrote:
>>> > Hi Bob,
>>> > My thought is that the "instant reveng" function would basically
>>> replace the
>>> > model for the class that you're currently editing, rather than trying
>>> to
>>> > incrementally update individual operations.
>>>
>>> But what about any other model elements that refer to the existing
>>> oprerations?
>>>
>>> If some of those operations you "replace" but are really the same then
>>> you lose those references.
>>>
>>> Bob
>>>
>>> ------------------------------------------------------
>>>
>>> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2833988
>>>
>>> To unsubscribe from this discussion, e-mail: [
>>> [email protected]].
>>> To be allowed to post to the list contact the mailing list moderator,
>>> email: [[email protected]]
>>>
>>
>>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2834648
To unsubscribe from this discussion, e-mail:
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email:
[[email protected]]
