I have some related interfaces and classes that I want to represent in UML (sorry about the relationships, I don't know how to do it properly with StarUML):
The idea of an interface ISMS implementing IMessage and IStorable, instead of having directly the SMS class implementing itself both interfaces, aims to make the project more modular, maintainable, and easier to test.
Is this a good approach for the design? If so, is this a good way of representing them in an UML Class Diagram or is there a better way to represent an interface and its relationship with other interfaces/classes in UML?
I have a couple of remarks on top of Bruno's already very clear answer.
Your design
The decomposition of the interfaces into IStorable and IMessage seems at first sight to be a sound application of interface segregation principle.
Combining the two interfaces into a reusable ISMS interface instead of directly implementing them in a concrete SMS class will in this regard keep your code more maintainable, since it will easily allow to replace the SMS implementation with an alternative one (which makes sense if you consider that SMS functionality can be platform specific).
The question is however if SMS and email could not be used interchangeably. But only you can answer this question: If your design requires to keep those communication channels distinct (and maybe your real code adds some differences between the two interfaces), it's fine. But if not, it would make sense to allow such interchangeability and replace ISMS and IEmail with a single more general INotification.
Your UML representation
First of all, I'd like to reinforce Bruno's remark about the difference between generalization (plain line) and realization (dotted line).
Maybe I'm old school, but instead of using the circle for the interface, I'd advise for the more conventional interface as with a class box with the keyword «interface» above the name of the interface. Especially if you have properties and operations.
The circle is in my view better suitable for the lollipop notation of an interface. This is very practical when you have no much to say about the interface itself, but want to show what interfaces a class implements (lollipop) or is dependent on (socket). The interfaces details are then defined in another more detailed diagram. You can theoretically merge the two notations in the same diagram, but personally I find it less readable and would not advise it.
Is this a good approach for the design?
I think yes, also because MMS if you add it can also implement ISMS too (may renaming that interface).
For IEmail it is less clear except that simplify Email and other classes working with interfaces to have one interface rather than two
I am pretty sure Christophe will say much more about that :-)
is this a good way of representing them in an UML Class Diagram or is there a better way to represent an interface and its relationship with other interfaces/classes in UML?
the relation to indicate a class implements an interface is a realization (drawn with dotted line), you used a generalization, so also adding MMS :
... ISMS implementing IMessage and IStorable
warning this is not an implementation because ISMS is an interface, same for IEmail, this is why between interfaces the inheritance is supported by a generalization rather than a realization.
Related
I'm an university student and I'm trying to do a class diagramm for a very simple client-server game.
The game consist of a online rouge-like when 2 player explore a dungeon. I'm having trouble to identify an easy class diagramm. Should I show in the class diagramm the server class and the client class? What other classes should I add?
Here is what I’ve done so far:
It is recommended to keep class diagrams small and focused on a given topic. This is true for simple games, as it is for complex systems. This leads to have several diagrams that are easy to read rather than one big and extremely complex diagram with all possible classes of your system. It would therefore seem better to keep client and server classes separate in different diagrams.
In the special case of a client-server system, the client and the server might moreover have different designs targetting different technologies. This is one reason more to keep them separate, unless you intend to reuse the same design on both sides, for example if you intend to have a common code base with a rich client.
However, it could be very helpful to you, to use a component diagram, at a higher level than individual classes. Component diagrams allow to focus on the interfaces between the parts of your system and will allow to explain the big picture (e.g. that there is a client and a server and how they are interfaced) before diving into the details.
I have some related interfaces and classes that I want to represent in UML (sorry about the relationships, I don't know how to do it properly with StarUML):
The idea of an interface ISMS implementing IMessage and IStorable, instead of having directly the SMS class implementing itself both interfaces, aims to make the project more modular, maintainable, and easier to test.
Is this a good approach for the design? If so, is this a good way of representing them in an UML Class Diagram or is there a better way to represent an interface and its relationship with other interfaces/classes in UML?
I have a couple of remarks on top of Bruno's already very clear answer.
Your design
The decomposition of the interfaces into IStorable and IMessage seems at first sight to be a sound application of interface segregation principle.
Combining the two interfaces into a reusable ISMS interface instead of directly implementing them in a concrete SMS class will in this regard keep your code more maintainable, since it will easily allow to replace the SMS implementation with an alternative one (which makes sense if you consider that SMS functionality can be platform specific).
The question is however if SMS and email could not be used interchangeably. But only you can answer this question: If your design requires to keep those communication channels distinct (and maybe your real code adds some differences between the two interfaces), it's fine. But if not, it would make sense to allow such interchangeability and replace ISMS and IEmail with a single more general INotification.
Your UML representation
First of all, I'd like to reinforce Bruno's remark about the difference between generalization (plain line) and realization (dotted line).
Maybe I'm old school, but instead of using the circle for the interface, I'd advise for the more conventional interface as with a class box with the keyword «interface» above the name of the interface. Especially if you have properties and operations.
The circle is in my view better suitable for the lollipop notation of an interface. This is very practical when you have no much to say about the interface itself, but want to show what interfaces a class implements (lollipop) or is dependent on (socket). The interfaces details are then defined in another more detailed diagram. You can theoretically merge the two notations in the same diagram, but personally I find it less readable and would not advise it.
Is this a good approach for the design?
I think yes, also because MMS if you add it can also implement ISMS too (may renaming that interface).
For IEmail it is less clear except that simplify Email and other classes working with interfaces to have one interface rather than two
I am pretty sure Christophe will say much more about that :-)
is this a good way of representing them in an UML Class Diagram or is there a better way to represent an interface and its relationship with other interfaces/classes in UML?
the relation to indicate a class implements an interface is a realization (drawn with dotted line), you used a generalization, so also adding MMS :
... ISMS implementing IMessage and IStorable
warning this is not an implementation because ISMS is an interface, same for IEmail, this is why between interfaces the inheritance is supported by a generalization rather than a realization.
I need to develop a system for a library system from Java & Netbeans. I am wondering do I have to include classes made from Netbeans for user interfaces in the class diagram. In addition to that suppose we have a class "Librarian". I assume that I can create two classes one for UI and one that including details in the class diagram and use it in the UI class. Or I can implement, what class diagram says directly in the UI class for "Librarian". Please tell me which is the correct way that software engineers are supposed do.
Whether or not to show something in a class diagram depends on the intention of the editor and what he wants to show to his audience. Often it's a good idea to create overview diagrams where you omit details. The overview is then accompanied by a couple of detail diagrams which are logically oriented at sub-domains which in turn help to understand the systems as a whole.
Also it's not uncommon to just leave out "obvious" things. If you work with known scaffolds in certain domains you must not describe that again and agin but just can assume that it's known. In your case that would be the GUI part which will be known implicitly. You might consider to create a sketch of the scaffold somewhere in a more general class diagram. This could be helpful for people coming from other worlds (and not knowing NetBeans like me).
Beware of drawing wall-papers that contain each and every detail in a single class diagram. Looks impressive but is absolutely useless (an anti-pattern if you like to call it that way).
I'm in the process of creating a hangman game for Android, but I'm unsure about some parts of the class diagram. I have an Alphabet Interface With Methods for resetting, check if a letter is guessed, and marking it as guessed if it is not previously guessed.
The app will support both the Norwegian and English alphabet which means the the implementation of Methods will differ some.
In the class diagram, is it fine to leave the classes implementing the Interface empty or should I never do it this way unless they add New functionality?
being part of
Generally speaking your class diagram should contain as much detail as is needed to get the full picture without including every little detail. Someone unfamiliar with your project should be able to take it and implement it without asking too many questions.
If you have classes who's only purpose is to be a union of interfaces, those should be included in the diagram if they should be instantiated, even if they are empty. But generally they would not be empty..they would at least have a few members to keep track of things.
I have a project and I'm required to produce the class and sequence diagram. It is a procurement website. My only problem is that I don't know how to associate the web pages (user interfaces) to these diagrams. If they are not needed what is the right way for me to include it in the diagrams because from a book I read there are "UserInterface" classes, so another question, what should be inside of these UI classes.Can someone give me an example. Thanks!
There are several levels of abstraction for UI modelling.
Use cases and state machines. These diagrams are made in human terms.
Planning on the server/page/frame level. Here UML deployment and component diagrams are useful.
Planning of the content of UI, defining elements and functonalities and connections between them WITHOUT choosing the concrete components. No standard for this, extremely important, stage. Use diagrams that you like. Class ones are usable, but in not standard reading.
Planning of the content of screen elements WITH choice of the UI components (frames, buttons and so on) and connecting functionalities to them. On this level you can use class and sequence diagrams.
Drawings of the planned screenshots. For this level there are no UML diagrams. And a common standard doesn't exist.
These levels require MANY diagrams. The lower the level, the more diagrams it needs. Putting user interfacES into one class diagram is possible for a minuscule project, but you can't say it SHOULD be done so.
In your class diagram you will normally describe/design the (data) model part of your application, while the user interface (UI) corresponds to the view part within a model-view-controller (MVC) architecture. As a UI cannot be designed with a class diagram, I cannot see any meaning for a "UserInterface" class.
However, there is a new modeling language for modeling user interfaces: the Interaction Flow Modeling Language (IFML), which has been adopted as a standard by the OMG in March 2013. If you are serious about UI modeling, then you should use that language.
Classes of UI can be modeled as ordinary UML classes. You can create stereotype "webpage" if you want of course. If it is needed to define internal structure of UI class use composition. In sequence diagram you can define interaction between instances of UI classes in common way.
Example: