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.
Related
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 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
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...
So thanks to the Visualization and Modeling Feature Pack , I can build a uml model diagram and generate a bunch of classes.
But what now? Presumably, my developers will add code to those classes. Useful code, valuable code, and as the templates themselves indicate:
// Changes to this file will be lost if the code is regenerated.
So what is the best solution here? Can I make the modeling project reflect changes to the actual classes? Should I generate partial classes? Modify the default templates to read class files and not auto-generate anything that has been modified? Should I tell developers not to edit model files under pain of....well, pain?
Thanks for the tips.
As far as I know, this is really the key reason for partial classes in the first place. The custom code goes in one file, the auto-generated in another.
You could also create classes derived from the generated ones, and put any changes in there. I also agree with above poster that partial classes could be the way to go.
Although the tools generate basic skeleton classes out of the box, that's really just a starting point. You can easily adapt the generator templates to create your own stuff. Different people want to generate different code from the classes - some even generate XML or SQL. And yep, in C#, partial classes are good to generate, so's to keep the hand-written code separate from the generated bits.
It's good to put lots of extension points in the generated code, where you fill in the details by hand code.
Another neat idea is "double derived": from each UML class, generate a base class and a derived class. The derived one has only constructors. The base class has any methods you generate. So your hand code can easily override generated methods where you need that.
There are several options in the tool and recommending what is best is hard without knowing your scenario. Partial classes are great for some, but not all applications. If you want your UML class to generate a partial class, you can set it's C# stereotype's property to "Partial" and it will do so, and custom code can then be added in a partial class that won't be overwritten. If you want to prevent code from being overwritten, you can do this by setting the overwrite property to False on the template binding that corresponds to the package you are working on. This lets you set your extension code to be in a package that is not overwritten, while your model mastered code is overwritten with the latest model changes. Finally, if you want your code to be the master for your model so it always reflects the latest code, then you can reverse engineer your code by using the architecture explorer to select your classes and then dragging them in to a UML diagram. So for a given gesture, either the model is the master or the code is the master. In this version, we did not implement automated merge capabilities between the two.
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.