Black Pearl

A cool video and some NI guys promoting their new products for producing lightening stroms: Sweet Apps Blog on NI community Felix

A good suggestion for friday night.... Felix

That could be an issue, as if you resize the array, the complete super-cluster must be reallocated/copied. But I would suggest to dig further. Try to get hold of the code section where LV crashes. If your project is big, you could implement a simple logger vi, that just writes to a file it's call chain. Then you know until which point the code did run fine. Felix

It's very simple in LabVIEW: Create a gun.vi with a nice gun icon and an indicator (wired to ConPane). Create a foot.vi with a nice foot icon and a matching control (wired to ConPane). Place both vi's on an empty vi and wire them. Run the vi in highlight execution mode. Felix

There are tools around to make an app running from an usb memory stick, that cheat things like the M$win registry. They could be useful for the last parts we don't make be removing the rubbish from our installations. I've never worked with them, though; sorry. Felix

Congrats. Felix

Well, my specs usally say: 10. software: customized software wirtten in LabVIEW. Yep, no more. And I can live with it. The customer hase to design the feature (write more detailed specs) and at some point I can say 'that's out of scope/budget/...'. This seems to be a completely different situation that NI has, but in parts, it isn't. Once I have a feature completed and go on to the next customer, all change requests are pure cosmetic. Well, both situations are completely different. So I try to put it in a much higher abstraction level. I think that a correctly working software only gets (by request) two kinds of additions: * new features (so completly new from the scratch, as add-on) * cosmetic changes (like a cancel button on a dialog) and this mechanism is user (customer) driven. but seldom (never) * improving a sub-feature (performance optimization, Edit->Create SubVI) * adding a subfeature (e.g. support for abstract classes in LVOOP) Because this can only be judged by the developers and sometimes the power users; never management or new customers (-> marketing). Felix

The 'community' is even weaker, but much better polished. And a lot of succesful open source projects use ugly bugzilla web services. I wouldn't judge from what we see to what 'they' see. Well, we all know that the LV programmers community is cool, despite scrapy ways of communication. Which brings me to a fundamental 'flaw' in the IE system. You and me as users just see a very small portion of the complete code. We are power users, don't forget, so we already discuss 'stability' and 'performance' while I guess most ideas are on the level 'add a button to do X in Express VI Y'. I make pretty complex measurement equipement and I'd like to have the customers questioning the 'though stuff' (how do you implement error propagation, what about the PID controller, how is your internal messaging system designed ...) but in 99% of the cases I get 'I want a cancel button here', 'I want a plot legend there' and I want a 'comment field in this dialog'. If the only mechanism to develop LV further would be the pure IE exchange, we will all be talking about the good old times of Express VIs when LV didn't look like facebook. If we implement a class, we would need to invite the method vi's as friends and then go on the method to accept the invitation; instead of Icons they would all have Avatars double the size of an express vi .. Felix

I enjoy the discussion with you, because it really helps me to understand my own issues (in this case uml) better . As the metamodelling is a field somwhere between mathematical/philosophical domain and formal (computer) languages, it comes to splitting hairs about every single word. In addition I'm a bit frustrated why associations are classifiers and not relationships. So slightly modifying your statement above: 'inheritance and dependencies are specific types of associations relationships' is according to the uml specs. After writing the previous post, I actually found an explanation why associations are classifiers: they own properties. Back to splitting hairs: a link is the instance of an association. Nope. They specify the model. So, whatevery you do, a state in your (any) uml model ownes an optional 'entry'-Behaviour. If your implemenation of a state machine has an entry code, but your uml model has not, your model is incomplete (which is not bad!). If your model has an entry behaviour but your implementation has not, your work is not finished; so either: a) rework the model so there is no 'entry' behaviour, b) code the 'enrty' (if possible by your state machine design) or c) make a state machine design that allows for an 'entry' code. To get a bit philosophical, we make our lifes easier be needing to make less decisions. Having a good knownledge of uml and LV eliminates a) from above choices (never model what we can't do because we now what we can't do) and make c) more easy because we know a state machine design that allows for entry/doActivity/exit. Felix

Inheritance and Dependencies are not Associations. If I remember correctly, they both are decendants of 'relationship', while the Association is a Classifier itself. Also note, that associations connecting properties (so not methods or parameters). Because they are connecting properties and properties can be stored in the classes private data (if the properties belong to the class), it is always necessary to have the type cast in LV for bidirectional associations. It was clear to me that you can have bidirectional associations with by-ref implementations (also requiring the type casts). I was questioning if the same is possible with by-val design, which you showed is practical code. Yes, that was my point. From the formal point, the state machine should contain the 'alphabet', the states, the transitions, the initial state and the final states (Σ,S,s0,δ,F). But I'm not sure if this really would lead to a 'better' code. Doing it all the way as 'correct uml' with region->vertex->state seems like an overkill to me at the moment. I was actually looking at the mathematical model. I'm ok with an implementation compromise. I was thinking more about this. From a 'formal point of view' where I just look at the abstract state machine, it is very clear to me that states (executing code fragments) should be seperate from transitions (defining the order the code fragments are executed). I think this seperation is even more functional than Entry/Do/Exit. This is one of the big questions: to what extend should code reflect the uml meta-model, how concrete (or strict) should be the uml syntax. Felix

