Conceptual 'Class Model' mapping an 'Observer Pattern' in UML

Question

I am drawing a conceptual UML Class Diagram based on an Observer Pattern between a UI layer and a mapped domain, where the publisher pushes notifications in the form of SQL queries to the different classes creating records in a SQL database. The model so far looks as following (purely conceptual, note the not yet implemented methods from the ISubscriber interface):

I have some questions regarding the different types of associations between the classes.

• What type of association exists between ISubscriber and IPublisher?
• What type of association exists between the domain layer classes and the DataAccess class supposed to contain the SqlConnection? Assuming the interface methods are overwritten and pushes SQl queries to DataAccess class

Answer 1

The IPublisher needs to know its subscribers to be able to push the notifications. This means that there is an association between the IPublisher and * ISubscriber.

Since the IPublisher needs to find efficiently its subscribers, you may even indicate that the association is navigable from publisher to subscriber.

It is not clear if your design should allow an ISubscriber to subscribe to only one IPublisher or if it can subscribe to more than one. If you already know, you may wish to specify the opposite multiplicity accordingly. Keep in mind that implementations of the observer pattern with multi-subscription, rarely need a reverse navigability: usually, the notification is then designed in a way to indicate the relevant publisher (e.g.: ISubscriber would have a notify(IPublisher from) operation or reception.

Regarding the associations of domain classes with data access classes, your question is too broad, as it depends on your chosen architecture. For example, you may use:

• the active record pattern where every domain object takes care of its DB operations (i.e. DB class and Domain class are the same),
• the repository pattern, where a repository for relevant aggregates deal with the DB (i.e., Domain object does know nothing about DB) and the rest of the application inserts or extracts domain objects into/from the repository, as if it were a container/collection.
• several variants of gateway pattern, such as the table data pattern, where a gateway is in charge of the DB, but the object deals with the gateway (i.e. there is a dependency from domain class to the DB gateway, or even an association if dependency injection is used).
• Many others (I can only recommend having a look at the Patterns of Enterprise Application Architecture, a book which is a really good investment)