Information Model

An information model in software engineering is a representation of concepts and the relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. Typically it specifies relations between kinds of things, but may also include relations with individual things. It can provide sharable, stable, and organized structure of information requirements or knowledge for the domain context.

It is very easy to put together a class diagram and assume that it is correct. One should not put off testing until you have coded your application. Test every time you add information to your model. Let the models do the work of finding discrepancies for you. The modeler should take notice of errors early, while they are cheap and less painful to fix.

The term information model in general is used for models of individual things, such as facilities, buildings, process plants, etc. In those cases the concept is specialised to

1. facility information model,
2. building information model,
3. plant information model.

Such an information model is an integration of a model of the facility with the data and documents about the facility. Within the field of software engineering and data modeling an information model is usually an abstract, formal representation of entity types that may include their properties, relationships and the operations that can be performed on them. The entity types in the model may be kinds of real-world objects, such as devices in a network or occurrences. The types themselves may be abstract such as for the entities used in a billing system. Typically, they are used to model a constrained domain that can be described by a closed set of entity types, properties, relationships and operations.
An information model provides formalism to the description of a problem domain without constraining how that description is mapped to an actual implementation in software. There may be many mappings of the information model. Such mappings are called data models, irrespective of whether they are object models entity relationship models or XML schemas.

The word model used in this section has a more specific meaning than the word normally does when discussing UML models. Model is a stereotype that you apply to a package to signify that it is a complete view of the system from a particular perspective. A package of stereotype <<model>> is an overall grouping of other packages and subsystems used to represent a particular view of a real-world physical system. You can build many model views of a physical system, each for a different stakeholder. For example, if you were to create models of a hotel reservation system, you might have a

1. business-model view for management,
2. a logical-analysis view and
3. a physical-design view for programmers and database analysts, and
4. an implementation view for (IT) people.

Your goal for modeling the business-model view would be to create a complete representation of the business from a manager's perspective. In addition, it would detail the people involved and the business process flows that occurred. However, the business-model view wouldn't detail the programming code that ran the applications. That information would be provided in the physical-design view for programmers and database analysts.
You could compare a <<model>> view with the various drawings used to architect a building. There are physical building blueprints, electrical design schematics, plumbing schematics, and so forth, each providing a complete model of the physical building, but a different view. Each view is created for a different stakeholder.