Looks really cool. Did take me some time to follow the cycle from Paul's big paper through the other threads, and I certainly miss some of the discussions. A lot of half finished thoughts from my side, but I just throw them in the debate as fuel for all of you: Bidirectional Association of by-val classes This has kept me thinking for some time when studying the association meta-class of uml for my latest post on my blog. At first I was convinced that by-val design only allows uniderctional associations of classes. But theoretical thinking told me, that if class A contains class B, I can place class A in a LVObject in class Bs private data (inside the Get method). Later I then can retrieve class A back from B with a type cast and update the values of B inside A. If I read the code correctly, this is implemented between StateMachine and State. If so, thanks for the proof. Dynamic dispatch instead of enum/case This was discussed on the NI forum recently (I don't remember the thread). Basically, the traditional enum shift register and case structure design is completly replaced by dynamic dispatching. Again, if I understand this correctly, thanks for the demonstration. Readability of the design This is dating back to my first analysis of state machines. I did browse some text-based implementations of state machines. I think they used a very similar design. At that time, I felt the case/enum SMs in LV very superiour as they directly present me the code instead of the general state machine design. This is nothing if I have an up-to-date documentation in uml as presented. But getting to the concrete code takes me a couple of clicks more than when I use the traditional non-OOP approach. I would list this as a big con because I have to do a lot of 'cowboy coding' on customers site and neither have the uml tools available there nor the time for proper modelling. But I see that I have the possibility to attack a task by at least two ways: EITHER going through the state machine and accessing the concrete dynamic dispatch vi of Enty, DoActiitiy or Exit OR going through the class of the states and having in the PE for every class access to all three Activities. Now comes the theoretical stuff: state machine theory I: transisitons I checked the wikipedia entry on state machines. The mathematical modell suggests that a state machine has states, transisitions and an alphabet. From this, the state classes should not have access to the command queues (alphabet). Also they should not contain the transitions, tranisition logic and TransisitionActivity. state machine theory II: Entry state The initial state is also part of the state machine definition. So the private data cluster of the stateMachine class should contain a set (array) of state classes and an initial state (which is 'listed inside'/ 'an element of' the set of states (can you force this?). uml I: transisitions I just did have a very brief look at the state machines in the uml specs. Transisitons are seperate from States. The transitions are performed by the state machine meta-class and not the state meta-class. This is a bit tricky in the implementation, but described in the specs: If the states DoActivity finishes execution, it's generating an event/trigger. If a trigger is received by the SM, the DoActivity is aborted Certain triggers can be deffered as an attribute (?) of the state. I didn't get all of this in my head at first reading, so propably anyone who mights try to improve the design be adjusting it to uml: Superstructure Chapter 15; Tranisitions 15.3.14; 15.3.11; current spec. uml II: pseudostates To get even more out of such a state machine design, we could target the list of pseudo-states. I consider all parallel process options to be really cool in LV, so fork and join could be nice to have. Even more I'm struggling with the concepts of Deep and Shallow History. uml III: orthogonal regins, sub-statemachines Now I'm really leaving my LV knownledg and completely focus on uml state machines. Is it possible to have a general (reusable) state machine class (and each specific state machine is inherited from this with it's own set of states)? Can we do a nesting of state machines (the top SM contains a state that contains another SM)? Can we find a deign to have two and more SM's running in parallel as 'orthogonal states', including proper mechanism to stop the others in case of severe errors in one of them? Ok, enough of theory. Hope this hobby of mine helps you to get projects out and is not just a waste of time. My professional work is completly non-OOP, non-uml. Felix

Look at the (auto)correlation. Felix

In my playground uml specs it's treated the same way. If no visibility is specified, it's treated as public. Felix

And with localisation to Erich, Erik... Felix

I created some simple polls. There is no option for multiple choice, so I can't just ask 'which diagrams do you use?' but I need seperate polls for each type (well, I only ask for Class and StateMachine). http://decibel.ni.com/content/groups/uml?view=poll#/?tagSet=undefined Felix

Just a 'hack' idea: make the window it's own exe with the icon1, then call this exe from the main (icon2). Felix

It's friday evening and it's raining outside: You made my weekend! That's even more than you revealed on the ni community in terms of presents for the 'scripting ninjas'. Now I need to send a PM to JGCode to thank him as well. Felix

difference between engineers and journalists: journalist: who can I blame engineers: who can I get to fix it (otherwise I need to fix it) Felix

As far as I can read/understand Java code, it supports multiple inheritance for interfaces. So you were correct. Anyway, thanks for the citations you posted. The note you posted above about uml is not complete (superstructure 7.3.24 ) : * there is nothing that forces the methods to be abstract in the interface (it is mentioned for the properties!). -> I'm not clear with this. * Constraints (Pre- and postconditions) are forced to be implemented with the interface. * association can be forced by the interface. * An interface can redifine Interfaces (I don't know what redefine means, sorry -> I want to be able to tell you next week). * An interface can contain classifiers (thats really important, how to write a method which returns or accepts a MyCLassA as a parameter?) * It is somehow (I don't understand yet) possible to say that a class requires a certain interface. I see the use: I want to call MyClass.MyOperation(iMyInterface). As far as I see at the moment: * Interfaces can only have abstract methods * abstract class can have a mixture of abstract and implemented methods. * if you have abstract methods only (as by interfaces or pure abstract classes), you can allow multiple-inheritance. Also, turn it the other way: * an abstract class can contain some code ([re]used in the child classes). An interface not. * A very importantfeature is to call any object by it's interface. Felix

From uml (Interface): As a classifier, an interface may be shown using a rectangle symbol with the keyword «interface» preceding the name. So it is only the type, not the API. Also, there is no stereotype <<interface>> in the standard profile. I also was wrong with my saying about the Interface is different than a class, interface is a child of classifier, as is the class. There is also a class called InterfaceRealization, this is the one that has a very different inheritance tree (Dependency, Abstraction, Realization). Felix

@Dave/Daklu, the Adapter seems to be a very cool pattern for LVOOP, as a kind of substitute for the missing interfaces. I'll need to study them... Here a set of 'stupid' things (I just want to state that I'm not a wise old man but feel more like a babarian in the fine civilization of OOP) I gained from my studies on meta-modelling and OOP (just in case you might find them useful or like to discuss): * It seems that in the beginning of OOP interfaces and abstract methods/classes were about the same. You call an object by its abstract parent class or it's interface and don't care how it implements it's methods. How these are implemented (not the methods but abstract c/m and interfaces) is very much a language flavour. * In MOF (which is the metamodel of OOP), abstract classes are suggested like this (which is possible in LVOOP): Each package should provide a factory to return the classes. In case of an abstract class it should return a null-pointer (that's not possible in LV, but a default obj) and a NullPointerExeption. * In uml, interfaces are very different to classes in respect of their inheritance. I'm not yet into the details. But it is mentioned that they provide a facade to the class, so the facade pattern could be a way to go (I think that's Daklu's implementation, I also think about the adapter pattern at the moment). * In uml there is also another concept, I think it was called 'Substitutable'. It works like an interface in situation where you can't have interfaces (uml is meant to model also stuff outside programming; you can't model an electronic circuit by defining 'interfaces' the same way). Again, I haven't looked into the details. Felix

I just did download it 2 days ago and it was fine. Felix

Congratulations and thank you! For us users it is really valuable to have such a close communication to R&D. This is a very exceptional parctice and a great personal commitment. Felix

To still feed the original topic - preferred uml tools: The developement of the eclipse uml2 tools has slowed down/stalled; it wasn't part of this years release (helios). However a new tool is on the horizon: papyrus mdt http://www.eclipse.org/modeling/mdt/papyrus/ It didn't make it into the releas as well, but it can be downloaded as an add-on from helios. I've been playing around with a day for now, it seems a bit more powerful than the older uml2 tools. Still it is lacking user friendly design and also provides the classic open-source flaw: don't ask for documentation. If looking for a heavy-weight but free (open-source) option, check it out. It's even listed in the OMG's list for SysML (which is pretty short). Felix

Just focusing on data types: Paul, is it possible that you export them as xmi, then I should be able to import them in my tools. On the implementation, I think I32, SGL, DBL, ... should be modelled as primitive types. Arrays would be modelled using the multiplicity, I would need to look up where this is inserted in the class hierarchy. Clusters would be of DataType: DataType is specialized from Classifier (same as Class) and has attributes. The advantage is that dataType does not have an identity. Enums would be LiteralEnumeration. More intersting would be how to model advanced and by-ref data types with their specific usages: * Communication types: User Events, Notifiers, Queues * For by-ref implementation: (single-element) queues, DVR The other work to be done in this field: using profiles (?) to disallow inheritance, methods (?) modelling polymorphism, type-casts, uml method ConformsTo() (then again maybe we need to modell this in OCL) implementing type def as a sterotype (?) <<type definition>>, maybe also for strict type def and private data cluster Felix