We Keep Coding

How to structure UML for more than 100 entities?

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.

UML diagrams + Android classes

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.

How do I model a graphical application using UML?

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.

Elegant code when there are many subclasses?

I have an interesting programming problem that has had me stumped for days. Some context to aid my questions:
Currently I am writing a game that uses a Material Emum to hold all the materials needed in the game ie Material.DIRT, Material.WATER, Material.CLOTH ...
However I wish to make the code as modifiable as possible and have the ability that should someone want to extend the game to add new materials they can do so. Thus my current Enum system breaks down and so I have attempted to switch to a Class/Subclass system. I have found two ways to do this, they are explained below with their pros and cons.
Case 1 - Having an abstract Material class and subclassing.
Thus every material would extend Material. This is advantageous as we can now "group" like materials together ie Fabric could extend Material and then Wool and Cotton etc extend this. The problem with this is that for every material there has to exist a class and with so little parameters for each material it feels like a waste. If there is 1000 materials there would be 1000 classes all with virtually nothing in them. I could cut this down by having anonymous classes but now the code has no way to differentiate one material from the other. I could use an id system which is the major problem with case 2.
The question for case 1 is:
Is there a more elegant way of doing this?
Case 2 - Having a single Material class and instantiating each new material as an instance of this class defining each material with a different id/name. This saves a lot of writing and also allows us to differentiate between materials. The problem with this is now we have an id system, what do we base this system on? Strings, ints? I ask this because I am always keen to have a complex free system that avoids using hardcoded strings and ints in the code. This is why I like the enums as there is no worry of typesetting. Another problem is users wanting to add new materials could have conflicting ids with other users.
My question for case 2 is:
Is there a full proof method of being able to differentiate instances uniquely and consistently (is the same every runtime)?
Thank you for reading. Any help or methods on how best to do this would be most appreciated.
Edit: I should note that some materials may have methods and behaviours associated with them. Some behaviours may be unique to certain materials and some that are similar for a "group".

Use a configuration file with all the materials in it, written in some DSL (simple table, basically).

How do you structure a java program? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
For quite awhile I have been trying to make a simple "game" in Java that is really just an applet with a square and a grid. What I want it to do in the end is the user clicks and the square will move to where the user clicked rounded to the nearest grid square.
The problem is I am a self taught beginner and I am having a hard time figuring out how to actually structure the program, some examples:
should I have a separate class listening for mouse clicks?
When I receive a click should I send it to some other object that represents the box and let it decide what it wants to do or just call some function that makes the box move?
I really want to learn all this "when to use what" stuff for myself so any links or general advice is appreciated.

What you're really asking is how to develop a game, which is notably different from a typical Java application. However, I'll give you a few ideas to at least point you in the right direction.
Take advantage of the fact that Java is an object-oriented language. That is, objects should each have their own responsibility.
Separate your game into three key layers: the application layer, the game logic layer, and the presentation layer.
The application layer should contain all of your helpers and generic subsystems, things like random number generators, text parsers, file access modules, mesh loaders, etc.
The game logic layer should implement all of the rules of your game, and be responsible for maintaining canonical state. Basically, when you press the "W" on the keyboard to move forward, the game logic layer should receive MOVE_FORWARD_REQUEST from the UI.
The presentation layer should be responsible for two things: getting input, and rendering your world. When it gets input, like the "W" key, it should map that to an action, and send that to the game logic layer to be processed. Then, it should render the world based on whatever the game logic told it to do.
Game development is obviously an entire realm with many books dedicated to it. One of my favorites is Game Coding Complete, which does focus on C/C++, but should give you a good idea about how you ought to structure your game.
Good luck!

One main principle of good software development is the Single Responsibility Priciple. It states that a function or class should only have one responsibility.
This way your classes and objects shouldn't become too big and unmanageable.

