Hi Mark and Tom, the current Java profile that is included in the Java module only contains a selection of classes/interfaces from the JRE/SDK. To make it complete, one could reverse engineer either the .jars of the JRE as Tom suggested, or the sources with Java Source file import. This would indeed result in a large model.
The intention behind the current Java profile (made by me btw) was different. It is created to make sure that for Java reverse engineering the resulting user model gets not too large by creating all the referenced Java classifiers. For this, a set of the most commonly used classes/interfaces without any members was appropriate. However, it is not complete (and needn't be), and entending it for other purposes is an option. The (architectural) stereotypes that you suggested would be really needed, but should probably not be part of the Java profile. MVC pattern, distributed web applications or other concepts are not Java specific. I'd suggest a (small) MVC profile, or a GOF pattern profile, or a JEE profile separate from the Java profile. (Currently the best way to provide these profiles are as ArgoUML modules.) Regards, Thomas -------- Original-Nachricht -------- > Datum: Wed, 27 Apr 2011 00:54:01 -0400 > Von: Tom Morris <[email protected]> > An: [email protected] > Betreff: Re: [argouml-users] ArgoUML Java Profile > On Tue, Apr 26, 2011 at 8:45 PM, Mark Fortner <[email protected]> wrote: > > Recently I needed to create a new class diagram and I thought that the > Java > > Profile would contain all classes in the JDK, and all attributes and > methods > > for those classes. Since this doesn't seem to be the case, I was > wondering > > what the intent was behind the Java profile? I could see having a JEE > > profile with stereotypes for things like "Controller", and "Service", or > > "Model", "View", "Controller" but I don't see anything like that in this > > profile either. > > I think the main intent of the Java profile is, first, to split out > things which are Java specific, but had historically been included in > the core of ArgoUML. This was inappropriate, but understandable given > that the implementation language as well as target language for many > of the original developers was Java. Second, it's intended to support > the requirements of Java reverse engineering and code generation round > trip. > > Historically, the recommended way to get what you're looking for was > to apply the Java classfile reverse engineering module to the JRE lib > of the desired version. I haven't tried it in a while, so I wouldn't > guarantee that it still works, but that would be my first suggestion. > Choosing appropriate options for modeling fidelity to keep the > resulting model from being overwhelming is important for this > exercise. > > If you generate something useful, the ArgoUML team might want to host > it someplace where others would be able to reuse it. > > Tom > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=449&dsMessageId=2724489 > > To unsubscribe from this discussion, e-mail: > [[email protected]]. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=449&dsMessageId=2724568 To unsubscribe from this discussion, e-mail: [[email protected]].
