Design Patterns in Dynamic Programming

I mentioned this on a thread some time ago - that many of the GoF patterns disappear in languages such as Lisp, but didn't have the reference handy. Came across it again today so I thought I'd post the link:
http://www.norvig.com/design-patterns/
Pete

hi sourdi
Below are the list of Design pattern in abap .
Singleton: ensuring single class instantiation
Adapter: making class interfaces compatible
Factory: encapsulating object creation
MVC: decoupling business logic from the view
Facade: providing a simplified interface
Composite: treating individual objects and compositions uniformly
Decorator: forming a dynamic chain of components to be used as one by the client
regards
chinnaiya P

Similar Messages

ABAP Object X Design Patterns X Extreme Program

Hi Evebody,
Im postgraduate in Object Oriented Analysis and Programming.
Ive been working with ABAP procedural development for two years and Ive started to work with ABAP Objects has few months.
Id like to get deeply knowledge in my developments skills, could someone tell me if ABAP Object X Designer Patterns X Extreme Program is a good path to follow?
Id like to share material and guides about this topic.
Ive already bought these books to help me.
ABAP Objects - H. Keller; Hardcover (Pre-Order)
Design Patterns Explained - Alan Shalloway
Ill be very grateful with any help.

> And do you think these themes are a great combination
> for ABAP development?
Design pattern are very abstract and can be used with any OO programming language. The implementations will differ but the core concepts are always the same.
XP is an agile development process and can also be used with any programming language.
Learning what design pattern are and how to use them is very important in my opinion. Most companies expect that you are familiar and have experience with them.
Extreme Programming (XP) on the other side is different. When I began to explore XP it got me started on how software should be developed in general. Since the concepts behind XP are quite different, it should at least stimulate you to start thinking about how you develop software at the moment and if there might be better ways of doing it.
If you have only time to study one subject go for the design pattern. You might also consider reading the following books if you want to improve your OO coding skills:
<a href="http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672/ref=pd_bbs_sr_1/102-4989641-7820932?ie=UTF8&s=books&qid=1173448197&sr=8-1">Refactoring: Improving the Design of Existing Code (a true classic)</a>
<a href="http://www.amazon.com/Refactoring-Patterns-Addison-Wesley-Signature-Kerievsky/dp/0321213351/ref=pd_bbs_sr_2/102-4989641-7820932?ie=UTF8&s=books&qid=1173448197&sr=8-2">Refactoring to Patterns (Shows how to improve code by introducing design pattern)</a>
cheers
Thomas

Design patterns for Dynamic Class Loading