I think one of the most important concepts to master when developing software is the concept or Orthogonality. It's not the simplest definition, but in essence it means that one component (such as reading mouse clicks) shouldn't be directly tied to an unrelated component (moving a square on the screen).
In your case, the code reading mouse clicks should be separate from the code that actually moves the box. Whether you implement this as inner/anonymous classes or not is up to you. But if you follow the Orthogonality principle, it will be easy to change at a later date should you change your mind.

One problem here is that all the rules have some leeway in them where you have to use your own best judgement.
For example, the app you are describing now seems to me so simple I'd probably do it in a single class, with perhaps a couple of nested, perhaps anonymous classes. In any event, I could make a decent case for fitting the whole thing into a single source file, claiming that multiple source files would actually increase the complexity of the whole thing.
But if your GUI had a number of different controls, perhaps each controlling different behavior, it would become time to split the functionality up so you're not ending up with a big bowl of spaghetti code.
The Java GUI libraries try to naturally separate (view+controller) from model. You are encouraged to define and display the GUI in one module (= file) but to have your data model and perhaps functionality in another. For complicated GUIs, there may also be multiple GUI implementation modules held together by code.
One way to keep things "clean" is to work in "layers" where each layer "knows" only what it needs to know. To be specific, the GUI layer needs to know about the existence of its underlying models – tables and lists and whatnot need to be connected to TableModels and ListModels, etc. It doesn't need to know about details of these models though, so it can simply refer to those models by interface.
The model layer, on the other hand, need know nothing about the GUI. The less it knows, the better, and this would theoretically enable you to exchange GUIs without needing to touch the models.
My model can also contain ActionListeners to respond to actions undertaken by e.g. pushing buttons in the GUI.
Of course, actions and changes to the model will often result in changes to the GUI. How to communicate these changes to the GUI if the model layer doesn't know about the GUI? You can use bound bean properties here. Here's a short tutorial: http://www.javalobby.org/java/forums/t19476.html . So you have the same kind of structure: Changes happen in your model, they're communicated to beans with property change support within the model, and the GUI can attach listeners to those properties to find out something changed.
Whether you perform actual, effective actions (e.g. writing files, converting data, whatever) within your model code or whether you split "processing" code off into yet another module is up to you and will again depend on how cluttered your model already is. If there's a tiny handful of fields and methods feeling lonely in there, you may decide to mash things together but the moment it starts to look messy you'll want to refactor your processing code out into its own module. Processing sounds like the kind of module that doesn't want to know about other modules either; you may end up just calling its methods from the model level.
I've described my basic style for doing GUI development. There are certainly other recommendations out there, and you will likely develop your own style based on your experience. This is just intended to give you an idea and a possible starting point.

Step 1 - find the demo applets supplied by Sun. http://java.sun.com/applets/jdk/
Step 2 - read those demo applets. At least three. Preferably all of them.
One you've read several applets, you should see a little more clearly how to organize programs. You can then ask questions with a lot more focus pointing to specific applet examples and your specific programming problem.

Yeah, I'm a beginner programmer myself. Yeah, segregating functionality across multiple classes is a good way to reduce complexity and increase cohesion of individual classes.
Increasing cohesion good because by having more complex data structure your algorithms become less complex and your code is less dependent on each other.
For instance in your case it might be a good idea to separate the classes in accordance to MVC (Model View Controler).
You have a Model which represents the way your game data is structured.
You have a Viewer which present your Model in what ever form you please.
Have a Controller which picks up changes in the Model (via Listeners) and then updates the Viewer
Now you can change your Model and add extra functionality requiring only small changes in the way the Viewer works.
There are many Patterns out there but there isn't a hard rule when to use one over the other. There are some cases in which you can use several and there are cases in which will require you to chose one design pattern over the other.

Every beginning Java programmer should start with the Sun Tutorials. They are quite good.
Another good source, especially among free sources, is Bruce Eckel's "Thinking in Java", available from http://www.mindview.net/Books/TIJ/.
But the latter is a little dated compared to the former. That is why I recommend both.