Note that the developers of AndroMDA use MagicDraw and take advantage of Magic Draw's support for concurrent model development. This allows AndroMDA developers to concurrently develop AndroMDA cartridges and their corresponding UML models, which are collectively stored in the AndroMDA profile.
Any ArgoUML developers who have used AndroMDA with ArgoUML are aware of this. That is why there ArgoUML provides of merged version of the AndroMDA profile for ArgoUML users. It is very nice that ArgoUML has greatly enhanced its support of the creation of UML profiles in 0.22 (direct manipulation of datatypes, stereotypes, and enumerations in class diagrams). However, I doubt that AndroMDA developers will consider substituting ArgoUML for Magic Draw without support for concurrent model development. This is also an issue for people like me who want to create their own AndroMDA cartridges. It would be very nice to be able to create my own cartridge model in ArgoUML, extending the AndroMDA meta model, and maintain it in a separate sub model. I think it would be a great benefit to ArgoUML project to have AndroMDA developers using ArgoUML as their primary modeling tool. I think it would be very useful to hear from AndroMDA developers what they would require in ArgoUML, in order to use it as their primary modeling tool. cheers, roy On Mon, 2006-06-26 at 13:41 -0400, Roy Feldman wrote: > Hi Graham, > > On Mon, 2006-06-26 at 06:36 +0100, Graham Compton wrote: > > Roy, > > > > Thanks for voting for the issue. > > Thanks for raising the issue. > > > > > 2) No support for concurrent development of changes to relationships > > > between sub-models. In other words, in order to modify or delete an > > > existing relationship between elements in two models, it cannot be done > > > concurrently. Users would have to halt concurrent development to make > > > such changes. However, it would be nice if you could add relationships > > > and modify new relationships between sub-models while developing > > > concurrently. > > > > As I understand it, such relationships would be owned by one sub-package or > > another (or the main model itself). The definition would not be shared, and > > therefore, only those working on the owning package could make the change. > > > > Would this solve the constraint that you describe? > > What you say is true, but I think you are be making implicit assumptions > about how ArgoUML would support Concurrent Model Development. > Specifically, I think you are implying that a sub-model mechanism would > distinguish between read-only and read-write sub-models. > > I think this is direction to move towards, but it would be a big > improvement if the ArgoUML initially didn't make a distinction read and > read-write sub-models and instead put the burden on the user. > > Without tool support for distinguishing read and read-write models, you > would need to establish a policy that is easy to for modelers to > follow. > > You are obviously correct that relationships would always belong in a > sub-model or the main-model. However, I am concerned about the practical > issue that modelers often aren't aware of the location of a pre-existing > relationship, including myself. ;-) > > The restriction I am suggesting is to help avoid merge problems because > of user error, not because of a limitation in the model implementation. > > With tool support of the distinction between read and read-write models, > ArgoUML would not let you create a relationship in a read-only model, so > there would be no need for the limitation I suggested. > > > cheers, > > roy > > > > > Cheers, > > > > -----Original Message----- > > From: Roy Feldman [mailto:[EMAIL PROTECTED] > > Sent: 26 June 2006 04:20 > > To: ArgoUML > > Cc: OSF > > Subject: [Fwd: RE: [argouml-dev] Re: [argouml-users] UML model and CVS.] > > > > > > On Fri, 2006-06-23 at 21:01 +0100, Graham Compton wrote: > > > People, will have different priorities and requirements in this area. > > > I’m an architect and in my line of work, solving the large-model > > > problem is essential for me to make serious use of tool in my work. > > > Hence the use of my maximum allocation of 10 votes on issue > > > http://argouml.tigris.org/issues/show_bug.cgi?id=3497 > > > > > > > > > > > > Unfortunately, I’m the only one to vote for it so far :o( > > > > You are no longer alone. I have just used my 10 votes for this issue. > > > > FWIW, I was just about to raise this issue when I happily saw it already was > > a discussion topic. I am leading a small open source project where we > > are using ArgoUML and AndromMDA. Although our project team is currently > > small, we are > > already working with very large models. I believe the lack of support for > > concurrent development > > of models is the biggest obstacle keeping ArgoUML from being widely adopted > > for > > large-scale development projects. > > > > > > Although having simultaneous access to a model would be nice, I don't think > > it will solve > > the problem of developing and maintaining large models. > > > > IMHO, the solution will require some form of concurrent, but > > asynchronous, modification of a model. Similar to what some commercial > > tools do to solve this problem, I would like to see the ability in > > ArgoUML to partition a model into separate sub-models. For me, the ideal > > scenario would be to allow multiple sub-models form a single model, where > > the sub-models > > could be stored in a version control system. > > > > To simplify the development of such a feature, I think that it > > would be reasonable to impose certain limitations on the feature to > > simplify model merging. These limitations need not be enforced by > > ArgoUML, but manually by the users. > > > > Propose concurrent development limitations: > > > > 1) Model merging would handle only one version of a given sub-model. > > In other words, no support for concurrent development of the same > > sub-model. Users would have to ensure that only one version of a module > > is modified. My experience is that in practice, work on large models is > > normally managed is such a fashion with commercial tools such as > > Rational Rose and Magic Draw. You don't want multiple people modifying > > logical parts of the same model. In this matter, concurrent development > > of models is different then concurrent development of software. > > > > 2) No support for concurrent development of changes to relationships > > between sub-models. In other words, in order to modify or delete an > > existing relationship between elements in two models, it cannot be done > > concurrently. Users would have to halt concurrent development to make > > such changes. However, it would be nice if you could add relationships > > and modify new relationships between sub-models while developing > > concurrently. > > > > cheers, > > > > roy > > > > > > > > > > > > > > > > Is there an equivalent issue for the concurrent feature request and > > > how many votes does it have? > > > > > > > > > > > > If developers and users used their votes on either issue then we may > > > be able to judge the relative priorities across the user base. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Graham. > > > > > > > > > > > > -----Original Message----- > > > From: Linus Tolke [mailto:[EMAIL PROTECTED] > > > Sent: 23 June 2006 18:19 > > > To: dev@argouml.tigris.org > > > Subject: RE: [argouml-dev] Re: [argouml-users] UML model and CVS. > > > > > > > > > > > > Hello Tom! > > > > > > > > > > > > If there are developers working on a design but not simultaneously, > > > then I don’t consider it as concurrent development. The problem is > > > then so very much easier in fact that ArgoUML need no support for it. > > > It can be fully handled by the configuration management system for the > > > project by allowing just one of the developers at the time access to > > > the model file. > > > > > > > > > > > > I don’t consider partitioning the models physically and logically as > > > solution to the concurrent development problem. It is a solution to > > > the “large-model” problem, the problem that arises when your project > > > is so large that you would want to control different parts of the > > > model separately configuration-management-wise. This is a much more > > > complicated problem. > > > > > > > > > > > > I don’t agree that we necessarily need to solve the “large-model” > > > problem before addressing the concurrent development problem. > > > Especially since I think that the effort needed to implement > > > partitioning models, merging models, tracking changes to models, and > > > comparing models is an order of magnitude bigger than allowing several > > > GUIs to connect to the same model and work simultaneously. It gets big > > > because it requires that a lot of knowledge of the model is coded into > > > the tools that address this. > > > > > > > > > > > > Please also observe that a simple XML-comparison and merging tool (I > > > guess that there already exists several of these) together with a > > > developer understanding the relationship between different UML > > > elements could probably solve most of the merging models, tracking > > > changes to models, and comparing models needed for our users. This > > > without any knowledge of the model, UML or Diagrams built into the > > > tool. > > > > > > > > > > > > So, I can summarize to say the opposite: I think we could get a long > > > way by providing better support for concurrent development before > > > addressing the “large-model” problem. > > > > > > > > > > > > /Linus > > > > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > From:Tom Morris [mailto:[EMAIL PROTECTED] > > > Sent: den 22 juni 2006 08:04 > > > To: dev@argouml.tigris.org > > > Subject: RE: [argouml-dev] Re: [argouml-users] UML model and CVS. > > > > > > > > > > > > > > > This sounds like it's intended to address real-time concurrency, but > > > there are many times when multiple people want to work on a design, > > > but not necessarily simultaneously. Also, collaboration isn't > > > necessarily limited to two people. I think we could get a long way by > > > providing better support for non-realtime collaboration before > > > addressing the realtime piece. This includes support for partitioning > > > models physically and logically, merging models, tracking changes to > > > models, comparing models effectively, etc. > > > > > > > > > > > > > > > > > > For realtime collaboration, choosing the appropriate level at which to > > > distribute the application is a key design decision. The elements > > > sent to clients can be anything from blocks of pixels, to drawing > > > commands, to ArgoUML meta commands, to model repository commands and > > > events. Each level provides a different set of benefits and costs. > > > The top level (sending pixels one way and mouse events the other) is > > > probably doable today with screen sharing software using an unmodified > > > version of ArgoUML. > > > > > > > > > > > > > > > > > > Tom > > > > > > > > > -----Original Message----- > > > From: Linus Tolke [mailto:[EMAIL PROTECTED] > > > Sent: Monday, June 19, 2006 10:21 AM > > > To: dev@argouml.tigris.org > > > Subject: [argouml-dev] Re: [argouml-users] UML model and CVS. > > > > > > Hello all developers! > > > > > > > > > > > > > > > > > > For some time I have believed that the best solution to the > > > concurrent development problem is to allow the running of > > > ArgoUML in a server/client mode. I.e. a server opening and > > > saving the model and clients that have an separate GUI that > > > connects to the running UML Model and Diagram Model. > > > > > > > > > > > > > > > > > > With MDR and eventually the diagrams' model stored in MDR > > > (Diagram Interchange?) this design feels not entirely > > > out-of-reach. > > > > > > > > > > > > > > > > > > The benefits is that there is no merging of models by some > > > other tool. All Diagrams, Tree and Model elements update > > > immediately when someone has made a change, part of this is > > > already in place since we have several GUI elements working > > > against the same models already. Mauro's work can be used as a > > > help for reserving objects to avoid race conditions (if > > > needed). > > > > > > > > > > > > > > > > > > The drawbacks are that this requires that all developers are > > > on the same network but that is not such a big deal since most > > > of us are on the Internet anyway. The developers also need to > > > coordinate on who runs the server and who does not. > > > > > > > > > > > > > > > > > > I would like that you had this possible architecture in mind > > > while pondering about the design of the different layers on > > > top of MDR and the Diagram Model. Issues are with one of the > > > developers moving a Fig in a diagram, how have the other > > > developers' clients registered interest to learn about this > > > move and thousands of similar things... Other issues are with > > > things like Undo. Should each user have their own Undo list? > > > Probably. Will that work? Not always. > > > > > > > > > > > > > > > > > > /Linus > > > > > > > > > > > > > > > > > > ______________________________________________________________ > > > Från:Linus Tolke [mailto:[EMAIL PROTECTED] > > > Skickat: må 2006-06-19 15:52 > > > Till: users@argouml.tigris.org > > > Ämne: Re: [argouml-users] UML model and CVS. > > > > > > > > > Yes, Marco! > > > > > > > > > > > > > > > > > > Your original question was how it is possible to have the > > > model within CVS and my answer is avoid concurrent > > > development. > > > > > > > > > > > > > > > > > > If you want concurrent development, then I there are several > > > different ways and reasons to achieve this. > > > > > > > > > > > > > > > > > > Mauro's paper Usando a modelagem colaborativa no aprendizado > > > da UML available from the ArgoUML web page at > > > http://argouml.tigris.org/docs/ discusses a solution where you > > > do this for the purpose of stimulating collaboration (if I > > > have understood it correctly, I don't read Portuguese). There > > > has earlier been other attempts at this where ArgoUML just > > > opens an extra window (which also can be achieved by running > > > ArgoUML in a NetMeeting/Remote Desktop environment). > > > > > > > > > > > > > > > > > > This is probably not what you want but I want to mention it as > > > an alternative for you to think about. > > > > > > > > > > > > > > > > > > /Linus > > > > > > > > > > > > > > > > > > mailto:[EMAIL PROTECTED] > > > >> Sent: den 17 juni 2006 14:39 > > > >> To: users@argouml.tigris.org > > > >> Subject: [argouml-users] UML model and CVS. > > > >> > > > >> UML is great and ArgoUML is great too. > > > >> > > > >> But with respect to MDA I was wondering how it would be > > > possible to > > > >> develop UML model in a CVS as well as we develop today a > > > java class. > > > >> CVS can resolv conflicts on java files but not on ArgoUML > > > files > > > > because > > > >> they are binary files. > > > >> > > > >> And even if we use xmi I not sure CVS can resolv conflicts > > > if xmi > > > > export > > > >> do not take care to export objects always in the same > > > sequence. > > > >> > > > >> Any ideas about it? > > > >> > > > >> Regards, > > > >> Mar > > > >> Compilo subAdministrator > > > -- > > > Ing. Marco LOMBARDO > > > ============================= > > > Mayking spa > > > Via Brescia 31 > > > 36040 Torri di Quartesolo (VI) > > > Cell +39 347 1979448 > > > Uff +39 0444 267561 > > > Fax +39 0444 269945 > > > email: [EMAIL PROTECTED] > > > Skype: lombardomayking > > > web: www.mayking.com > > > > > > > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.394 / Virus Database: 268.9.2/373 - Release Date: > > > 22/06/2006 > > > > > > > > > > > > -- > > > No virus found in this outgoing message. > > > Checked by AVG Free Edition. > > > Version: 7.1.394 / Virus Database: 268.9.2/373 - Release Date: > > > 22/06/2006 > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.394 / Virus Database: 268.9.3/374 - Release Date: 23/06/2006 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
