I am designing a UML for my JAVA program class. It has 50+ attributes and 50+ properties. I have to include the UML in my report in word document. Is there any problem if the diagram gets split into multiple pages?
20+ properties have getters and setters, so it is necessary to include them?
And there are few other classes with which I have to show the relationship, the relationship diagram will be on another page, so on relationship UML do I have to list all the attributes again ? or I can just include the class name in the rectangle?
If your diagram contains only one class, what's the point of it. Maybe it's better to put just a textual class description?
On the other hand a single diagram spread across few pages isn't really readable anymore.
UML specification explicitly says that you place on your diagram only what is needed and useful in a specific context. You may put just a class name on other diagrams and that's fine.
Other option is to depict your class with properties and operations important from the perspective of specific interactions. You can show that the list is incomplete by placing an ellipsis after the last feature in each section.
If I had a case like you I would very carefully examine my design looking for flaws in it. A class with that many features can hardly ever be justified.
Related
Simple question for a simple-minded person such as myself. I am quite new to programming and I have commenced working with UML diagrams for my class. Question: Are the member variables provided the in the UML diagram fixed? Am I warranted to add my own variables, or must I strictly adhere to the UML that is given for any assignment regardless of whether or not it is stated?
thanks :)
This depends on the purpose the diagram is supposed to serve. Usually UML class diagrams, as other types of diagrams, are created in order to communicate certain aspects of a software to other people. Then class diagrams just contain the elements (classes, member variables, methods, ...) that are required for the target audience to be able to understand these aspects.
For example, let's assume there is some kind of third-party software library you want to use. In this case you probably want to know how the interface offered by the library looks like, so you can make use of it in your own application. You are only interested in information regarding the library interface though, you do not care about its inner structure. Therefore, a class diagram that just shows all classes, methods, ..., that are visible from the outside would be sufficient for this use case and nobody would expect you to just use the depicted library classes in your implementation.
However, there are some other scenarios in which the goal of a diagram might be different. For example in the area of automated code generation, a given UML class diagram would be expected to contain all classes, methods etc. that are suppsoed to be transformed to code. Here it does not make sense to omit information, because the corresponding code snippets would not appear in the generated code subsequently.
As you can see, there is not only one single use case for UML diagrams and thus their interpretation always depends on the given context.
I hope this helps!
I have a class diagram like it is shown in the picture.
There is a Controller that has some TopicLoaderIF and several TopicReaderIF classes. The TopicLoaderIF creates a series of TopicIF upon request from the Controller. Then the Controller forwards these TopicIF to the correct TopicReaderIF. Let's not enter in weather these model is correct or not but in the relationship between them.
The thing is that I have been trying to model this as an UML class diagram but I am stuck thinking on the kind of relation between the Controller and the TopicIF (in red), if there should be any in the diagram. Further more, I am also not sure if it is correct that all three, the TopicLoaderIF, the Controller and the TopicReaderIF, have a direct associations to TopicIF. Should they be just a normal association, without the arrow?
I would appreciate any advice you may give me regarding this diagram.
Navigability expresses A can see B if there's an arrow from A to B. In a rough sketch these arrows can be helpful, but are not mandatory. If the arrow is not present, both classes could see each other, but must not. When implementing such an unspecified association you will judge at the needs and only implement needed references (if B has no need to see A you would not implement a reference).
Once you are going into detailed design, you will start using role names towards the ends. This makes perfectly clear how navigation will work.
TL;DR When sketching, use arrows. Once starting with details, replace them with role names.
I going to start a new application for that am designing class diagrams...
In my application I am planning to implement log4j for logging and audit4j for audit.
Now i am having a doubt, Is it necessary to add logging and audit functionality in UML(Class Diagram) because each class using both of them and it is default understandable. If I add them my UML looks so clumsy and unclear..
Is it advisable to remove logging and audit from UML. Will it cause any drawbacks while construction...
Thanks in Advance...
Class diagrams and other UML diagrams serve the purpose of clarifying the interdependencies and interactions between the modules and classes. As you mentioned, adding unnecessary details which are cross cutting across modules/classes will clutter your diagrams and will not add any value.
As a developer looking at class diagrams, I would not want to see the loggers/audits. You can add the details about these cross cutting functionalities in your other specs/documentations.
UML is not about diagrams, it's about models. Your diagrams help humans to understand the model. You create more than one diagram to highlight a certain aspect. If you try to document a 3-dimensional sculpture with 2-dimensional photos you also need to make more than one photo. Some of those photos will have duplicate (redundant) information. You can crop them if needed. But sometimes you need that for the context.
To sum up: make as many diagrams a needed. Focus in some. Make a more global picture in others. It's an art of its own to get good pictures.
I've been developing an Android app for a while but I didn't start with any particular diagram. And now comes the time to do some real diagrams but I don't know how. Not because I'm not familiar with UML but because of Android and it's components.
For example, my app requires that the user needs to be logged in in order to see a menu. From there the user can choose the options he wants. The user can also do his registration.
Although this might be a silly and simple example...The point is...I didn't use any class named "Person" with getters and setters; or any class named "Request" with getters and setters and other methods.
My app use classes like "Login.class", "SignIn.class", "MenuActivity.class", "HistoryActivity.class".
My question is...how do I use UML for an Android app?
I mean I can't have a conceptual model diagram that says "Person"-----"Request", right?
Thanks in advance.
I think you are confused with different types of UML diagram types,
There are,
Structural UML diagrams
Class diagram
Package diagram
Object diagram
Component diagram
Composite structure diagram
Deployment diagram
Behavioral UML diagrams
Activity diagram
Sequence diagram
Use case diagram
State diagram
Communication diagram
Interaction overview diagram
Timing diagram
And more, I think you are talking about Class diagram. Since class diagrams are technical and are targeted for the development team, It is totally fine to have all these Login.class, SignIn.class, MenuActivity.class, HistoryActivity.class in your class diagram.
But you can use conceptual things like Person, Request ect in your other UML diagrams (eg Use Case). because in these diagram this is targeted for many users not just developers, So using MenuActivity does not make any sense. Using conceptual entities is the way to go here.
Good luck
Your example suggests that you're trying to capture a some sort of use case. In this case you may need an activity diagram to demostrate the higher level view or a communication diagram if you're more concerned with more detailed one.
UML isn't concerned with programming languages, platforms and so on. Its main purpose is to provide a notation which can be used to communicate ideas without necessarily getting into too much details. So the first thing you need to consider is why you need diagrams in the first place and what you want to communicate with them. Given these questions answered it will become clear what kind of diagrams you need.
There is such thing as "4+1 model" which aims to separate the software model into several views. These views show different aspects of the software and concerned with different levels of detail. In Unified Process, for example, it is adviced to model from "top" to "bottom" of the solution, from high-level overview of use cases and main features to the actual implementation details. UML supports that providing different types of diagrams as well.
So if I understood I can use those conceptual terms (Person, Request) even if they aren't any classes with those names at all...they are used as an example right?
You indeed can, but not in diagrams with low-level features like Activities. You may want to build a domain class diagram that will include Persons and other entities relevant to your application, but won't be really represented in code.
I was taught UML early on in university but all the examples were always with simple console applications. Now that I have been assigned to develop a project with a graphical interface (using Java) and was required to submit a UML model, I haven't got a clue how to go about representing the graphical frontend aspect of the application in tandem with the non graphical backend classes. I'm not quite sure where to even start.
How would you suggest I go about doing this?
Usually UI modeling involves 3 things:
How the UI looks like: this is not usually done in UML. You need a tool like Visio or Pencil to do that.
How the UI is structured: This considers how the UI is structured into classes. How these classes are related to each other (dependencies, navigation, ...). How they are related to domain classes. How they are related to the Use Cases (which ones they implement). This fits naturally in UML structural diagrams: class diagram, package diagram, component diagram, ...
How the UI behaves in runtime: How certain actions cause objects to be created and methods to be called to perform the desired actions. This fits naturally in UML behavioral diagrams : sequence diagram, communication/collaboration diagram, activity diagram.
So basically in your UML model, UI classes (Screens, Applets, Pages, ...) will appear like normal classes. This will allow UI structure and behavior to fit in your application view models.
Note that there are tools that make use of UML profiles to provide UI mocking as alternative to graphical tools like Visio. In this custom profile you may find for example stereotyped class called << screen >> and stereotyped dependency called << navigation >> to model how UI elements trigger UI navigation to other screens.
I think you need to start by asking what you want to model and then that leads to you work out whether UML is useful and if so, which parts. Start by asking who is going to use this model and for what. Model with a purpose.
If you want to model the class structure of your application, then a UML class model might be useful. But even then, are you trying to illustrate the UI classes or the information (domain) structure, or both?
If you are trying to show how the runtime interactions work, then a sequence diagram might be useful.
If it is modularisation of code and dependencies between modules, a package diagram would do this.
If you have a complex user interface program with a sophisticated component structure which you want to explain, then it's no different to server software and a component diagram would be useful.
Whenever creating a model ask why you are doing it, for whom and what they want from it. That leads you to select something useful rather than just doing "busy work".
Asides from the previous answers, a common design for UI is one of model-view-controller (MVC). Some UML tools actually have stereotypes to help you with representing these elements. The model is the data that you want to show, the view is how it is displayed, and the controller links the two, taking the input to the UI and processing it to change the display with the new data from the model.
It is also easy and useful to create sequence diagrams for a MVC system to show the actions and their effects.