Hello Mark!
There are a lot of things left to improve on ArgoUML. Please work with this,
either by implementing this or by discussing the priorities so that someone
else is convinced to do it. The priorities are ultimately set by the
developer that does the implementation.
/Linus
Den fredagen den 2:e september 2011 skrev Mark Fortner:
> 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]<javascript:_e({}, 'cvml', '[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=2835483
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]]
