Black Pearl

Both vis just pass the input to the output. One with LVObject and one with an array of LVObject. Using an object, I get the output of the same class. Using an array, the class type doesn't get propagated. Also, the array Prims handle the class-type propagation. Felix

Thanks for this overview. The concepts (Must Override, private in a lib) cover the ideas I came up with. Your experience did add some new aspects. Mainly this assured me, that I didn't miss anything. 'Abstract' wasn't completely meant in the sense of the 'abstact' statement in other languages, but in the use of all this meta-modelling im into. I could think about instanciating an abstract class but not being able to call the abstract methods. This would be the other way round. I see that you might want to accept the abstract parent class and call the abstract methods of this class because the call dispatches to the child class that has these methods implemented. But I already can do this with interfaces. So an 'abstract' statement is just one kind of realization. I'll dig & think further on this topic. They are interfaces. I guess this is to support for multiple inheritance. But I also see a design advantage in this approach. You focus on inheritance and the method declaration only. The implementation is done in a step further down the road. Doesn't make sense for the implementation of eclipse.uml2: the static methods are in the <Class>Operations class and not in the <Class>Impl class. We might be missing something. Felix

Thanks Ton for the reminder. But I'm pushing back the design patterns to a later stage of this project. First of all, I'm not ignorant of these. I read the GoF book 10 years ago and I frequently re-read them on wikipedia (and if they seem to be relevant, I can cross-check the german and english wikipedia + the linked articles/implementations). Second I use the eclipse implementation (it's OpenSource) as a cross-reference. I guess they did a better design job than I am able right now. So I'm more struggling with getting these things done in LVOOP with the native by-val behaviour and a lot of things lacking (interfaces, abstrac statement, generics). Looking at the java eclipse implementation, I really think that interfaces would do us a favour in the design process (which I really think is a big reason to migrate to OOP, I mean the better 'tools' to do design before coding). In the eclipse code, all uml classes are implemented as interface first, which (in this specific case) is nothing else than designing all function/procedures/methods/properties as a prototype first. In a second step (this is a different folder in the project called 'impl') they do actually implement all these objects (because there is only this single implementation, the other use-cases of interfaces are not applicable). They also have another folder in the project called 'operations' (or was it 'util'), in which all static declarations go (named <Interface>Operation, the implementations have <Interface>Imple as name). I must confess that until now, I never thought about using static-dispatch (what are the advantages over dynamic dispatch?); furthermore it seems alien to me to have all these static methods in a different hierarchy (there are calls mainly/only? forth and back between <thisClass>Impl and <thisClass>Operations). Felix

I was a bit experimenting in the field of generics. I'll at first give a description of the requirements I have in the uml design, and later go to the LVOOP part. uml: A lot of attributes or assiciations are defined as 'derived union'. They are similar to an abstract declaration, as they will be defined by child class(es) -> derived. Furthermore they are composed of all subsets -> union. The child classes define there own (derived or non-derived) attributes and declare them as a subset of the parent attribute. To make things a bit more complicated, sucvh an attribute can have a multiplicity of [0..1], which is valid if all subsets are either emty or of the same value (the union of all subsets will evaluate to emty or 1 value). LVOOP: I realize the derived union/subset concept by overriding the derived properties accessor VI to add the subsets that are declared in this class. (Q1) So these Accessors (for a correct multiplicity of [0..1]) return an array which is either empty or contains n elements of the same value. So I wrote a vi 'remove duplicates' (I will also need to check for a valid Multiplicity). So input and output of this VI is an array of LVObject. As far as I got, I will always need a for-loop with a to more specific prim. (Q2) So far I have only used an array of objects. I haven't explored other concepts of managing the List/Set/Bag. The most simple idea would to use an array of DVR's to the objects. Others would be a by-ref framework class such as linked lists instead of the arrays. (Q3) Q1: As far as I know, we don't have any 'abstract' statements in LVOOP. Can you point me to same concepts of implementing this? Q2: If I only have a scalar of object, not an array, I can propagate the class type to the output either by dynamic dispatching or the Preserve Run-time Class prim. Any chance I could do this for an array of objects? The array prim's work fine if I'd inline the code... If we can't do this, I'll go and write something for the idea exchange. Q3: Will I be able to avoid the type casting if I use any of these concepts? Felix

Ok, here we go. Not all accessors are implemented. But the StructuralFeature by-ref class contains a MultiplicityElement by-val class. Exactly: The ME is part of the TD that is inside the DVR of the private data. What needs to be done (and this is where I'd code some scripting VIs) is writing the accessors VIs. They do implement all public methods of the delegate and pass the calls to the delegate. So actually, this isn't an interface, because the code is in the delegate, but a kind of multiple-inheritance. For an interface, you will have empty methods, inherit them in an abstract parent class and use the must-override flag to force any descendent to implement them. Type casting the class to the implemented interfaces is an objectiv I didn't think about yet. But propably with the correct kind of by-ref, the cast would just pass the 'interface-class'. The nice thing is, that inheritance works in favour of this concept. The delegate will carry it heriatage (so you can design an interface hierarchy), as well as the class will carry the heritage of all interfaces. Felix

I looked up what an abstraction 'is', so here comes the uml2-spec: 7.3.1 Abstraction (from Dependencies) Generalizations • “Dependency (from Dependencies)” on page 62 Description An abstraction is a relationship that relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints. In the metamodel, an Abstraction is a Dependency in which there is a mapping between the supplier and the client. Attributes No additional attributes Associations • mapping: Expression[0..1] A composition of an Expression that states the abstraction relationship between the supplier and the client. In some cases, such as Derivation, it is usually formal and unidirectional. In other cases, such as Trace, it is usually informal and bidirectional. The mapping expression is optional and may be omitted if the precise relationship between the elements is not specified. Constraints No additional constraints Semantics Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional. Abstraction has predefined stereotypes (such as «derive», «refine», and «trace») that are defined in the Standard Profiles clause. If an Abstraction element has more than one client element, the supplier element maps into the set of client elements as a group. For example, an analysis-level class might be split into several design-level classes. The situation is similar if there is more than one supplier element. Notation An abstraction relationship is shown as a dependency with an «abstraction» keyword attached to it or the specific predefined stereotype name. Felix PS: I didn't yet read the dependencies package, so I can't translate this to normal-geek-speak.

Just to keep this updated, I'm moving away from the original topic. Today I found the 'Delegate' design pattern on wikipedia, and it was mentioned to be a solution for the multiple-inheritance. Well, coded the MultiplicityElement as a by-val class (first attemt was by-ref) and put this one in the by-ref private data of the 'child'-class (so it is already by-ref, that's why I implement it by-val). Then write the Accessor VI's and voila. Looks good so far. I think the wrapping of the 'parent'-class can be automated with scripting. Which means, that we propably are a very short step away from interfaces and multiple inheritance of our own brew... I'll dig through the interface implementation thread on LAVA tonight, just to see if I miss something... Felix

I agree with Daklu that software developement is to a very big fraction about creating abstractions. If you draw good software, you spend a lot of time on this and not on the functionality of the code: descriptive Icons, 4x2x2x4 connector pane, organizing vi's in directories, folders, libraries, placing code inside SubVIs, if you OOP, a lot more overhead is going into encapsulation... Abstraction is beautiful, because it structures our code like nothing else. A major advance of good abstraction design is reuse. Here is one of my better designs. As part of the project I had a motion controller, which came with a dll driver and a bunch of ugly vi's that did implement the dll calls. My lowest level abstraction layer did use the provided vi's, but wrapped them with a 4x2x2x4 connector pane and included error handling. This layer could be directly reused on a diffrent project that had the same motion controller but a diffrent mechanical design. The layer above provides the functionality I did need for this project (for the specific mechanical design). It consists of very view vi's that sometimes perform complex operations, like Posisition(x,y), Home, ... On top of these vis, there is a single Action Engine (no LVOOP available). This AE is only for encapsulation, so all VIs that deal with motion are grouped in the hierarchy window and the 'handle' for the controller card is hidden from the user. So the complete LV code consists of 4 abstration layers: 1. dll calls 2. error handling 3. project specific functionality 4. encapsulation My current studies of the uml architecture also teach me how to design abstraction layers. For each concept that is introduced in the uml architecture, there is a set of deticated classes in the inheritance tree (actually, it's a graph as they allow multi-inheritance). And each set of classes is placed in a package. As an example, the ownership package has the two classes namedElement and Namespace. Together, they provide the funtionality to create a tree of nested elements (namespaces are elements that may contain other elements) and to navigate through this tree using OwnedElements and Owner. There is no mixing with other concepts. So one concept -> one layer. Felix

I aim for a code generation tool, I'm addicted to 'scripting'. But I enjoy the privilege of having this as a private project, so I don't expect any tool in the near future. I fear that a major work far on the horizon will be to get uml adapted to LVOOP specific concepts. There is the redefinition package in the uml framework, but I havn't looked at it. I did OOP years ago in JAVA, so the basic OOP concepts are not unfamiliar, neither are some of the GoF design patterns. It is a lot of new concepts though, digging through the 100s of pages of uml specs, LVOOP threads on LAVA, scripting and hooks on LVOOP, the eclipse source code... But so far I can manage to break things down into smaller issues, as this is my everyday engineering task. I'm heading of for holidays this afternoon and might be back on this the end of next week. Felix

Daklu, thanks a lot for the bag implementation. I was trying to avoid this topic and move towards having a real 'uml_class' object. But properties inherit (via structuralFeature) from multiplicityElement. To make things a bit more difficult, multiplicityElement has two attributes: isUnique and isOrdered. So I propably need to cover all 4 cases. I think I'll try to make it a List (they call that Sequence in the uml specs). Later I can enforce the uniqueness if isUnique. And I can introduce isOrdered=false later as well. Felix

That makes perfect sense to have the two approaches! 1) If I'm the class designer and in need for by-ref -> private-data into the DVR 2) If I'm the class user and need to use a by-val class as by-ref -> object in the DVR 1) allows the class user to be ignorant of DVRs, IPEs, ... 2) allows the class user to be very flexible with objects, like have all the init code by-val and just when he needs to branch the object for parallel task operation, place it into an DVR. After parallel execution, dereference back and operate by-val again. So they are not two flavours of implementing the same by-ref. But they are two different use cases: make a class by-ref or use an object by-ref. Because I implement an design that is completly traditional (I refere to JAVA, C++) by-ref, I get better code making the class itself by-ref. In other situations I might be better off using by-val or object-inside-DVR. For my current implementation, I will consider the object-inside-DVR design for the package class. I will try a brief explanation of the model: Almost every class is inherited from the 'namedElement' class. This defines mustBeOwned=true. The only class that overrides this is Package (generalization namespace, mustBeOwned = false). Because the package is the only class the is 'creatable' by the class user (I use this term as you find it when using ActiveX e.g. to to interface Excel, where you need to obtain the workbook ref from the Applications Workbooks Collection via some methods like Add, New), you can implement factory methods like CreateClass(name, classType) (the eclipse uml2 implementation does this). Using the factory design pattern, you can hide the Create and Destroy methods from the class user. General idea for both by-ref designs: It is a bit cumbersome to do all the repeated DVR/IPE/UnBundle operations by hand. Some will be faster using Reusable VIs with the drop content flag set, some will go as templates, others might be benefit from scripting (like an 'Create Wrappers'-tool for the object-inside-DVR). uml-tools: - I still don't use StarUML although I've installed it. - For fast scetches, I still think dia is the way to go (especially as they have also support for other domains, if you don't have a specific tool and/or just need a scetch, it is easy). - For design I'm trying to get used to eclipse. They have a design and modelling branch (I think this equals the galileo package). But it comes with a lot of overhead = full support of project management tools far advanced what you have with your LabVIEW installation (+ all kinds of integration with SCC, issue tracker, ...). I think if you have the need for these things, you'll already go with the toolkits from NI so it's just a duplication (ballast) and you won't want to use your own interfacing with the eclipse enviornment. But they really offer the most advanced uml support I've seen in any of the free toolkits. Felix

It is still raining, so I was doing some code before going out. One thing seems to be a bit cumbersome in LV. In a traditional language I can define a class <list> with all kind of add, clear, ... methods and use that as the type for the accessor Get operation. So I can write something like: MyCollection.GetList.Add(Element) Using the by ref implementation, it seems that I need to either a) rewrite the array as an list object (gives a bad performance). b) provide a class locking (semaphores) so I can code lock, checkout, modify, checkin, unlock c) write the add, clear ... methods for each 'list' Any better approaches. Felix