Hi,
I have to develop a program for uni that dynamically loads classes based on names in a text file. All the classes subclass an abstract class with a constructor that takes one argument. This means I can't use the Class.forName(className).newInstance() method of class loading. I have researched some design patterns I could use and have come up with the following 3:
Factory pattern; "Robocode" pattern (not it's real name, but Robocode uses it); and, the "one I made up myself" pattern.
The robocode pattern instantiates a class using the default no-argument constructor then immediately sets all properties that shoud have been provided in the constructor:
Object o = Class.forName(myClass).newInstance();
o.setProperty(property);Personally I think this is ugly and a cheap fix instead of doing it properly.
My own pattern finds the constructor that takes the arguments I need then calls it to create the object:
Class c = Class.forName(myClass);
Constructor cons = c.getConstructor(new Class[]{Class.forName("java.lang.String")});
Object o = cons.newInstance(new Object[]{"hello"});What's the best to use? Are there any other patterns I should consider?

My own pattern finds the constructor that takes the
arguments I need then calls it to create the object:
Class c = Class.forName(myClass);
Constructor cons = c.getConstructor(new
Class[]{Class.forName("java.lang.String")});
Object o = cons.newInstance(new Object[]{"hello"});
I have followed this basic 'pattern' several times though I would use
Constructor cons = c.getConstructor(new Class[]{String.class});
It works great.

Design Patterns: 'Program to an interface, not an impl.' and Factory Method

Design Patterns: 'Program to an interface, not an implementation' and Factory Method.
Hi All,
I've 4 questions. And 1M thanks for your precious input.
1. OOAD steps:
Requirement-->Use Cases-->Analysis Classes-->Sequence Diagrams-->CRC-->other UML diagrams if needed--> Domain/Business Classes.
If we follow the rule 'Program to an interface, not an implementation',
would that imply NECESSARILY we should have another set of Interface Classes for our Domain Classes? i.e Interface_ClassX for ClassX_Impl.
2. If the point 1 is a MUST because of the rule 'Program to an interface, not an implementation',
ie we should have an Interface classe for every one Domain classe,
would that NECESSARILY imply we should have as many Factory Methods as they are Domain Classes to abstract the creation process?
Interface_ClassX X= Factory.GetClassX() ( return new ClassX_Impl)
Interface_ClassY Y= Factory.GetClassY() ( return new ClassY_Impl)
Interface_ClassZ Z= Factory.GetClassZ() ( return new ClassZ_Impl)
3. On the point 2, the underlying principle used is Factory Methods.
Now on the surface, what are other possible business and/or technical naming for such Factory Methods? I mean should we call it a kind of Business Facade?
4. Is the point 1 and point 2 considered to be the best practices?

So the question here is whether we can predict having
more than one possible implementations which required
option c. Is this a dilema? I guess it's hard to
predict the future.Right. Hopefully it's fairly obvious while designing things and
deciding what objects are needed.
Now, if the Presentation Tier, says JSP, needs that
ClassNormal object. Would we still keep that line of
code a.
OR would we introduce an intermediate object to free
JSP from the direct creational aspect using new
keyword like the choice b. that you reject.
The point here is to reduce the direct coupling aspect
between the Presentation Tier and Business Tier. So
what would that intermediate object be?In that case, you have to ask yourself if there is a valid
need for reducing the coupling. If you simply make an intermediate
object, what keeps you from making an intermediate object to your
new intermediate object, ad infinitum.
That intermediate object could be a Facade pattern, or simply
an abstraction. We actually did that here, we began a massive
java project, and we abstracted away from Swing J-classes and created
our own "wrappers" that simply extended all the J-classes and we had
all our programmers develop using our wrappers instead of the Swing
classes. That allowed us to add some custom code, some temporary bug fixes, etc. Some of our classes were nothing more than "EPPasswordField extends JPasswordField" with nothing overridden. It does allow us a place to hook in and adjust or fix things if needed though.

Program for designing patterns for fabric

I need advice on which program would be best for designing patterns to then use for fabric printing, wall paper etc.
I am a complete adobe novice.
Thanks,
Kim

Hi kimtreasure,
For designing you can use Adobe Illustrator and Adobe Photoshop.
For more info:
Photoshop : Adobe Photoshop CC new features | Buy Photoshop CC
Illustrator : Adobe Illustrator CC new features | Buy Illustrator CC
Download trial version.
Creative Cloud Help | Install, update, or uninstall apps
Thanks,
Atul Saini

Design Pattern for multithreaded client server program

I asked this question in another post, but with other stuff, so I'll distill this one.
I am creating a multi-threaded client server program (just for learning - a chat program at this point). I built the server and client in swing, and I'm wondering what the best design pattern is for this setup. Right now all the swing stuff is in the MyServer class. In that class I have a loop accepting client connections to the serverSocket and creating a new MyServerThread (threaded client connection).
The problem is that all the work of creating input streams, interacting with the server, all that stuff is done in the MyServerThread class, but I want that text to be written up to the Swing objects - which is in the MyServer class. So right now in the MyServerThread class I pass the MyServer object into it, but I'm not sure if that is really the most robust thing to do. Does anybody have any suggestions as to how this should be done. If somebody has an article they'd like to point to I'll check it out too. But if it's just the run-of-the-mill multithreaded client-server article, I've read alot and most don't specifically address my question.

Thanks for the reply Kaj, and I think I'll keep my design for now, since it's just quick and dirty. I've read the MVC concept a while ago and I'll revisit it again when I get more serious. But I have a question, why should I be using a callback interface, why an interface at all? And then make MyServer implement that interface...why not just pass MyServer to the thread object? Or is there something down the line that I did not forsee?

Wpf: Event driven vs MVVM design pattern

I'm a beginning coder and I've been working on a WPF app for several months now and struggled to implement anything in MVVM due to time constraits to learn so I coded my program the only way to knew how: with code behind, tight coupling, and a whole bunch of
spaghetti code.
My program has grown into 20,000+ lines of messy (but working) code that is mostly event driven. The app I am building will probably be used and continue to be developed for years to come, but I will be the only one working on the code.
However, now that I have time to start learning MVVM, I'm wondering how useful it really is to follow the MVVM pattern. I'm considering refactoring my code into the MVVM pattern but everything seems 100x difficult to do with little documentation. With using
code behind and tight coupling, I can make the UI do exactly what I want it to do and everything seems like it can be coded so much faster through the event-driven methods.
How important is it to follow the MVVM design pattern for WPF apps, especially in the long run? Do you think it's a good idea for me to invest my time to redesigning this app and following an MVVM pattern?

20k lines is a lot.
That will mean maintenance will be a significant overhead.
Anything making maintenance harder will mean maintenance takes longer.
If you're going to do any serious wpf development ( and 20k lines is serious imo) then you should be using mvvm.
The thing is though, it's different.
You will need to learn it before it becomes second nature and doesn't appear to be an overhead.
It isn't true that "everything" can be coded so much faster with event driven methods.
In fact a number of things are way easier to do using mvvm rather than code behind.
If that isn't enough to persuade you.
Teams use MVVM.
Go to an interview and tell your prospective team lead you think mvvm is no good and you may as well not go to the interview.
If it becomes obvious in an interview you haven't learnt mvvm then you will not be chosen.
Teams also use automated testing.
This is nigh on impossible with code behind and one of the selling points of mvvm.
You can test without instantiating a view which means you can run thousands of fast tests in seconds.
That means you can make changes safe in the knowledge you're not breaking stuff you haven't worked on.
It means someone else in the team doesn't break your code without realising.
Since UI and code are decoupled you can makes changes to either or both rather easier - that decoupling = flexibility.
As your code base grows then re-factoring becomes MASSIVELY faster if you have automated tests in place and your layers are loosely coupled.
I don't know about this paraticular app you have because I don't know almost anything about it.
If you plan on doing professional wpf development then I suggest you re-adjust your opinions on MVVM.
Please don't forget to upvote posts which you like and mark those which answer your question.
My latest Technet article - Dynamic XAML

Is there a design pattern for this?

I'm looking for a solution to a design problem I have.
For a restaurant booking system I need a number of different opening times describing when you can and cannot book. These opening times are essentially Jodatime Period objects. There's a set of opening times spanning a week and these are repeated for every week (a default set of opening times) however it's possible to override these opening times say for a specific day.
The domain model would be something like a Restaurant class holding 2 Lists of OpeningTime objects one for defaultOpeningTimes and the other for overiddenOpeningTimes the overidden ones get used if they exist for the requested time period. However the database model would be a bit messy as I'd have 2 lists mapping to the same table (OpeningTime). Is that a good idea? Perhaps there's a design pattern for this, if someone could point me in the right direction I'd be very grateful, or perhaps this is the best solution? Thanks!

jduprez wrote:
But why do you put the logic in the database too (I'm no DB expert and I didn't know these concepts until I read your post, but that's what a dynamic view based on derived values looks like to me): performance (1 round-trip instead of two)?Hi jduprez. Long time no speakee.
I guess part of it is that I spent many years as a DBA and modeller, and really appreciate what it's taught me about design. Also, databases are (or should be) designed from the ground up to provide data-directed requests optimally, and include all sorts of nice stuff like transaction handling that aid consistency, as well as speed.
That said: I HATE SQL. Think Coliseum, with that emblazoned in 60-foot high letters around its walls, and it might come close to just how much I hate that so-called "language". I hate its form; I hate it's inconsistencies; I hate the fact that something like what OP is trying to do is NOT an easy task (and might involve the creation of a table that simply contains Dates, just in order to satisfy Boolean logic).
However, once you work it out, a database view (at least from the database's standpoint; JDBC I'm not so sure about) is just like any other Table - and that I DO like.
Programs are good at processing parameterized (ugh) temporal information; databases are good at persistence and high volume. Those two may meet at some point, but I reckon it's going to take another Codd (or Joda) before it does.
- that's clearer to 90% of the dev team (my biased numbers, based on 50% of Java developers having decent knowledge of SQL and much less than that having the advanced SQL knowledge which I rank your suggestion at)Sounds to me like you'll get the solution that matches the skills you have then. Is that what you really want, if a better one is available?
- that doesn't require investigating the if of your suggestion (JDBC support)Agreed, but only because my JDBC knowledge isn't what it could be. I'd also be surprised if it doesn't support access to a named view, since they were designed to be equivalent to Tables.
- the Op is using DAOs, so it's possible, if profiling does show this is hampering performances, to change that with no impact on the client code that calls the DAO.There's no doubt that a database solution is much higher level than a programming one; but, as I said, it's what they were designed to do. And tinkering around with program optimization has the feel of a "hacker's solution" to me. Not that there's any particular problem with that - I do it quite often when I have no control over my source - but I also try to keep in mind what the "actual" problem is.
Winston

What is the best design pattern for this problem?

No code to go with the question. I am trying to settle on the best design pattern for the problem before I code. I want to use an Object Oriented approach.
I have included a basic UML diagram of what I was thinking so far.
Stated simply, I have three devices; Module, Wired Modem, and Wireless Modem.
In the Device Under Test parent class, I have put the attributes that are variable from device to device, but common to all of them.
In the child classes, I have put the attributes that are not variable to each copy of that device. The attributes are common across device types. I was planning to use controls in the class definition that have the data set to a default value, since it doesn't change for each serial number of that device. For example, a Module will always have a Device Type ID of 1. These values are used to query the database.
An example query would be [DHR].[GetDeviceActiveVersions] '39288', 1, '4/26/2012 12:18:52 PM'
The '1' is the device type ID, the 39288 is the serial number, and the return would be "A000" or "S002", for example.
So, I would be pulling the Serial Number and Device Type ID from the Device Under Test parent and child, and passing them to the Database using a SQL string stored in the control of the Active Versions child class of Database.
The overall idea is that the same data is used to send multiple queries to the database and receiving back various data that I then evaluate for pass of fail, and for date order.
What I can't settle on is the approach. Should it be a Strategy pattern, A Chain of Command pattern, a Decorator pattern or something else.
Ideas?

elrathia wrote:
Hi Ben,
I haven't much idea of how override works and when you would use it and why. I'm the newest of the new here.
Good. At least you will not be smaking with a OPPer dOOPer hammer if I make some gramatical mistake.
You may want to look at this thread in the BreakPoint where i trie to help Cory get a handle on Dynamic Dispatching with an example of two classes that inherit from a common parent and invoke Over-ride VIs to do the same thing but with wildly varying results.
The example uses a Class of "Numeric" and a sibling class "Text" and the both implement an Add method.
It is dirt simple and Cory did a decent job of explaining it.
It just be the motivation you are looking for.
have fun!
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Business delegate and Session facade design patterns

Does any one tell me, what is the difference between business delegate and session facade design patterns.

1. Session Facade decouples client code from Entity beans introducing session bean as a middle layer while Business Delegate decouples client code from EJB layer ( Session beans).
2. SF reduces network overhead while BD reduces maintenance overhead.
3. In SF any change in Session bean would make client code change.
While in DB client is totally separate from Session bean because BD layer insulate client from Session beans(EJB layer).
3. In only SF scenario, Client coder has to know about EJB programming but BD pattern no EJB specialization needed.
4.SF emphasizes on separation of Verb, Noun scenario while BD emphasizes on separation of client(presentable) and EJB layer.
Anybody pls suggest more differences ?

The search for a perfect design pattern

The search for a perfect design pattern
I am searching tip to upgrade a labview program used. I am looking for the best approach to make
my program more robust and scalable.Software and hardware.
Today the system consists of :
GPS, weather station, ultrasound wind sensor, echosounder and a webcamera, all connected to a computer.
The computer OS is XP pro with Labview version 2009 installed. Except for the webcamera all peripherals have serial communication interface.
The webcamera interface is ethernet.
Device                           Data type                 Interval                    Interface
GPS                                NMEA string                1 second                   Serial rs232
Ultrasound wind sensor   NMEA string                1 second                   Serial rs232
Weather, temp,humid     NMEA string               35 seconds                 Serial rs232
Echosounder                  NMEA string               500ms-5 seconds       Serial rs232
                                                                      (depending of depth)
Webcamera                    Jpg                           Snapshot on demand Ethernet
The tasks to be solved
All the data have to be stored.
All the data have to be displayed in real time.
Weather history data must be buffered to be plotted in a graph (pop-up windows).
Absolute wind speed and direction have to be calculated.
Option to send navigation data attached to email at desired time intervals.
Image snapshot at desired time intervals.
The data wich streams into the serial ports are not synchronized and vary in intervals . Would it be a good idea to put all the serial peripherals into a serial device server. Is it possible to let the server place a event in my software, to trigger reading of the data, from the the server. Or how could that be done in other ways?
The perfect design pattern
In version one of the software I use 4 parallel loops to read data at the serial ports, inside these loops the data was separated and outputted to a datasocket server. I used datasocked read in other loops to present and store data. But it did not look good, and yes it was a mess, a really rat nest. I am looking for a better design pattern.
Could some kind of producer/ consumer pattern be the way to go?
Comments and tips are wanted.
TIK

Nice Project! Congratulations ;-)
I am not an expert for large applications. But your project looks nice and manageable. Here my straightforward ideas:
I would build a GUI, with menu bar, pop-up graph display thing.
THen low level tasks with each one handling a RS232 device and feeding queues or fireing notifications.
Maybe handle the snapshots in an event structure on the GUI blockdiagramm.
When GUI and producer tasks are running, close the gap with a middle layer which captures the data and actualizes GUI by reference. For instance the graph-thing-dialogue triggers a "flush queue" and displays the last 200 entries of the array of data.
I often run into issues when having defined too many userevent structures. I guess i am too stupid for that. Thats why i rather use queues (when i dont want to loose data) or notifiers (data is up-to-date). Nevertheless I like a "stop-all-tasks" user event...traditionally.
My team is actually developing a large application. We are using LabVIEW classes and objects.
So have fun!
Yours
RZM

Choice of design pattern for data acquisition system

Hello all
I have a trouble about selecting the suitable design pattern / architecture for a data acquisition system.
Here is the details of the desired system:
There is data acquisition hardware and I need to use it by observing parameters on User interface.
the data acquisiton period, channel list to scan should be chosen on User interface. Besides, there are many user interface interactions. e.g. if user selects a channel to add scanlist, then I need to enable and make visible some other parts on user interface.
When user completes the channel selection, then he will press the button to start data acquisition. Then I also need to show the scanned values on a graph in real time and log them in txt file.
I know that I cannot use producer consumer pattern here. because the data acquisition loop should wait for parameters to scan channels. and it works in a given period by user. so the user interface loop performs higher rate then consumer loop (data acquisition loop). it means queue will be bigger bigger. if I use notifier it will loss some data come from user interface.
is there any idea about that ? is there any suitable design pattern for this case ?
Thanks in advance
best regards
Veli BAYAR
Embedded Systems Software and Hardware Engineer
"You live in a graphical world. Why not program in one?"
Solved!
Go to Solution.

johnsold wrote:
Veli,
I recommend the Producer/Consumer model with some modifications.
You might need three loops. I cannot tell for sure from your brief description.
The User Interface loop responds to the user inputs for configuration and start/stop of acquisition. The parameters and commands are passed to the Data Acquisition loop via a queue. In this loop is a state machine which has Idle, Configuration, Acquisition, and Shutdown states (and perhaps others). The data is sent to the Processing loop via a different queue. The Processing loop performs any data processing, displays the data to the user, and saves it to file. A notifier can be used to send the Stop or shutdown command from the User Interface loop to the other loops. If the amount of processing is minimal and the file write times are not too long, the Processing loop functions might be able to occur in the Timeout case of the UI loop Event structure. This simplifies things somewhat but is not as flexible when changes need to be made.
I am not sure that a Design Pattern for this exact setup exists but it is basically a combination of the Producer/Consumer (Events) and Producer/Consumer (Data) Design Patterns.
Lynn
Check out this thread: http://forums.ni.com/t5/LabVIEW/Multiple-poll-case-structures-to-event-help/td-p/2551309
There are discussions there about a 3-loop architecture that may help you.
Jeff
Jeffrey Zola

Design Pattern / Best Practice Question

Hi,
I have been using Flex for a while now, but there is a
scenario which I still have not found a solution I'm entirely happy
with. I'm wondering if anyone else out there might have suggestions
on a design pattern or best practice.
Suppose I have a view which depends on model data which
resides in some back end systems. That model data may or may not
have been loaded (e.g. via a web service or remote object call) at
the time the view is displayed.
I don't know if the user will ever visit this part of the
application so I would prefer to defer retrieval of the data until
the user actually navigates to this view. Or I want to retrieve the
data each time the view is displayed because the data is dynamic
and could change between one presentation of the view and the next.
Because the data comes from several systems, I cannot simply
make one service call and display the view when it completes and
all the data is available. I need to call several services which
could complete in any order but I only want to display my view
after I know all of them have completed and all of the model data
is available. Otherwise, I can present the user an incomplete view
(e.g. some combo boxes are empty until the corresponding service
call to get the data completes).
The solution I like best so far is to dispatch a single event
(I am using Cairngorm) handled by a single command which acts as
the caller and responder for all of the services. This command then
remembers which responses it has received and dispatches another
event to navigate to the view once all the results have returned.
If the services being called are used in different
combinations on different screens, this results in proliferation of
events and commands. An event and command for each service and
additional events and commands to bundle the services and the
handling of their responses in the right combinations for each of
the views.
Another approach is to have some helper class listen for all
of the model changes and only display the view when the model
enters some state that is acceptable. It is sometimes difficult to
determine just by looking at the model whether it is in the right
state (e.g. how can I tell that a collection is the new collection
that should just have been requested versus an old one lingering
from a previous call). The logic required can get kind of
convoluted and brittle.
Basically, all of the solutions I've come up with so far seem
less than ideal and a little hackish. I keep thinking there is some
elegant solution out there that I am just missing ... but so far,
no luck finding it. Thoughts?
Thanks.
Bill

i think a service class is right - to coordinate your calls.
i would have 1 event per call (so you could listen to individual
responses if you wanted to).
then i would use a flag. if you want to check for staleness,
you would probably want two objects to map your service flag to
lastRequested and lastCompleted. when you check, check if it's
completed, and if it's not stale and that your lastRequested is
less than lastCompleted (meaning that you're not currently waiting,
i.e. you've returned since making a request). then make the request
and update your lastRequested.
here's a snippet of what i mean.
./paul
public static const SVC1_LOADED:int = 1;
public static const SVC2_LOADED:int = 2;
public static const SVC3_LOADED:int = 4;
public static const SVCALL_LOADED:int = 7;
private var completedFlag:int = 0;
then each call would have it's own callback.
private function onSvc1Complete( evt:Event):void {
completedFlag |= SVC1_LOADED;
lastCompleted[ SVC1_LOADED ] = getTimer();
dispatchEvent( new Event("svc1complete") );
checkDone();
private function checkDone():void{
if( completedFlag == SVCALL_LOADED )
dispatchEvent(new Event( "allLoaded" ));

Is this a good design pattern?

Hi,
I am working with a team to create an application that can acquire data from up to 24 thermcouple channels. We plan to create a wizard to assist the user in setting up the test (specifiying stop conditions, sample rate, channels to sample, output file, and email/text notifications). After the setup, if the user does not cancel out, then the program continues. We have defined parallel loops and their roles, trying to fit into a producer/consumer design pattern. I have attached the main file which shows the structure of the program. We are trying to keep it clean and modular. Before diving into development, we are finalizing a detailed design specification so that different people can work on each of the loops' subvis. I was hoping that people could review the block diagram and offer suggestions for improvement or validate that we have chosen a good method of implementation.
Notes about the block diagram
The plan is for data driven stop conditions to be detected by Event Notifier, handled by the Main UI event, and then the Data Collector is instructed to stop (as well as the Main UI loop). When Data Collector stops, it releases queues, the queue reference becomes invalid, and then the loops with the Dequeue will be stopped.
I am not sure if an additonal event structure should be in the DataCollector to specifically handle the Stop button on the UI because if it is in the Main UI event structure, the DataCollector would not be stopped immediately. This is important to stop quickly because the sample rate could be VERY long. I understand about using an event structure instead of WAIT, but didn't know if there is an efficient way leaving it down in the Main UI event structure....????
Data Collector is the producer, it currently only collects data and passes it on. If the program is going to contain a start collection button, or pause/resume, I need to figure out how to handle this with the Main UI event structure.
Event Notifier consumes data from the Data Collector. It looks at all data and should set a flag if a stop condition is met. The flag will be handled by the Main UI event structure to tell Data Collector to stop. The event notifier also sends a notification to the Email/Text Caller when thresholds have been exceeded warranting a reason for the user to be notified via text or email.
Email/Text Caller waits for notification and then calls a subVI to send an email or text with certain data and channel information. The subVI call is lengthy, so we decided to put this in its own loop instead of a case structure inside the Event Notifier.
Report Generator logs all collected data to a file. A second queue was used, but uses the same data as the first. Is this the correct implementation since two consumers need the same data?
Main UI - handles changing of sample rate, possibly the stop button, possibly start/pause/resume of data collection. Also handles when Event Notifier sets flag for a data driven stop condition, which then should provide a mechanism to stop the Data Collector.
A big question that i have is.... Should the Main UI event structure just be in the Data Collector so that the loop can be stopped immediately? All of the UI events (stop button, start/pause/resume data collection) directly effect the Data Collector. Should the data Collector have a state machine instead?
I feel that the 3 consumer loops (Event notifier, Email/Text Caller, and Report Generator) seem like a good implementation, but i am not confident about the Data Collector and Main UI loops. Should they be combined?
Solved!
Go to Solution.
Attachments:
updatedMain.vi ‏13 KB

A couple of thoughts:
Overall it looks workable- remember to name your queus and notifiers- then you can depop the BD and launch each loop in its own sub-vi without wiring all those queues between loops- Just obtain ref to named queue.
"Data collector" needs a supervisor to control how often the data is collected- I'm thinking a QSM with "init- collect- stop" states. A simple timed loop could produce the "time to acq ticks" under control of the sample rate control. This puts both the DAQ init and cleanup functions within the Data Collector's perview so it aids coehesion and solves the exit without waiting for the loop to iterate.
I'm not a fan of duplicating data- I assume analisys is pretty much just some comparisons- so it is pretty quick- Why not append summary data to the same queue? And make it a single element queue- the report loop can then inspect the queue and look for a summary data "index" - if its greater than the last index written append the darn data to the report? Preview queue works great for these situations.
Do not combine the UI handeler with anything else! Do you see the snag?- hint: here thar be spaghetti. keep the functions seperated for solid scalable and maintainable code.
One last thought: Its getting less popular to stop loops on the error out of a dequeue. First it returns a default element that can cause your listeners some headaches. Second it doesn't let you run cleanup code. Use a stop command <enum> built into the element data as an executive to determine when to stop. We'll try to get the examples updated to show current best practices.
Jeff

Best architecture and design pattern to use

I am currently designing a moderately sized LabView application and cannot decide on the best architecture/design pattern or combinations thereof to implement.
The program basically polls an instrument connected to a serial port continuously at a 2-10Hz rate. When operator clicks a button to start a run, the polled data is then filtered, has math functions performed on the data, writes collected data to files, and produces reltime graphs and calculates point-by-point statistics. At the completion of a run, some additional data files are written. I pretty much know how to accomplish all these tasks.
What is also required is main-vi front panel interaction by the operator to access a database (via a C# dll with .Net) to query for specifications to apply in order to determine pass/fail status. Setup conditions also need to be changed from time to time by the operator and applied to the data in real time (ie- a measurement offset). I have prototyped the database portion successfully thus far.
For the main vi, I started off using the Top Level Application Using Events design pattern (Event structure within a while loop). Copious use of bundled clusters and shift registers keep the database data updated. I cannot figure out how to have the top level vi concurrently poll the serial device as outlined above. The Event structure is only active when defined control values change, and use of a timeout is no help since it prevent data from being collected while the user is accessing the database. All database and setup parameters must be applied to the data as it comes in from the serial port. Error trapping/recovery is a must.
I believe what I need is two parallel processes running under my main vi (one for database and setup, the other for polling and data processing/display, but what would be the preferred choice here?
Revert back to a polled loop in lieu of Events, use notifiers, occurrences, user-defined events, Producer-consumer loops?
It�s been about 3 years since I have had an application on this level (which used a state machine architecture), and a lot has changed in LabView (using 7.1 Prof Devel). I am currently having a mental block while trying to digest a lot of features I have never used before.
Suggestions Welcome!
Thanks.
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~

I suggest a (3) state machine(s) architecture. The first is the user interface. Your main VI is a good start. Another state machine handles the instrument I/O (your serial polling). The third handles all data processing. The three loops run independently. Each has a wait to allow LV's scheduler to share CPU time among the loops. I like queues or functional globals for inter-loop communications.
This allows a lot of flexibility. Each portion can be tested alone. Each can have different timing and priority.
Spend some time thinking about what needs to be done and plan the structure carefully before you do any coding (except for little test programs to try new ideas).
I also like Conway and Watts "A Software Engineering Approach to LabVIEW", published
by Prentice Hall.
Lynn

Design Patterns in Dynamic Programming

Similar Messages

Maybe you are looking for