Question

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?

Was it helpful?

Solution

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.

OTHER TIPS

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top