Analysis patterns
From CSSEMediaWiki
(Difference between revisions)
(Added list of patterns. Hope someone can fill it out.) |
Tanmay Bhola (Talk | contribs) (→List of Analysis Patterns) |
||
| (6 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
| − | |||
What is an ''analysis'' pattern? I think an analysis pattern is: | What is an ''analysis'' pattern? I think an analysis pattern is: | ||
* An archetypal domain model for a specific problem domain. | * An archetypal domain model for a specific problem domain. | ||
* Like a design pattern, but without implementation details. | * Like a design pattern, but without implementation details. | ||
| − | In other words, analysis patterns look a lot like design patterns, but they are for some specific problem domain, rather than being applicable to any problem in the way that design patterns are. They are examples of [[Domain modelling]]. | + | In other words, analysis patterns look a lot like design patterns, but they are for some specific problem domain, rather than being applicable to any problem in the way that design patterns are. They are examples of [[Domain modelling]] and focus on conceptual structures of high level business processes, instead of implementation. |
Consider our [[Parse tree design]] example. We aren't the only ones to need a parse tree, and our design must look a lot like other designs. Why not abstract out the problem domain concepts, remove any implementation details (like Enums in java) and make a reusable model, suitable for use in any parse tree implementation? Then we'd have an analysis model for the domain of parse trees. | Consider our [[Parse tree design]] example. We aren't the only ones to need a parse tree, and our design must look a lot like other designs. Why not abstract out the problem domain concepts, remove any implementation details (like Enums in java) and make a reusable model, suitable for use in any parse tree implementation? Then we'd have an analysis model for the domain of parse trees. | ||
| Line 16: | Line 14: | ||
| − | + | == List of Analysis Patterns == | |
| − | + | ||
| − | + | ||
| − | + | The following is a list of Martin Fowler's analysis patterns. It would be great if each one could have its own wiki page. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | {| | ||
| + | |- | ||
| + | | [[Accountability]] || The concept of accountability applies when a person or organisation is responsible to another. It is an abstract notion that can represent many specific issues, including organisation structures, contracts, and employment. These analysis patterns look at describing relationships that define responsibilities between those types of parties. | ||
| + | |- | ||
| + | | [[Observations and Measurements]] || This deals with recording information about objects in the real world. Information can be represented in computer systems as records, attributes, objects, and various other representations. The typical route is to record a piece of information as an attribute to an object. For example, the fact that I weigh 80 kgs would be recorded in an attribute of a person type. This group of analysis patterns suggests more sophisticated approaches and why the described example fails. Also included here are ''Observations for Corporate Finance''. | ||
| + | |- | ||
| + | | [[Referring to Objects]] || Within an OO computer system, each object has a unique ID, which is used as a guarantee that any object can be directly accesssed. We still need some way to refer to a particular object though: For example, I might need to find a particular person to whom I need to send a bill, and a doctor may need to mark a patient down as suffering from diabetes. Object systems provide us with powerful browsing capabilities that exploit the natural relationships between conceptual objects, but sometimes a more explicit identifier is required. These analysis patterns are about ''conceptual'' references to objects - references that humans use. That is, the indexing we need when referring exactly to objects in our working life. | ||
| + | |- | ||
| + | | [[Inventory and Accounting]] || Most commercial computing systems are designed to track the money moving through an enterprise and recording the way it is earned and spent. The fundamental idea behind accounting and inventory tracking is that there are various pots of money and good, and we must record how money and goods move among these pots. The analysis patterns here are born from this fundamental idea. They present a core set of concepts that we can use as the basis for financial accounting, inventory, or resource management. The patterns do not describe these processes directly, rather they describe the underlying ideas from which processes can be built. | ||
| + | |- | ||
| + | | [[Planning]] || Planning is a vital part of any large endeavor. Many managers spend most of their time developing and tracking plans. These analysis patterns here, examine the relation ship between standard plans and one-off plans, and how to plan and record the use of resources. | ||
| + | |- [[Trading]] || These analysis patterns look at the buying and selling of goods and at the value of these goods with respect to changing market conditions, i.e. trading situations where prices are fluid and we need to understand how these price changes affect the profits of our trades. Using experience of building a trading system for a bank, buying and selling is looked at from both angles by Fowler here. The bank has to understand the value of the net effect of these trades in different circumstances. | ||
| + | |} | ||
| + | [[Category:Analysis Patterns]] | ||
[[Category:Pages that need examples]] | [[Category:Pages that need examples]] | ||
Latest revision as of 06:07, 20 October 2010
What is an analysis pattern? I think an analysis pattern is:
- An archetypal domain model for a specific problem domain.
- Like a design pattern, but without implementation details.
In other words, analysis patterns look a lot like design patterns, but they are for some specific problem domain, rather than being applicable to any problem in the way that design patterns are. They are examples of Domain modelling and focus on conceptual structures of high level business processes, instead of implementation.
Consider our Parse tree design example. We aren't the only ones to need a parse tree, and our design must look a lot like other designs. Why not abstract out the problem domain concepts, remove any implementation details (like Enums in java) and make a reusable model, suitable for use in any parse tree implementation? Then we'd have an analysis model for the domain of parse trees.
The parse tree design exercise stepped through a series of design issues. Rather than being a single model, we produced a family of related designs, with extensions that address different issues. e.g. the Visitor Pattern was applied to the parse tree to allow flexible traversals, while the Flyweight Pattern reduced space requirements.
Analysis patterns are like that too. Most patterns provide a model for some problem domain, with extensions for variations on the theme.
The main source of analysis patterns is Martin Fowler 1997.
List of Analysis Patterns
The following is a list of Martin Fowler's analysis patterns. It would be great if each one could have its own wiki page.
| Accountability | The concept of accountability applies when a person or organisation is responsible to another. It is an abstract notion that can represent many specific issues, including organisation structures, contracts, and employment. These analysis patterns look at describing relationships that define responsibilities between those types of parties. |
| Observations and Measurements | This deals with recording information about objects in the real world. Information can be represented in computer systems as records, attributes, objects, and various other representations. The typical route is to record a piece of information as an attribute to an object. For example, the fact that I weigh 80 kgs would be recorded in an attribute of a person type. This group of analysis patterns suggests more sophisticated approaches and why the described example fails. Also included here are Observations for Corporate Finance. |
| Referring to Objects | Within an OO computer system, each object has a unique ID, which is used as a guarantee that any object can be directly accesssed. We still need some way to refer to a particular object though: For example, I might need to find a particular person to whom I need to send a bill, and a doctor may need to mark a patient down as suffering from diabetes. Object systems provide us with powerful browsing capabilities that exploit the natural relationships between conceptual objects, but sometimes a more explicit identifier is required. These analysis patterns are about conceptual references to objects - references that humans use. That is, the indexing we need when referring exactly to objects in our working life. |
| Inventory and Accounting | Most commercial computing systems are designed to track the money moving through an enterprise and recording the way it is earned and spent. The fundamental idea behind accounting and inventory tracking is that there are various pots of money and good, and we must record how money and goods move among these pots. The analysis patterns here are born from this fundamental idea. They present a core set of concepts that we can use as the basis for financial accounting, inventory, or resource management. The patterns do not describe these processes directly, rather they describe the underlying ideas from which processes can be built. |
| Planning | Planning is a vital part of any large endeavor. Many managers spend most of their time developing and tracking plans. These analysis patterns here, examine the relation ship between standard plans and one-off plans, and how to plan and record the use of resources. |
