I have a couple modules. They communicate to each other through events.
What UML diagram would typically be used to show this?
Is there a non uml diagram people use?
Any examples?
I think you definitely want a sequence diagram to show all the event interaction between modules in sequence. This is the preferred way to represent sequence of asynchronous messages between components
If you want to express the fact that a module A fires an event E that is handled by module B, I suggest a static diagram to show the structure of your architecture.
In particular, I would use a class diagram where I could draw:
the modules A and B (classes with a stereotype)
the event E (i.e. still a class with the stereotype event)
an association named subscribe between B and E
an association named publish between A and E.
In general you want to use a "behavioral" diagram(s). There are multiple flavors. Which one you choose depends on the intent of what a given diagram wants to convey.
http://www.visual-paradigm.com/product/vpuml/provides/behavioralmodeling.jsp
Related
First, context:
We're developing some applications using QP Framework from quantum leaps.
QP is basically an event manager for state machines.
Our approach:
Since we're using QP, our modules interact with events and signals (classes/structs and enums) except some very specific modules that interact by methods.
Problem:
For those last modules, interfaces are easy, just a collection of all the public methods in said module, however, how about the others? Can we say an interface is a composition of other classes and enumerations?
Since the modules interact by sending/receiving events, both should know what kind of data packets (events) can travel through that interface.
Can we represent an interface like this? or should an interface only be a collection of methods?
edit 1:
Replying to the comments below, I don't want to say the interface had nested classes, but that the interface would define said classes so they could be used as events, but from your answers, seems using signals would be a better approach. (The ADC:: prefix and the name of the interface are not the same, just some bad naming choices, as the package name was ADC and so was the interface)
edit 2:
From the comments and answers below, I had no knowledge of the signal stereotype, so updating the question, I think it would become something like this?
This solves the classes and signals problem, however, the enum remain...
My intention was to say the interface would define this keywords, i.e. the module that implements the interface, should define this enum and their values.
Is this the correct approach?
The interface in your diagram is perfectly legit. UML interfaces do not have the constraints of Java interfaces: they can have operations, attributes, and all kind of associations (btw, the aggregation does formally not add any semantics to associations, and you could safely consider to remove the white diamonds), including composition (black diamond).
However it might not represent what you are looking for: interfaces express a contract. It means that the classes implementing it must provide those attributes and associations, and not that the classes will get all these features by a kind of “inheritance”.
Moreover, I’m not sure if you try to express some complex interface, or just found no better way to represent event consumption/generation. In the latter cse it would be an overcomplex and misleading approach.
For event based design, you may be interested in using signals. Signals are like classes, but there are UML elements to express the ability to process a family of events, and/or to generate events. It moreover facilitates the link between sequence diagrams and class diagrams, as a message can correspond directly to an event instance.
The model per se is legit. However, it's likely not what you intended. The shared aggregation has no defined meaning. See p. 110 of UML 2.5
shared | Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
So unless you define the meaning of them the model has no defined meaning.
If you intend to inherit operations/attributes you would draw an open triangle arrow towards other classes. Enumerations should simply be an attribute (simple association with role).
P.S. As per Geert's comment I notice the nesting too. So you obviously over-define this by adding the (meaningless) shared aggregation. You could represent the nested classes by showing them inside the enlarged «interface». Or you use (as suggested by Geert) the nesting relation (personally I use that rarely, but it's an alternative).
I'm using IBM Rational Rose, but I'm not sure if I'm able to model/design the methods/procedures which are known as "operations" within a class onto "UML User Class Diagram". Is there any way to model the algorithm or the code of 'operations' (i.e something like flowchart) via the software? If so, is there any possibility to get the methods design auto-implementation integrated via code generation in order to define them within a java source file?
Another way to model behavior is to use StateMachine, Constraints, Sequence and Timing diagrams. Of course, you can simply write Notes describing behavior in plain words.
You can use activity diagram, activity diagrams are near a flow chart.
See rsa activity diagram
On your activity diagram, you create a partition and you can link your partition to you operation. Then you create callOperation action which can be linked to method call.
I create a class diagram with 4 class Class1, Class2, Class3, Class4, each one containing a method operationx.
And here is a simple example modeling operation1. The important point is that the partition named Operation1 is linked in the UML model to Class1:operation1 and the 3 actions are linked to method operations. This is not a "typo" tips.
You can look also to sequences diargam but it does not look like a flow chart.
i am currently working on a project and need to create some uml diagram properly in order to put them in my final report.
so i'm wondering if i should put the GUI classes in the diagram ? in that case, there would be a lot of informations and i fear this would make it harder to read it !
in addition to that, as i'm using observers in my program, how can i proceed to add the Event classes that i used ? i found a similar question here :
Typical uml diagram for showing events
and i dont know if it is the right way or not !
Thank you for your answers
Class Diagram are typically used to show interaction between classes with relationship (Cardinality). It is bit like ER Diagram. For your case, If you want to show control flow between different classes with event in time ordering manner then it is better to use Sequence Diagram and if you want to show the relationship between different class with participation of one's object on another object then uses Class Diagram. Both diagram will certainly add some standard on your final report.
I had used Argo UML (free and open source software) to create those diagram. But various other tool like Rational Rose, violet or visual Studio-2010... are also available.
i'm wondering if there is a pattern how to separate the domain logic of a class from the ui responsibilities of the objects in the domain layer.
Example:
// Domain classes
interface MachinePart
{
CalculateX(in, out)
// Where do we put these:
// Draw(Screen) ??
// ShowProperties(View) ??
// ...
}
class Assembly : MachinePart
{
CalculateX(in, out)
subParts
}
class Pipe : MachinePart
{
CalculateX(in, out)
length, diamater...
}
There is an application that calculates the value X for machines assembled from many machine parts. The assembly is loaded from a file representation and is designed as a composite. Each concrete part class stores some data to implement the CalculateX(in,out) method to simulate behaviour of the whole assembly. The application runs well but without GUI. To increase the usability a GUi should be developed on top of the existing implementation (changes to the existing code are allowed). The GUI should show a schematic graphical representation of the assembly and provide part specific dialogs to edit several parameters.
To achieve these goals the application needs new functionality for each machine part to draw a schematic representation on the screen, show a property dialog and other things not related to the domain of machine simulation. I can think of some different solutions to implement a Draw(Screen) functionality for each part but i am not happy with each of them.
First i could add a Draw(Screen) method to the MachinePart interface but this would mix-up domain code with ui code and i had to add a lot of functionality to each machine part class what makes my domain model hard to read and hard to understand.
Another "simple" solution is to make all parts visitable and implement ui code in visitors but Visitor does not belong to my favorite patterns.
I could derive UI variants from each machine part class to add the UI implementation there but i had to check if each part class is suited for inheritance and had to be careful on changes to the base classes.
My currently favorite design is to create a parallel composite hierarchy where each component stores data to define a machine part, has implementation for UI methods and a factory method which creates instances of the corresponding domain classes, so that i can "convert" a UI assembly to a domain assembly. But there are problems to go back from the created domain hierarchy to the UI hierarchy for showing calculation results in the drawing for example (imagine some parts store some values during the calculation i want to show in the schematic representation after the simluation).
Maybe there are some proven patterns for such problems?
Agree with #Marjin, and to generalise his answer. What you need is Model-View-Controller of which MVP and MVVM are variants. From your comments I think you understand that, but need to understand how to implement the pattern. Without knowing your language & target architecture it's hard to give absolute specifics. Notwithstanding, I'd start with the Observer pattern (link has sample code).
The problem you're dealing with is how to provide observable access from the domain to the UI - without encumbering the domain with UI-specific code. Observer provides a means to do that. It does require domain changes, in particular to enable registration of observers and notification of changes. However there's nothing GUI-specific in that so it stays well encapsulated.
hth.
PS: If your app is a typical thin-client web app you'll need to modify the approach. And beware: lots of web app frameworks are advertised as "MVC", but the implementation is architecturally quite different to the Observer pattern.
You can take a look at the model-view-presenter (mvp) and model-view-viewmodel (mvvm) patterns.
Fowler's presentation model includes two sample applications; it also might be of interest to you.
I think that investigating these patterns will give you some ideas on how to continue. Mvvm looks a lot like your current solution; so i'd start there if I were you.
Maybe a View Helper can help. It's not a C++, but a Java EE pattern, but in your case it will definitely separate your domain objects from their presentation details...
I have another programmer who I'm trying to explain why it is that a UI component should not also be a data-structure.
For instance say that you get a data-structure that contains a record-set from the "database", and you wish to display that record-set in a UI component within your application.
According to this programmer (who will remain nameless, he's young and I'm teaching him...), we should subclass the data-structure into a class that will draw the UI component within our application!!!!!!
And thus according to this logic, the record-set should manage the drawing of the UI.
******Head Desk*****
I know that asking a record-set to draw itself is wrong, because, if you wish to render the same data-structure on more than one type of component on your UI, you are going to have a real mess on your hands; you'll need to extend yet another class for each and every UI component that you render from the base-class of your record-set;
I am well aware of the "cleanliness" of the of the MVC pattern (and by that what I really mean is you don't confuse your data (the Model) with your UI (the view) or the actions that take place on the data (the Controller more or less...okay not really the API should really handle that...and the Controller should just make as few calls to it as it can, telling it which view to render)) But it's certainly alot cleaner than using data-structures to render UI components!
Is there any other advice I could send his way other than the example above? I understand that when you first learn OOP you go through "a stage" where you where just want to extend everything.
Followed by a stage when you think that Design Patterns are the solution every single problem...which isn't entirely correct either...thanks Jeff.
Is there a way that I can gently nudge this kid in the right direction? Do you have any more examples that might help explain my point to him?
Have you heard of Martin Fowler?
Separating User Interface
Code
Anyway, if he wants to go further in that direction of adding render methods to his data controls, have him look at "loose coupling". It's okay to create some generic type of interface that gets him halfway there, but the UI component should take it the rest of the way.
This boils down to functional vs. non-functional responsibilities. What the data structure does and how it's visualized are two completely separate things -- essentially the root of the MVC pattern.
There's also a notion of circular dependencies here. Since the UI must know about the data structures, if you allow the data structures to then depend on the UI, you've got yourself a nice little ball of mud.
Generally on the point of decoupling:
Not only can there be different components of the UI rendering the same data structure. You may even have completely different UIs (Web, Desktop Application, ...) Now of course, you could subclass Person with WebPerson and DesktopPerson (this already sounds wrong, doesn't it? The naming is simply not about the kind of Person - it's about something else).
Each UI could work on different kinds of Persons, e.g. Teacher and Student. So we get WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher and DesktopStudent.
Now let's say, WebPerson defines the method "drawAddressFields()" to draw a web version of the address fields. But since WebTeacher has to derive from Teacher to use the additional data field "salary" (and let's assume single inheritance), it must implement "drawAddressFields()" once again!
So maybe the argument of "this will cause much more work" will help to create some motivation :-)
BTW, it will automatically lead to creating some delegate that implements the code of drawAddressField(), which will then evolve to creating a component that does the drawing separately from the data structure.