creating a media collections manager

Hi I'm trying to create a program to manage my movie and tv show files I downloaded. I want to write it in JAVA cause I can practice for school doing this and to program needs to be cross platform I want to run it on windows/mac/linux. What i want the program to do is read a foldername or filename and then scrape the info from IMDB/themoviedb.org/theTVDB.org using the API's. After the info is scraped it should be save to .nfo files with an XML stucture so XBMC can read them and add the info to its media library. I had some UML lessons in school so I thought I would make a class diagram of how the info should be use internally in the program but I don't know if what i made is good or could be improved upon. Is the开发者_StackOverflow中文版re anyone who can give me some advice? UML class diagram.

First off, there is no Right or Wrong in design, just opinions. Asking for advice is a good idea, just remember that advice is all you get - not a right-or-wrong answer. That said, here are some of my suggestions:

1) Pay careful attention to association directions and multiplicities.

At the moment, your MovieInfo has a directed association to a Genre, and the MovieInfo end multiplicity is 0..1. This means that any genre can have at most one movie, and also that you cannot pick a genre and find all movies of that genre.

If you instead make the association bidirectional and the multiplicity 0..* at both ends it corresponds better to the logical relationship between a movie and a genre.

2) Don't allow setting of key characteristics.

For instance, your Genre class contains a setGenre() operation, which means that you can associate a movie with the genre "horror", and then change the genre itself to instead be "romantic comedy". You most likely don't want that to happen, so instead the genre name should be set only in the Genre constructor.

3) More classes!

It's a good idea to create an individual class for each concept in your information space. Right now you are using simple strings to represent things like studio, director, etc, which means that if you want to find, say, all movies put out by a certain studio you have to go through all movies and check their "studio" fields individually.

The current design also makes it very difficult to handle joint productions where there are more than one studio involved.

Instead, you should create separate classes like you've done for Actor and Genre.

4) Change Actor to Person.

Some people are actors in some movies, directors in others, producers in some... But if you create separate classes for Actor, Director, etc you end up with a situation where the same individual is represented by multiple instances of different classes, which is messy.

If you instead create a single class Person, with a 0..* association to Movie named actorIn, another 0..* association to Movie named directorOf, etc, you get around this problem. Yes, you can have several separate associations between the same two classes.

5) Separate the information model from the implementation model.

An information model describes concepts and their relationships, an implementation model the code entities used to achieve the desired functionality. In this case, get() and set() routines are part of an implementation model; they add nothing to an information model.

Once you get into the implementation model, that's where you start thinking about implementation issues such as "do I really want to be able to set the play count of a movie arbitrarily, don't I rather just want to be able to increase it by one?"

OK, hope that helps some. Remember it's all personal opinion, and good luck.

Part 2 - Added after Aegis' comments Jul 30:

You're asking a pretty big question here, and it's more in the realm of general software engineering than Java or UML specifically.

In large or complex systems, a domain model is often used. This describes the context in which the system exists. In your case the domain model would contain things like IMDB, but it would not contain Actor since your system won't be communicating with any actors.

An information model, on the other hand, describes the information managed by the system and the relationships between the different information entities. Information entities may represent certain domain objects but they don't need to, nor do all domain objects be represented in the information model. You have the beginnings of an information model in your updated diagram.

Both the domain and information model help define or explain the system. They are not used directly to generate code or anything like that. They are there to help you talk about and understand the system and its parts. The reason they are separate models is that system design is a complex process, and it helps to simplify matters if you can focus on just one aspect at a time. Also, the UML family of languages do not have a concept of "aspect" in themselves, which means that you can't describe different aspects of the same thing in an easy way; hence separate models for different aspects.

Once you get into the implementation, one of the things you need to do is manage the information. Again, the classes you create to do that do not need to correspond directly to those in the information model, but here you do need to ensure that you implement all the information concepts and relationships correctly.

All that said, in any project you always need to find the right balance between writing specifications and getting stuff done, and also between specifying different aspects of the system. Information management is only one aspect, and there are many others such as communication, error management, threading, etc etc.

With any documentation (and UML models are a type of documentation) you should always keep in mind the intended audience: what do you need to tell them, and how must you structure the message to get it across as clearly as possible? If the intended audience is yourself, then it might be that you're over-specifying - although it is always a good idea to try to get your thoughts down on paper (or in a model) in order to check yourself and make sure you're not trying to divide by zero somewhere.

I'm not trying to discourage you, mind. If one of your goals with this project is to learn UML then you're doing fine. Just be aware that modelling has a tendency to lure you into thinking that as long as the model is complete and consistent, the code will write itself. It won't, and there will always be several Big Problems left that don't make themselves known until you get into the code. If you spend a lot of time specifying and modelling only to realize that it doesn't solve these Big Problems, you might get fed up with the whole thing and chuck it all away, which would be a pity.