From kedar@ccs.neu.edu Thu Jan 23 12:23:12 1997 Received: from stockberg.ccs.neu.edu (root@stockberg.ccs.neu.edu [129.10.112.123]) by amber.ccs.neu.edu (8.8.4/8.7.3) with ESMTP id MAA06624; Thu, 23 Jan 1997 12:23:11 -0500 (EST) Received: from stockberg.ccs.neu.edu (kedar@localhost.ccs.neu.edu [127.0.0.1]) by stockberg.ccs.neu.edu (8.8.4/8.6.4) with SMTP id MAA29305; Thu, 23 Jan 1997 12:23:10 -0500 (EST) Sender: kedar@ccs.neu.edu Message-ID: <32E79E7E.167EB0E7@ccs.neu.edu> Date: Thu, 23 Jan 1997 12:23:10 -0500 From: Patankar Kedar P Organization: College of Computer Science, NEU X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.4 sun4m) MIME-Version: 1.0 To: johan CC: lieber@ccs.neu.edu Subject: Re: DemDraw with decorations References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: R Hi Johan, Sorry for the delay. Thanks for ur input. In the current model : There are two lists. 1. DiagramElement List :contains all the diagrams which represent the connected network model components viz. Perspectives and ArcPerspectives. 2. NetList: Contains all the connected network model components viz. NetNode( i.e. ConstClass or altclass) and Netarc(constedge or constedge) Each component owns a graphical representation fifure i.e. perspective and arcperspective. This is really nice architecture as it loosely couples the network model and graphical representation. This was essential as it was a framework not a concrete application. So in order to work with the graphical attributes of the network(or clas graph) components we have to work with the perspectives. currently there is no provision to store the graphical attributes such as color,font,etc. with the perspectives. So i think we need to add here. About the decorator : Curently there is a class for storing user preferences. But it is not used so widely. It can be associated with Document class and then user can select his global preferences which will not affect the UML meaning of the class graph diagram. Write now I don't what these preferences could be. We can keep separate file named cd-draw.cfg or cd-draw.res( like turbo-c has one configuration file). This object can be read and parsed in separately. In my opinion it is better to keep the graph object and the configuration or preference object separate. All the changes that are going to happen during the running of the application(like changing color of the vertex if it happens to be inside the subgraph, etc) are going to have local impact. Once user goes into other mode the global attributes has to be restored. So in my opinion we should provide different draw methods for each mode( nice overloading). instead keeping this information inside the object. Currently there are two different draw methods one for normal drawing and other for drawing the same diagram when it is selected. But at the same time your idea of using same draw method but to use drawing attributes (Decor_List) which are set by the current mode, also appears to be more elegant. I really don't know which way to go. I don't know which is more OO styled. The page for this project is reachable from my home page http://www.ccs.neu.edu/home/kedar Thankx kedar .. johan wrote: > > Kedar, > > I've been 'glancing' at DemDraw.{cd,beh}. I think the vertex/edge list > representation will work, if we modify it a bit. The goals of these > modifications are: > > 1) allow the same underlying object to be used for several purposes, > without forcing a possibly information-loosing print/parse between > the modules. > > 2) make the amount of information carried in the object to be closer > (if not equal) to that in a .cd file. In particular, I didn't see > any provision for labeling edges (ie part names). Eventually, we > want parse/printing information in there as well, in addition to > information about optional parts. > > 3) I'll think of more reasons later on. > > Like I mentioned earlier, I think the way to go is via > decorations. Unlike my former opinion, I now think that the E/V list > should be decorated, and not necessarily the .cd (we want provisions > to convert from one to other _and back_, later. However, this implies > that all decorations must be optional) > > I propose: > > UVertex : UAltVertex | UConstVertex | UTerm > *common* > < id > UID > < vertexname > UVertexName > < position > Coordinates > [< incoming > IEdge_List] > [< outgoing > OEdge_List] > [< decors > Decor_List] . // NEW > > UEdge : UAltEdge | UConstEdge > *common* > < id >UID > < fromVertex > UVertex > [< fromPortNo > PortNo] > < toVertex > UVertex > [< toPortNo > PortNo] > [< decors > Decor_List] . // NEW > > Decor_List = "#Decorations" {Decor} "#EndDecorations". > > Decor = Ident "#=" Object. > > Notice how I slipped in an _Object_ in there. To maintain flexibility, > we don't wish to limit ourselves to printables (and we don't really > wish to have to print/parse everything we wish to decorate with). The > downside is that we can never print out a decoration list- so if we > choose to store objects, we loose the nice flexibility we had > before. > > To keep things loosely coupled, we (as in not com1205) will provide > the Decorated objects. > > public interface demeter.Decorated { // should throw an exception > public abstract void put_decoration(Ident mark, Object decoration); > > // add a decoration the edge e. decorations are identified by > // their mark- it is the user's resposability to make sure all > // marks are unique. If a decoration with mark already exists, > // it will be overwritten with the new decoration. > > public abstract boolean has_decoration(Ident mark); > > // return whether a given node has a decoration for the mark > > public abstract void del_decoration(Ident mark); > > // remove a given decoration. > > public abstract Object get_decoration(Ident mark); > > // this should throw an exception if the mark is invalid. Now, > // lets return a null > } > > UEdge and UVertex need to implement this interface. I guess we could > have the UGraph object implement it as well. I think that that should > be enough functionality so that UGraph should handle pretty much > anything. If UGraph is to implement it, it of course needs the > part as well. > > whadayathink? > > Johan -- KEDAR P. PATANKAR Office : College of Computer Science, Home : 75, St. Alphonsus Street, Northeastern University, Apartment 202, Boston 161 Cullinane Hall, Boston, MA 02120, USA MA 02115, USA Phone: (617)739-7476 Phone : (617) 373-4506 E-mail : kedar@ccs.neu.edu