Quantity (analysis sample)

from Wikipedia, the free encyclopedia

Quantity ( English Quantity ) is an analysis sample from the software art and is used for modeling of measurable values and their unity. The pattern was developed by Martin Fowler and described in his book Analysis Patterns .

problem

Computer systems process the information about objects in the real world as attributes of software-technical objects . Measurable values ​​are shown as numbers without a unit, since common programming languages ​​do not offer any data types for SI sizes or currencies .

In practice, this fact repeatedly leads to errors in application programs if calculations between different units are not carried out correctly or are not prevented, as is the case with the addition of 5 meters and 10 grams.

context

Quantity belongs to the group of analysis patterns, perceptions and measurements (English Observations and Measurements ). This group includes analysis samples that were created as part of a project to develop a medical application in the clinical field. The patterns are general and can easily be transferred to other application domains .

Other important patterns in this group are transformation ratio , composite unit , measurement , and perception . Conversion ratio expands quantity and allows conversion from one unit to another.

The technical use of this analysis model is of course reserved for the field of natural sciences due to the specification of measurability (numerical recording) of certain characteristics. For the purpose of standardization, a so-called " International System of Units " was developed, which contains the basic quantities as well as their associated basic units and associated abbreviations according to the international standard.

solution

Pattern quantity as a class diagram

The term “Quantity” is equated with the German word “Quantity”. It describes the numerical recording of certain things in our real world (countability of objects). This is understood to be a defined, measurable space of objects of a certain type. This space is represented by the name of the type and divided into countable units of the same size by the objects. These units are assigned unique names to represent the distinction. A numerical value is placed in front of the unit to describe the quantity. The resulting measured values ​​therefore always consist of an amount and an associated unit.

Certain data types are made available by the type system of the programming language via the compiler . Such data types are, for example, integer, real, string and date. Since the compiler already understands these data types, they can already be used for the implementation of attributes within a class. The compiler does not recognize other data types or they are made up of several basic attributes. These types are implemented as abstract data types in new classes and then, via relationships, appropriate connections are made to the classes that have to access these data types.

Quantity models measurable values ​​as a type that combines the amount with its associated unit. Quantity can thus be used to represent all measurable values ​​and is particularly suitable for currencies.

If measurable values ​​and their unit are modeled as objects in this way, a number of advantages result. Quantity includes the operations necessary to calculate with measurable values ​​and to compare them. There are also operations for input and output.

This includes checking whether an arithmetic operation with two different units is permitted at all. 20 kilograms cannot be added to 2 meters. In addition, it can be recognized if only a conversion is necessary for the execution of an arithmetic operation, such as the addition of 2 meters and 3 kilometers. As soon as several units have to be differentiated, the conversion should no longer be carried out from quantity itself, but should be outsourced to the sample conversion ratio. Similar tests are necessary when comparing quantities.

Further operations are made available for reading in and output ("toString ()" and "parse (String)" in the figure). These allow the output as a character string, as well as the reading in of a character string in quantity . Usually a representation is chosen in which first the amount and then the unit is output, e.g. B. "5 seconds".

Examples and related explanations

(1) For a better understanding, we consider the following statement:

The temperature is 38 degrees Celsius.

This statement contains 2 terms and a numerical value. The terms must be clearly separated. The numerical value is already clear. We therefore regard each term as a separate type and then let both types enter into a relationship. The relationship then represents the connection between the types and is indicated by a verb. The numerical value (amount) is then assigned to the appropriate type. In this case, the term “temperature” represents the room in which the objects are located. The individual objects themselves are represented by the unit called "Degree Celsius", of which exactly 38 can be counted in the example.

(2) An important aspect of the type assignment is the meaningful and correct use of the terms to avoid incorrect interpretations. Mixing up terms must therefore be avoided at all costs. Another focus should be on the imperative when using the analysis pattern "Quantity". This aspect must then be considered separately for each individual case. The following statement should clarify the relationships:

The book consists of 250 pages.

Interchanging the terms “book” and “page” in the sentence would not make sense here. In software engineering there is then a generic term “book” as a class with an attribute “page number”. It is not necessary to program the number of pages as "Quantity".

money

Be monetary values (currency) with quantity modeled, this is described as analyzing patterns of money (English Money ). So money is just a special case of quantity in which the unit is represented by the currency - the concept does not differ.

When displaying currencies, you have to decide whether to implement this object property either as an attribute in the object class or to generate a new data type as a separate class to accommodate the corresponding attributes. There are different currencies to which certain names are clearly assigned. Due to this fact, the need to form a separate class is already recognizable. In the practical implementation, a separate class is then created for the basic type of money with a meaningful class name (e.g. "Money" or "Money"). A subclass can then be attached to this class via an association, which uniquely assigns the various currency units to the basic type "Money".

However, a difference arises from the fact that the conversion factors of monetary units change over time, in contrast to the physical quantities. Another additional quality of money involves rounding numbers. Mathematical rounding is not always desired when dealing with monetary units. Money can define additional rounding rules for this purpose. For example, when paying out coins, it can be requested that it be rounded up to the next amount for which real coins exist.

A similar problem arises when, for example, 100 euros are to be paid out to three parties (100 divided by 3). A result of 33.33 euros is not satisfactory, as only 99.99 euros would be paid out and 1 cent would be lost, so to speak. The solution to the problem can be imagined in such a way that money delivers twice 33.33 euros and one time 33.34 euros as the result. One party is lucky and so receives an extra penny. In programming, this can be done by returning a container .

A money object is an immutable object of value ; H. Calculations with a money object do not lead to a change in the object itself, but rather create a new money object as a result.

The following Java - source code shows a method of multiplication. A new object of the money type is created.

public Geld multipliziere(double arg) {
   return new Geld(betrag * arg, währung);
}

literature

  • Martin Fowler: Analysis pattern: reusable object models . 1st edition. Addison-Wesley-Longman, Bonn 1999, ISBN 3-8273-1434-8 , pp. 40-42 .

Web links