UML-B FAQ - Revision history

imported>Mathieu: Category:User FAQ Category:UML-B

2008-12-11T22:23:01Z

← Older revision		Revision as of 22:23, 11 December 2008
Line 13:		Line 13:

	Of course, for this example, you could obtain a much simpler model by leaving out the explicit modelling of bridge, island and mainland, but the advantage of our model is that it can easily be extended to deal with different configurations having several bridges and islands.		Of course, for this example, you could obtain a much simpler model by leaving out the explicit modelling of bridge, island and mainland, but the advantage of our model is that it can easily be extended to deal with different configurations having several bridges and islands.

			[[Category:User FAQ]]
			[[Category:UML-B]]

imported>Colin: /* How should I model a fixed set of instances with a class? */

2008-11-13T12:39:28Z

How should I model a fixed set of instances with a class?

← Older revision		Revision as of 12:39, 13 November 2008
Line 12:		Line 12:
	[[Image:fixedClassInstances.png]]		[[Image:fixedClassInstances.png]]

	Of course, for this example, you could obtain a much simpler model by leaving out the explicit modelling of bridge, island and mainland~~. The~~ advantage of ~~this~~ model is that ~~you~~ can easily ~~extend it~~ to deal with different configurations having several bridges and islands.		Of course, for this example, you could obtain a much simpler model by leaving out the explicit modelling of bridge, island and mainland, but the advantage of our model is that it can easily be extended to deal with different configurations having several bridges and islands.

imported>Colin at 12:38, 13 November 2008

2008-11-13T12:38:07Z

← Older revision		Revision as of 12:38, 13 November 2008
Line 1:		Line 1:
	~~'''~~How should I model a fixed set of instances with a class?~~'''~~		==How should I model a fixed set of instances with a class?==

	It is often useful to use a class to model a small, fixed set of instances. (As opposed to an indeterminate variable set where instances are constructed dynamically).		It is often useful to use a class to model a small, fixed set of instances. (As opposed to an indeterminate variable set where instances are constructed dynamically).

imported>Colin: New page: '''How should I model a fixed set of instances with a class?''' It is often useful to use a class to model a small, fixed set of instances. (As opposed to an indeterminate variable set wh...

2008-11-13T12:37:18Z

New page: '''How should I model a fixed set of instances with a class?''' It is often useful to use a class to model a small, fixed set of instances. (As opposed to an indeterminate variable set wh...

New page

'''How should I model a fixed set of instances with a class?'''

It is often useful to use a class to model a small, fixed set of instances. (As opposed to an indeterminate variable set where instances are constructed dynamically).
For example, to model a bridge between a mainland and an island, I would define a new class type BRIDGE and enumerate it with a constant, "myBridge" (i.e. Instances = {myBridge} where {myBridge} has been added as a type expression using the add new type button). I might also define the mainland and island this way as instances of a class type, LAND, and use an association to represent the connection of LAND to BRIDGE. (My model loses the generic distinction between mainlands and islands, so you might prefer to use 2 seperate classtypes). I would do all this in a Context diagram rather than a class diagram. That way it represents contextual configuration data, rather than state variables.

[[Image:EnumeratedClassTypes.png]]

To specify the association exactly, I could add axioms to define the actual mapping of mainland and island to myBridge. However, be careful because if this specific data conflicts with the more general definition of bridges the prover will not work properly. (It would be better if the type axiom for bridges was minimal and the cardinality restrictions (bijection in this case) were made into Theorems to be proved).

In order to use these concepts in a class diagram (i.e. to add variables and events based on this configuration data) I would add corresponding classes and set their variability to fixed (because we don't want to model creation of land and bridges). To force them to have the same instances as the class types I add a new type expression for each class type, BRIDGE and LAND, and then set the corresponding class instances to these types. (Note that using supertype would make the class instances into subsets of the configuration data which is not quite what we want here).

[[Image:fixedClassInstances.png]]

Of course, for this example, you could obtain a much simpler model by leaving out the explicit modelling of bridge, island and mainland. The advantage of this model is that you can easily extend it to deal with different configurations having several bridges and islands.