Accountability
Joey Scarr (Talk | contribs) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Joey Scarr) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
Accountability (also named "Organization Structures" in Fowler's updated version) is an [[Analysis patterns|analysis pattern]] that models employment, contracts, organisation hierarchies, and other issues that arise when one person or organisation is responsible to another. | Accountability (also named "Organization Structures" in Fowler's updated version) is an [[Analysis patterns|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'' | + | 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, as well as more advanced concepts such as ''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. | [[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 == | == 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 == | ||
| − | 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 doesn't cut it). | + | 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: | ||
| + | |||
| + | [[Image:fowler_accountability2.png]] | ||
| + | |||
| + | In this instance diagram, BostonSales is the ''regional'' child of New England, but the ''functional'' child of the Sales department. | ||
| + | |||
| + | == Knowledge Level == | ||
| + | |||
| + | Knowledge Level is an abstract, high-level pattern that describes a situation where one group of objects describes how another group of objects should behave. The example given by Fowler is illustrated by the following diagram: | ||
| + | |||
| + | [[Image:fowler_knowledge.png]] | ||
| + | |||
| + | This diagram demonstrates the use of a knowledge level for employees. If you need to customise how Employees work, you can simply create a new instance of Employee Type with corresponding pay strategies and retirement plans. This allows the behaviour of Employees to be altered without writing any code. It's worth noting that this example uses the [[Strategy]] pattern heavily to delegate the different behaviours and allow them to be configured at runtime. | ||
| + | |||
[[Category:Analysis Patterns]] | [[Category:Analysis Patterns]] | ||
Latest revision as of 03:22, 25 November 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, as well as more advanced concepts such as 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.
Contents |
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.
Knowledge Level
Knowledge Level is an abstract, high-level pattern that describes a situation where one group of objects describes how another group of objects should behave. The example given by Fowler is illustrated by the following diagram:
This diagram demonstrates the use of a knowledge level for employees. If you need to customise how Employees work, you can simply create a new instance of Employee Type with corresponding pay strategies and retirement plans. This allows the behaviour of Employees to be altered without writing any code. It's worth noting that this example uses the Strategy pattern heavily to delegate the different behaviours and allow them to be configured at runtime.
