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 creating a project documentation for a Question management and generating system and need to draw class diagrams from that system.
My question:
I have a lot of dialogues and frames since I'm programming in Java. Should I include the GUIs with the diagram and relate them to other control classes?
I want to question and/or perhaps challenge the school of thought on UML behavioral diagrams.
Firstly, I want to ask, what comes first: Use Case or Activity?
I was taught that Use Case diagrams come first and then for each Use Case, you have one or more Activity diagrams to represent successful and alternate flows. From the Activity diagrams, you can identify nouns to establish classes.
I have, however, read other articles which say you create an Activity diagram for the end to end process and then from that, you can identify Use Cases.
I can see both scenarios working, and am confused, as to me it seems a case of hierarchy. For example, say I have a high level business process which is 'Grading Student Results'. If I map it as an Activity diagram, within which I would see swim-lanes. I would be able to pick out Use Cases, such as 'Determine Grade Boundaries,' 'Submit Results,' 'Convert Result to Grade,' and so on.
You could argue they are the same thing, i.e. both diagrams would meet this process modeling need. I then want to model the next level, for example, how you 'Submit Results.'
Can someone advise on the best practice: whether a Use Case diagram comes before or after an Activity diagram?
First:
There is no competition between any of the UML diagrams to be the "first
one". Sometimes it is better to work on some diagrams simultaneously and iteratively.
Second:
Each diagram can be used in different contexts and for different purposes.
Use Case Diagram vs. Activity Diagram
"Use Cases" are scenarios which show how the user will use the system to achieve their goals.
So:
Instead of showing this "scenario" with written use cases, you
can visualize its' steps with an activity diagram.
But in order to find use cases, you should discover the system requirements to some degree, (e.g. the scope, broad feature set, priority, cost, etc.).
In some business domains, such as for an automation project, in order to discover requirements/use cases, you may have to investigate current business flow. Sometimes this business flow can be complex, so you may want to investigate it with an activity diagram.
So:
An activity diagram can be used to investigate a business process to
understand and discover the flow, to better discover requirements.
So:
An Activity Diagram can be used at different levels of software
development stages for different purposes.
Just like other diagrams, you can use the Activity Diagram at any time, anywhere, as soon as it can help you to ask the right question, to understand and explore any issue related to your purpose.
Here is a summary purpose of Activity Diagrams:
The purpose of the activity diagram is to model the procedural flow of
actions that are part of a larger activity. In projects in which use
cases are present, activity diagrams can model a specific use case at
a more detailed level. However, activity diagrams can be used
independently of use cases for modeling a business-level function,
such as buying a concert ticket or registering for a college class.
Activity diagrams can also be used to model system-level functions,
such as how a ticket reservation data-mart populates a corporate
sales system's data warehouse.
UML Basics : The activity diagram by by Donald Bell
To get a quick grasp of which diagrams can be used for which purposes, I advise you to check out Scott W. Ambler's mini book: The Elements of UML(TM) 2.0 Style
Activity diagram is one of the those with widest abstraction range in UML. An activity can be used for anything between a business process (very abstract, comparing with software system) and a single method algorithm (code-level, practically blue-print, meaning kind of abstraction ground level).
Use Cases on the other side are in practice very limited in their abstraction. They show the interaction between a user and the system and would be somewhere in the middle of the abstraction scale. Not as abstract as a business process, and definitelly a lot more abstract than the implementation diagram.
Software projects tend to start working on a very abstract level (business goal for example) and finish with the abstracion 0 (implemented system). During the project analysts, architects and developers work together to gradually lower this abstraction producing always less abstract artifacts/models - business processes, use cases, architecture, design, code.
After this introduction it is not hard to answer your question - any of those can be used first and that depends on type of your project and its size. SOme examples:
A large project of development an ERP system. It is almost certain that in this kind of project the first thing to model is the business process. A long before even thinking of its functionality, the team must understand the business background. The best UML diagram for this is naturally the activity diagram. Some time after, when the process is clear and the high-level reqs known, the use case modelling can start.
A middle sized of relativelly small project, with no complex processes in background (for example a mobile app development) can start directly with use cases, identifying the users and their features. Later on, these can be further refined using activities.
A very small development of some interface, driver of communication gateway, highely technical, where even the user interaction is minimal, the modelling can start with the activities again, showing the concrete algorithm too be implemented. USe cases can be completelly skipped.
As a summary I would conclude that there are no unbreakable rules of this kind in software development. Each project is unique, each development methodology is unique, even each development team is special and unique. To think about "which diagram" to do first is straight and simply WRONG! Think about what kind of analysis or specification you need in a given moment - what is easiest and most usefull to be modelled. When this is clear - there are 13 UML diagrams to pick up from in order to optimally fulfill the aim.
Choice of UML diagram is the "HOW". More important than that is more often than not - the the "WHAT".
Use case diagram is for showing the functionalities and Activity diagram is for showing operations(1 functionality can have many operations).
eg. Use case diag. is Moher (can have many childrens) and
Activity diag. is like describing the child of Mother i.e. Use Case diag.