I did stop performing mind melds with people that show emoticons. In fact, I restricted myself to only do mind melds with silicon based life forms that run a graphical programming language. Thinking about this, we really should have some LV-style emoticons available. Laughing-numerical-prim. Felix

I'm back for the OOP training lessons. On this rainy afternoon, I did concentrate on the question of how to do by-ref implementations. My first approach (and I see the same in the Tree code from GoGators) was to put the object into the DVR. This seems to be a direct translation from other OOP languages with their pointer based by-ref concept. So today I realized that I also can place the data inside a DVR, make the object private data only the DVR and have the referencing/dereferencing inside the accessor methods of that object. This looks much better, as I 'hide' the by-ref implementation from the user (means they need to know nothing about DVR and IPE and less effort to code because they need to be coded only once). The self-referencing seems to work the same way via a parent class (placed inside the data TD inside the DVR inside the private data). Do these two approches to by-ref differ considerably? I don't want to consider for now all the fine details where I can get race-conditions or deadlocks, for this I would just like to have a general judgement approach A or B is more robust. If the weather won't change tomorrow, I'll try to face my problems with this way of coding. Felix

Both books target beginners according to their description. Bishop already has published a book on older LV versions, so propably having a review on one of those would help you judge the 'value' of the new one. To the more interesting part of this thread: those that lava are of course Vulcans Felix

In germany you have the same issues, and I always change the country settings to US. But then if you create a new user (even worse if the customers are doing this), it might show up as DE again. A lot of software and hardware isn't localized, and I really don't want to care about it. On the other hand, Excel is localized to an incredible amount. All the functions for the spreadsheet are localized! If you do any advanced thing with it via ActiveX from LV, this is unmanagable... Felix

First of all, get used to data flow. Use wires instead of locals to have the behaviour of 'variables'. You need to wire the output of i/10 to the = function instead of passing it via a local variable. You have no control of the execution order except data flow, so your loop might run 1 more time than you wish. Please keep posting code on the forums, so we can teach you the 'right way'. Don't feel offended, everyone coming from a programming background is doing these mistakes. As I can't see the true case, I can't judge if the outer while loop is necessery at all or I tried to solve you problem with it. Second, there is a primitive called 'First Call'. Wire it to the Select input of a Switch primitive. The true terminal will be your default starting value while the false terminal will be the feedback node. Felix

I checked his homepage, and he is researching on parallel programming. But using JAVA... Ok, got enough topics for the next family come-together. Felix

I joined the crowd rushing after this strange element Hq. Seems like easy to learn/use. When I was reading some introductions, I found that they warn to use it for large sets of binary data. Anyone yet experienced to say how it will work on real LV projects? The other issue that still keeps me away from using it, is the merging process. As far as I understand Hq yet, merging is the very elemental interaction you would do. I'm stuck with a FDS, so no merging for me (except I write my own LV merge...). Will this be a show-stopper? Should I stay with SVN? As a side-note, reading the manuals I discovered that it was my uncle who programmed the second SCC (and the first free one) called Revision Control System (RCS). I'm not sure if he is still into that... Felix

