Tool and material approach
The tool and material approach ( WAM approach ) is a method for software development that is oriented towards application and high quality of use .
The acronym "WAM" stands for the words Tool Automat Material , which form the central design metaphors of the approach. Its analysis documents, mission statements, workplace types and architecture guidelines support the development teams in iterative, agile software projects with prototyping and the analysis of business processes. The WAM approach is one of the few independent European contributions to object-oriented methodology.
The WAM approach is based on findings from industrial psychology and sociology: In factories and craft businesses, people work on materials with suitable tools. This image can be transferred to computer-aided work.
history
The WAM approach was founded by Reinhard Budde and Heinz Züllighoven at the GMD in Bonn. Subsequently, it was further developed at the University of Hamburg by Heinz Züllighoven and his group and is currently being taught there. The approach is based on Martin Heidegger's (work) stuff concept .
The WAM approach and Domain-Driven Design (DDD) have developed independently of one another . Nevertheless, the two approaches are very similar.
Basics
The WAM approach contains a number of metaphors, some of them from craft areas, that model various design concepts. The main five components of these concepts are listed here.
Expert values
Technical values are extensions of primitive data types of object-oriented programming languages. They hold information and cannot be changed, which is why technical values are useful for amounts of money, for example: It makes sense to add two amounts of money together. So here it is appropriate to treat an unchangeable amount of money as a separate technical value and to create a new one for each change to it. A subject value knows nobody but itself and other subject values. In the DDD, this concept is known as the Value Object .
materials
Materials are objects that a user processes with a tool as part of a task and that make up his work results. A material may use and change other materials, as well as specialist values, and create new specialist values. Many properties of specific technical objects, such as contracts, forms, bank accounts or plans, can be meaningfully transferred to software materials. Materials are entities in the DDD sense.
Services
Services, also known as service , offer technically motivated interfaces at which specialist values and materials can be received and returned. A service includes the implementation of the technical logic which does not fit into a tool or a machine. He knows and uses both technical values and materials, but does not present them. A service is usually available for the provision of external data (e.g. a network connection, database, file, etc.).
Vending machines
An automat is very similar to a tool, but a tool has a graphical user interface , but an automat does not. A typical field of application are background activities in which he is configured before his activity and then works without interaction with the user. Thus he offers z. B. for data archiving , downloading files or other long-lasting processes.
Tools
Tools enable the user to edit materials quickly and flexibly via a graphical user interface: They relieve him of annoying routine activities, as the user only has to initiate a process, which the software then executes. However, because operating a computer is fundamentally different from operating manual tools, it is necessary to recognize the concept of work behind the manual tool. A direct mapping of (manual) tools in software is - in contrast to materials - rarely useful. A tool can use, use and change services, machines, materials and specialist values, which can lead to cyclical dependencies during implementation. To prevent this, the connection between two sub-tools (a tool that is itself used by another tool) is not left-hand comparative .
hierarchy
All components are arranged in a certain hierarchy, creating a clear and easily maintainable structure. Technical values, for example, only know themselves and other technical values, whereas tools know other tools, machines, services, materials and technical values. In order not to break the class hierarchy and not to create cyclical dependencies, the observer pattern is often used so that classes from lower hierarchical levels can communicate changes in state to higher levels.
See also
literature
- ^ Reinhard Budde, Heinz Züllighoven: software tools in a programming workshop. Reports of the Society for Mathematics and Data Processing No. 182, Oldenbourg, Munich, 1990.
- ↑ a b Heinz Züllighoven et al .: Object-Oriented Construction Handbook. dpunkt.verlag / Copublication with Morgan-Kaufmann, 2004, ISBN 3-89864-254-2 .
- ↑ http://wam-ansatz.de