What is the difference between UML diagrams and UML models?
I've created several UML diagrams such as activity diagrams and use case diagrams. The guidelines required me to prepare the model of the software I designed for the presentation.
Does that that mean I have to use the UML diagrams I made, with the description of the contents or do I need something like mock-ups or wireframes to present the software?
The model represents the whole system or its part from a certain perspective, with multiple aspects and all the complexity. The diagrams slice it into small bits that can be analysed bit by bit.
By definition (writing from memory), A model is a simplified representation of the actual object (existing or designed) or its part, often focusing on specific aspects. Models are used to understand the real object and its properties better. A diagram is a visual representation of a certain aspect of the object or its part, usually in a standardised graphical notation.
The two main differences are as follows:
In case of a very simple system and only one interesting aspect, one diagram can represent the entire model with the only interesting aspect. In reality though we usually create the system model to fully understand a complex system (or a component) in which case you need to visualise or describe in some other way (not only as a diagram) several aspects of the system. For instance, you typically consider both static and behavioural aspects of the system and you need separate diagrams to show them, but they may still be parts of a single model. Model can also have a form of mocks, description. By the broadest definition BRD is also a model.
The diagram on the other hand is a graphical representation only. It's a kind of a single sheet out of the whole set of "plans".
In practice, you'll split complex information that constitutes the model into small comprehensible bits that you will show on a diagrams (and sometimes also in other forms, e.g. textual descriptions screen mocks or decision tables). Large, complex data model will be split by packages plus few diagrams showing the complex relations. The multiple behaviours of the system will be presented one at the time (you can't have a single activity diagram presenting multiple activities, can you?). The entire model of the system will be represented from various angles, both static and behavioural and shown on different models. And so on.
So typically, the model will consist of a list of objects in the system, usually represented in diagrams, the behaviours, also at least partially presented as diagrams and sometimes part of information presented in additional form as a part of the documentation.
Think of a house 2-storey house. Plans of each of the house's floors will be one version or even just part of the model, second part being the physical model or system visualisation. The plans can be very generic (so that you understand where the rooms are or how to run the whole infrastructure). A single plan of one floor will be a diagram.
A natural follow-up question is "What should be included in the model?" and unfortunately, there is no simple answer to that. As a rule of thumb though the model should contain all necessary information (and not more!) and diagrams should be build in such way (simple enough and logically split) that they allow to understand the information.