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).
Related
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 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'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:
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.