I don't mind the 'hijacking'. Felix

Thank you all for the feedback. It'll be next week that I'll have the time to look deeper into this. Concerning GUID, I already have xmi:id and I think it's unique for each element=object (and not each type of element=class). So the element manager might be a good idea. The main issue I ran into was that I tried to use the eclipse/java implementation to avoid architecting it all on my own. This was obvious the wrong way... So I was browsing through an abstract factory (so everything was multi-inheritance of interfaces, and no references of the actual implementation) and trying to find the Set-Accesor method for the owners. Well, the 'trick' is that the GetOwnedStuff returns a object inherited from the list class, which does implement an add method. So I'm going to try to rearchitect it towards native by-val. Felix

For this weekend I decided not to play around with VI Scripting but do learn some LVOOP. What I would like to do is to get the following design into LVOOP, taken from the UML specs: -- 7.3.14 Element (from Kernel) [..] Associations • ownedComment: Comment[*] The Comments owned by this element. Subsets Element::ownedElement. • / ownedElement: Element[*] The Elements owned by this element. This is a derived union. • / owner: Element [0..1] The Element that owns this element. This is a derived union. 7.3.33 NamedElement (from Kernel, Dependencies) [..] Generalizations • “Element (from Kernel)” on page 64 [..] Attributes • name: String [0..1] The name of the NamedElement. • / qualifiedName: String [0..1] A name that allows the NamedElement to be identified within a hierarchy of nested Namespaces. It is constructed from the names of the containing namespaces starting [..] [2] When there is a name, and all of the containing namespaces have a name, the qualified name is constructed from the names of the containing namespaces. (self.name->notEmpty() and self.allNamespaces()->select(ns | ns.name->isEmpty())->isEmpty()) implies self.qualifiedName = self.allNamespaces()->iterate( ns : Namespace; result: String = self.name | ns.name->union(self.separator())->union(result)) -- So in everyday-geek-speak: * The element class needs a reference to an object of type element (the owner). I'm not really sure how to solve this (DVR's?). I can get this not breaking the arrow by using a parent class of element (ElementParent.lvclass) and using this as part of the private data. * If I now try to make the qualified name, I need a) to cast the Owner to the Element child class (ok) b) to recurse through the GetQualifiedName method. (Here I get errors thrown). How would you code up a design like this? Felix

AQ: thank you for the presentation. On the download, the audio tracks are a bit screwed. I get the Q&A section played over you speech. It starts about min 32. Felix

The only recource I found so far is an 6 year old thread in LAVA1.0, so: Anyone sucessful in using eclipse together with LabVIEW? I actually was just looking to get a nicer uml modelling tool (dia is not advanced enough, I dislike the look of StarUML). So I installed eclipse -> WOW! That's a big supermarket full of developement tools without an cashier. So I hope to upgrade my 'FDS' to the 'über-geek Eclipse Managed More Than Professional Developers Suit'. Or is this just a dream and I only will waste nights trying to get some Java Code running instead of ordinary-but-loved wirework? Being new to eclipse at all, it will take some time to understand the concepts and explore the possibilities (any good readings?). So I don't expect to be ready next month. As a start, I'd like to call some LV code from eclipse to get some uml model from eclipse into LV code... Felix

Hope your company has a production hall where that monitor fits in! But honest: they people that write this kind of code, they certainly always tell the management that they work on a very big project. And we stupid guys won't ever show them such impressive things... Wait, there is this inline subVi scripting tool. I just need to make it work fully recursive and get it launched via QD. Every day I will aks for pay-rise and a larger monitor.... Felix