Creator
	We don't have a full "chain of creation"
	So far we have considered only parts of the system
	(for example fig 3 shows that "the user" creates an event)
	but not gone into detail concerning actual object creation.
	For this reason, it seems our diagrams do not adhere the creator principle.
	Creation is unclear concerning:
		-User
		-Group
		-Calendar
	It is clear that an event is created trough some kind of GUI interaction,
	but not which objects are responsible.
	Likewise the Store and GUI must be created somewhere, but it seems
	logical to make theese as part of the system startup (mvc, anyone?)

Information Expert or just Expert
	Experts are a bit better defined.

	-A User object is knows user info - such as name, employment status (Generel Manager or not?).
	It represents a user, and can as such be considered as infromation
	used elsewhere, rather than seen as containing information.

	-A Group object knows all its member users (or member groups) and its manager(s).
	it contains the group name aswell, and probably a member count, but this getting a little implementation bound.
	It probably goes that any group must know all groups that it is in.
	Though this is not currently reflected in the diagrams

	Currently, it is unclear whether Groups are able to present their
	calendars, or whether another object must ask the store for them events to create them.
	Either way, the group knows it's own id, so it would be able to ask the
	store, or provide the id for another object to ask the store for the relevant events.
	It is not a matter of great importance.

	-Calendars are a volatile but essential entity.
	They are the only objects that knows events in a relevant format, yet
	that format is arbitrarily defined during execution.
	They are used to answer questions such as "what events does [group name] have in [period]".
	This question is more complex than it sounds. As all users are
	considered groups, and groups can contain groups, this will include
	events from groups the group/user is a member of, and groups that they are members of.
	In short: they know events. It might be practical for them to know the
	groups the events concern, but it is not essential.

Low Coupling
	The system seems quite uncoupled, except perchance the connection
	between User and Store (user could be represented through the group
	entity, but it complicates the 'mental model' about user specific data.).
	A cleaner model could be using the "composite" design pattern with Group and User.

		-The calendar uses only events, and perhaps the store to
		retrieve them (see the section on Experts).
		-Events uses its atendees (groups, not users), and maybe the
		store to save themselves.
		-Groups uses their users, and maybe the store.
		-Users use only themselves, and perhaps the store.
		-The store is coupled to almost all other entities.
		this is necessary, and can be eased by eg. using interfaces or
		reflection (entity framwork) for saving entities.

Controller
	Control is a gaping hole in the current design.
	This problem is proabably do to the lack of focus on a user interface,
	which would demand focus on controll.
	It seems the MVC pattern might be clear-cut for this application, so
	perhaps the sollution is to add an entity with the specific purpose of
	controlling.

High Cohesion
	This system is failry small, and its primary job is ordering,
	displaying, and saving data. Therefore it seems almost ridiculous to
	talk about cohesion.
	The most interresting part of the system, cohesion wise, is probably the
	Calendar entity. It is an utterly artificial class, but it will probably
	be responsible for ordering the events.
	Though it could be argued that, as different UIs may have different
	goals, ordering events should be job of the UI.