I don't think I've seen this comparison anywhere, but would they be considered the same? If not, why not?
They are very similar, but there is a little difference:
signals/slots implement the observer pattern, where the producer has a reference to its subscribers and is responsible of notifying them
the publish/subscribe paradigm inserts an additional mediator, i.e., the topic handler, which decouples producers and consumers (the producers does not know who will consume messages)
A main consequence is that in the p/s paradigm you can have multiple producers on the same topic.
This is (probably) the most cited article about p/s:
The many faces of publish/subscribe
publish subscribe is same as the signals and slots...
check this...
http://en.wikipedia.org/wiki/Observer_pattern
http://doc.qt.nokia.com/qtmobility/publish-subscribe.html
Related
Does UML define how asynchronous communication patterns (observable, message bus, etc) should be shown when showing the interaction of various components in a system? I do know that sequence diagrams have the ability to show asynchronous calls however these do not show any information about the method of communication (for example, details on the event bus or the subscription to/disposing of an observable may be important to document). Is there a standard way of capturing these types of details?
Actually what you are asking is to go in more detail with a message. If for example you send data over a socket to another process you just call a system library's send method. This in turn will do lots of things (down to switching lots of transistors in lots of hubs and switches) until the opposite process gets control. Usually nobody is interested in these details. That's what we call abstraction.
However, if for any reason you are interested in some partial details of the message transport wihout going into the gory details you can simply stick a note to the message. Another way is to use a stereotype like this:
Please note that the sketch above shows a synchronous call, despite the question title. Use the open arrow variant for async calls.
I am not familar with WINAPI, and I am looking for a way to replace WaitForMultipleObjects used in one example I'm porting to Qt by anything using Qt only. Is it possible?
EDIT: (Providing more information as requested in comments)
A 3rd party API provides an array of events:
HANDLE m_hEv[MAX_EV];
In an endles-loop of a thread, the program waits for the events like this:
WaitForMultipleObjects(m_EvMax, m_hEv, FALSE ,INFINITE )
The HANDLE type seems to be void*.
So I wonder, if any Qt class could observe m_hEv for changes and unlock thread execution.
There is no simple way of porting WaitForMultipleObjects outside WinAPI. WinAPI has an "advantage" of that all lockable resources (sockets, files, processes) provide the same generic non-typesafe HANDLE, which is your void*. Unlike other platforms which have different ways of locking and signalling per the type of resource, the event handling in WinAPI is largely independent of the resources. Then a generic function like WaitForMultipleObjects can exist, which doesn't need to care who produced the HANDLEs. So you'll have to understand what the code is trying to do and mimic it differently per scenario.
The biggest difference is in WaitForMultipleObjects third parameter, which is FALSE in your case. Which means that the it will exit waiting as soon as any single event of the waiting array will happen. That is the easier scenario and can be replaced with a QWaitCondition.
Instead of m_hEv, you will pass a QWaitCondition* into the code which signals the event (most probably via WinAPI SetEvent(m_hEv[x]))
Instead of WaitForMultipleObjects, do QWaitCondition::wait().
Instead of SetEvent(), do QWaitCondition::wakeOne().
Would the third parameter be TRUE, then the WinAPI code waits until ALL m_hEv events are signalled. The established name for such functionality is a synchronization barrier and it can be simulated with QEventCondition too, but does not come out of the Qt box. I never needed to do any myself, but SO has some ideas how to do it:
Qt synchronization barrier?
WaitForMultipleObjects is a kind of generic function that works with many things: threads, processes, mutexes, etc. Qt is an OOP library where every class exposes the operations it supports. So the equivalent operation in Qt depends on what class you're using. For example, with threads, use QThread::wait. With mutexes, use QMutex::lock.
I'm looking for suggestions regarding implementing process flow / work flow management in a PureMVC based application.
Our Flex application includes a number of processes such as account creation, payment processing, etc.
Within our team, there is some discussion of how rigidly we should adhere to the PureMVC model.
Within the PureMVC model, it seems reasonable that the current state in the process could be managed in a Proxy.
Commands are clearly responsible for processing the actions required of each node and for node transitions.
Mediators for managing the UI.
However, I think that there is an important bit still missing here: a ProcessController.
The approaches we've reviewed all seem to either violate the PureMVC model (even just slightly) or make unreadable code.
A proxy would maintain the state of the process. As such, it seems to be an appropriate way to implement the controller. However, this is putting a lot of business logic into the proxy.
The Mediator space makes more sense, but the controller in that space would not necessarily directly interact with any particular UI element but would instead coordinate/delegate to dedicated Mediators.
Yet another model would have us put process transition information into Commands. While this seems to be the best place for that work (given the role of commands relative to proxies and mediators), this approach looks to make some particularly heinous looking code with process transition logic distributed among scores of commands.
So how have others handled this problem?
Thank
Curtis
This is exactly the problem that PureMVC StateMachine Utility (and Finite State Machines in general) are meant to solve.
In a simple XML format, you can define states, valid transitions to other states, and the actions that trigger those transitions.
It is all notification-based, so you send StateMachine.ACTION notifications that cause the StateMachine to execute any entering/exiting guard logic that may be necessary (e.g., only allow exiting the FORM_ENTRY state if all the data valid, or only allow entry into the FORM_PROCESSING state if the user has admin rights, etc.). If a state change occurs, notifications are sent that can be used to organize the view or execute logic upon entering the new state.
Here is a StateMachine Overview presentation that will give you a better idea
http://puremvc.tv/#P003/
I think your idea of 'ProcessController' is probably the better way of doing it. Personally, I'm not a fan of PureMVC and don't use it because it doesn't allow enough flexibility or extension points to help with such problems.
Frankly, it's hard to advise on your issue because I don't know exactly what you're trying to accomplish. I do agree that the concern needs to be handled by one object. If you can, try to create a model that can store the data for the process and have another class just manage it throughout. Not sure if that makes sense, but then again, your problem isn't very clear either.
As an added extra, I would look into Dependency Injection. I'm trying to remember if PureMVC does it (I don't think it does), but with DI it would of been a fairly simple problem to solve. Frameworks like Parsley and Robotlegs are really good at that.
In pureMVC the State Machine Utility is probably the best choice for a process controller - and btw, according to the Implementation Idioms & best Practices doc. for PureMVC, it's perfectly fine to have mediators that don't manage a visible component
I am using Weld to observe events. I thought there was a way to specify if the observer was asynchronous or not, but I am not finding that annotation or documentation.
Can observers be asynchronous, if so, what do I need to do to make that happen?
There is an open request for this: CDI-31: Asynchronous events.
Depending on your requirements, you can, as indicated in your comment, set a different transactional observer: If you use AFTER_COMPLETION or AFTER_SUCCESS, it should seem to your application like an asynchronous execution. However until a framework solves , I have just found an example using JMS for asynchronous execution in CDI.
Take a look at post on Piotr Nowicki's blog http://piotrnowicki.com/2013/05/asynchronous-cdi-events/
He described a couple of methods for achieving asynchronous behavior of CDI events.
If you guys want to see this happen, you'll need to head over the the link provided in Kariem's answer and voice your opinion. It seems the expert group is unwilling to consider adding async events because they consider it bloating the spec.
Honestly, Guice manages to offer this feature, and it remains lightweight, so I find the argument against this little counter-intuitive. Nevertheless, if you want to see this feature, head to the link, voice your opinion.
-Jonathan
Is it any uml-like modeling tool available that can design (draw) classes and can visually represent QT signals and slots, they connections?
The signal/slog mechanism is essentially a mechanism for registering callbacks. So your question could be paraphrased as: "How do I model callbacks in UML". I'm not sure if there is a good answer since callbacks are not really an object oriented construction. Conceptually the observer pattern would be closest.
You can try Enterprise Architect as it supports UML 2.1 and allow to create user defined diagrams.
These connections are dynamic, so I'm not sure it's even possible to represent them in a static way (as in a diagram).
Also, most often, they are tightly bound in time and code (i.e. you create two objects and then connect them). From the code, it should be pretty obvious what happens and why, making any extra documentation dangerous (since the best it could do was to document the current state and it would always be in danger to be out of date unless it was generated from the source, or rather from data gathered during the runtime of the application).