On Mon, May 12, 2008 at 11:44 PM, Luis Sergio Oliveira <[EMAIL PROTECTED]> wrote: > > I have just checkedout. The code should receive a merge from the trunk, > since the profiles *.xmi files changed place recently (last week I think). > >
hi, do you know how do i do that in eclipse svn? > > Where are the automated tests? > easy answer: no automated tests yet hard answer: how do i test this??? > The XML processing is a bit better (see PluginProfileLoaderImpl.java) than > the one devised for ProfileConfigurations (see > ProfileConfigurationFilePersister.java), but, I would like to see it less > hard coded, meaning, we could define a XML schema, generate parsing code > from there and parse and validate the XML files containing the profile > definitions. > In a project I worked before, castor did a great work at this, enabling the > generation of the java code from a XML schema and validation of the XML > files against the schema. > hi, a part from the schema, how would this improve the current code? if i'm still going to look for the attribute "X" in the tag "Y" to fill the values in my objects what is the point? > The code has no documentation for many of the public methods, so, it won't > obey to the coding style guidelines. > ok. i'm going to comment my code > How are the FormatingStrategy and the DefaultTypeStrategy intended to be > implemented in the plugin variant of the profiles? > i really don't know, these things existed before my profile's works last year and i never saw their utility... > As a generic comment, I see the usage of a new XML file format as negative. > We already have the XMI format. UML is an extensible modeling language and > it allows tagged values to be associated to stereotypes. Thus, we may > associate a figure file to a specific stereotype using a tagged value in the > stereotype (see FigNodeStrategy). We may define values for three Tag > Definitions - DefaultAttributeType, DefaultParameterType and > DefaultReturnType - in the model that is the a profile, and, where the types > are defined, or, being the profile dependent on another profile where the > types are defined. > i agree with you, we could do this by defining a profile of our uml extension (in this case, just for documentation) and use the tagged values for defining the things in the xml and the constraints for critics, indeed, i think we would still need to define a xml and these things for lower level profiles (the ones providing java code, for example, since not everything can be specified in ocl) > How about critics, couldn't we also place them in a XMI file? If they are > stored as OCL we sure can. If they are saved as a scripting language, these > could be placed in a special tagged value, closely associated to some class > or DataType for which they are meaningful. yes... the idea is that the critics could be implemented in any language what i have implemented was what is currently supported: critics in Java. ocl and these fancy things is the next step ;) > > Defining FormatingStrategies could be done in the same way as critics, > i.e., by placing code in the XMI file which would have to follow a specific > convention... > > This would allow users of ArgoUML to use ArgoUML to extend ArgoUML by > defining profiles which would have the same functionality as the module (or > plugin) profiles and the module profile developers would use also ArgoUML > for the same task. Even the PluginProfileModule class could go away if we > follow the idea of /design by convention/ and specify that there is a > mechanism in the ArgoUML core that checks the modules to look for profiles > in a specific directory of the jar. i think this is already there. currently the user has two options: (1) a user defined profile and (2) a plugin defining a profile we can't leave out the option (2) because not all critics can be specified in ocl. in my opinion we should move more things to the xmi files, in this case the paths for the fignodes... the ocl critics will be there when we have ocl in argouml (and ocl refering to the metamodel, instead to the model! this is the most difficult part) maas > > With this approach we would be eating more of our own dog food, which is > always a good thing if we want to make sure that in the end our software > works. > -- - http://www.marcosaurelio.com *1984 +2057 "It is slightly better to be simple than correct." Timothy Finin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
