Accountability
Joey Scarr (Talk | contribs) |
Joey Scarr (Talk | contribs) |
||
| Line 6: | Line 6: | ||
== Parties == | == Parties == | ||
| + | |||
| + | [[Image:fowler_party.png]] | ||
Fowler defines a Party as an abstraction of people and organisational units. | Fowler defines a Party as an abstraction of people and organisational units. | ||
| Line 18: | Line 20: | ||
The ''Organisation hierarchy'' pattern provides a highly flexible method for representing organisational hierarchies. It also supports modelling of multiple concurrent hierarchies (such as functional hierarchies and regional hierarchies), although if there are many hierarchies, the design quickly will quickly get out of hand. This can be solved by applying the Accountability pattern (described below). | The ''Organisation hierarchy'' pattern provides a highly flexible method for representing organisational hierarchies. It also supports modelling of multiple concurrent hierarchies (such as functional hierarchies and regional hierarchies), although if there are many hierarchies, the design quickly will quickly get out of hand. This can be solved by applying the Accountability pattern (described below). | ||
| − | + | [[Image:fowler_hierarchy1.png]] | |
[[Gang of Four]] design pattern enthusiasts will note that this is a simplified version of the [[Composite]] pattern (the difference between leaves and branch nodes has not been extracted out). Each node in the hierarchy is represented by an object at runtime, and each node is of the Organisation class. However, if each node type in the hierarchy requires different behaviour, subtypes of Organisation can be used to represent this, as in the following diagram: | [[Gang of Four]] design pattern enthusiasts will note that this is a simplified version of the [[Composite]] pattern (the difference between leaves and branch nodes has not been extracted out). Each node in the hierarchy is represented by an object at runtime, and each node is of the Organisation class. However, if each node type in the hierarchy requires different behaviour, subtypes of Organisation can be used to represent this, as in the following diagram: | ||
| − | + | [[Image:fowler_hierarchy2.png]] | |
== Accountability == | == Accountability == | ||
| Line 28: | Line 30: | ||
The Accountability pattern is used to model a set of complex relationships between parties, such as within an organisation with many different hierarchies (when the Organisation hierarchy pattern is too simple and doesn't cut it). The basic idea of the pattern involves modelling the accountability of one party to another using a ''typed relationship'', as shown in the following diagram: | The Accountability pattern is used to model a set of complex relationships between parties, such as within an organisation with many different hierarchies (when the Organisation hierarchy pattern is too simple and doesn't cut it). The basic idea of the pattern involves modelling the accountability of one party to another using a ''typed relationship'', as shown in the following diagram: | ||
| − | + | [[Image:fowler_accountability1.png]] | |
Each instance of Accountability represents a link between two parties (see [[Many to many association idiom]]), and the Accountability Type represents the nature of the link. This means that there is no hierarchical self-association on Party (i.e. the Composite pattern is gone), and each hierarchy is modelled through a set of accountability relationships. This allows complex structures such as the following: | Each instance of Accountability represents a link between two parties (see [[Many to many association idiom]]), and the Accountability Type represents the nature of the link. This means that there is no hierarchical self-association on Party (i.e. the Composite pattern is gone), and each hierarchy is modelled through a set of accountability relationships. This allows complex structures such as the following: | ||
| − | + | [[Image:fowler_accountability2.png]] | |
In this instance diagram, BostonSales is the ''regional'' child of New England, but the ''functional'' child of the Sales department. | In this instance diagram, BostonSales is the ''regional'' child of New England, but the ''functional'' child of the Sales department. | ||
Revision as of 00:32, 18 October 2010
Accountability (also named "Organization Structures" in Fowler's updated version) is an analysis pattern that models employment, contracts, organisation hierarchies, and other issues that arise when one person or organisation is responsible to another.
This analysis pattern covers the modelling of parties (which represent entities such as people and organisations), organisation structure, accountability relationships between parties in the hierarchy, knowledge levels, and operating scopes.
Martin Fowler writes extensively about this analysis pattern in http://www.martinfowler.com/apsupp/accountability.pdf (which can be considered an update to the second chapter from Martin Fowler 1997). This page includes material from both the original chapter and the updated version.
Parties
Fowler defines a Party as an abstraction of people and organisational units.
Take a look through your address book, what do you see? If it's anything like mine you will see a lot of addresses, telephone numbers, the odd email address… all linked to something. Often that something is a person, however the odd company shows up. I call 'Oak Grove Taxi' frequently, but there's no person I want to speak to — I just want to call a cab.
The use of a class such as Party allows much of the common data and behaviour of people and organisations to be abstracted into a single superclass. This mostly consists of contact data such as phone numbers, billing addresses, and so forth.
Organisation hierarchy
In any accountability system, there must be some way to model the hierarchical structure of organisations. Fowler begins by discussing the possibility of modelling the levels of an organisation hierarchy explicitly (i.e. in the class structure). However, such a structure is inflexible and not at all reusable - if the organisation changes its hierarchy at all (e.g. by removing a level to flatten the structure), the model must be reworked.
The Organisation hierarchy pattern provides a highly flexible method for representing organisational hierarchies. It also supports modelling of multiple concurrent hierarchies (such as functional hierarchies and regional hierarchies), although if there are many hierarchies, the design quickly will quickly get out of hand. This can be solved by applying the Accountability pattern (described below).
Gang of Four design pattern enthusiasts will note that this is a simplified version of the Composite pattern (the difference between leaves and branch nodes has not been extracted out). Each node in the hierarchy is represented by an object at runtime, and each node is of the Organisation class. However, if each node type in the hierarchy requires different behaviour, subtypes of Organisation can be used to represent this, as in the following diagram:
Accountability
The Accountability pattern is used to model a set of complex relationships between parties, such as within an organisation with many different hierarchies (when the Organisation hierarchy pattern is too simple and doesn't cut it). The basic idea of the pattern involves modelling the accountability of one party to another using a typed relationship, as shown in the following diagram:
Each instance of Accountability represents a link between two parties (see Many to many association idiom), and the Accountability Type represents the nature of the link. This means that there is no hierarchical self-association on Party (i.e. the Composite pattern is gone), and each hierarchy is modelled through a set of accountability relationships. This allows complex structures such as the following:
In this instance diagram, BostonSales is the regional child of New England, but the functional child of the Sales department.
