====== 2.3.4.8.3 Field Data ======
[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:start| Return to Object Data Taxonomy]]

===== Overview =====
[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:05_field:start| Return to Top]]

**Field Data**, or **Element Data**,  are the values stored within the Object and in many ways represent the reason for the Object (i.e., [[dido:public:ra:xapend:xapend.a_glossary:c:class]] in C++ or Java) to exist. In [[dido:public:ra:xapend:xapend.a_glossary:p:procedurallanguage]]) **Field Data** can be thought of as a [[dido:public:ra:xapend:xapend.a_glossary:v:variable]] with some variables having their values set at compile time (i.e., constants) and those during the execution of the procedure. **Note:** [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:start#operation_data| Methods or Operations]] in Objects are procedural in nature, generally represented by a block of code that executes from the top to the bottom, but can be circuitous within the block of code having logical expressions, looping and exceptions to control the flow within the block. 

**Constant Data** is a quality of the data to not be modifiable during the execution of the procedure. There are two broad categories of constants: **[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start#named_constants| Named Constants]]** and **[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start#literal_constants| Literal COnstants]]**. **Note:** **Constants** can be scoped to the particular procedure, the package of procedures or during the execution of the program. 

Often the two terms: **Attribute** and **Property** are used interchangeable in Computer Science because we often use them to describe the fields (i.e., elements) of an [[dido:public:ra:xapend:xapend.a_glossary:o:object]] in an [[dido:public:ra:xapend:xapend.a_glossary:o:oop]]. However, it is useful to understand the difference between the two grammatically:

**Attribute Data** is the quality or object that we attribute to someone or something. For example, intelligence is an attribute of a person. You can not go to the store and buy intelligence, it is an attribute of the individual. Another example would be a planet belonging to a solar system. Planets do not usually exist outside a solar system. 

**Property Data** is a quality that exists without any attribution. Geometric shapes are properties in their own right. They can be used to independently describe many things. For example, a planet or a ball can be described as a sphere((
Sphere, In geometry, the set of all points in three-dimensional space lying the same distance (the radius) from a given point (the center), or the result of rotating a circle about one of its diameters. The components and properties of a sphere are analogous to those of a circle.[[https://www.britannica.com/science/sphere]]
)). A definition of the sphere exists without the attribution to a planet or a ball. Therefore, we say that a planet or a ball has spherical properties. 

In [[dido:public:ra:xapend:xapend.a_glossary:u:uml]], an **Attribute** and a **Property** both represent an structural association between two entities. **Attributes** are most often represented as **Composition**((
The **Composition** is a part of aggregation, and it portrays the whole-part relationship. It depicts dependency between a composite (parent) and its parts (children), which means that if the composite is discarded, so will its parts get deleted. It exists between similar objects. 
[[https://www.javatpoint.com/uml-association-vs-aggregation-vs-composition]]
)), while **Property** is best represented by **Aggregation** ((
Aggregation is a subset of association; it is a collection of different things. It represents a "has a" relationship.
  * It is more specific than an association
  * It describes a part-whole or part-of relationship
  * It is a binary association, i.e., it only involves two classes
  * It is a kind of relationship in which the child is independent of their parent.
[[https://www.javatpoint.com/uml-association-vs-aggregation-vs-composition]]
)). 

According to Lenny Delligatti((
Lenny Delligatti,
__SysML Distilled: A Brief Guide to the Systems Modeling Language__,
FIrst Edition,
Addison-Wesley Professional ,
8 November 2013,
ISBN-13: 978-0321927866
)), "UML Attributes are [[dido:public:ra:xapend:xapend.a_glossary:d:data_type | Data Types]] (e.g., Strings, Integers, etc.) whereas [[dido:public:ra:xapend:xapend.a_glossary:s:sysml]] properties are ValueTypes (e.g., can be assigned computed values)."

There are different ways that **Field Data** can be stored. In most programming paradigms, the **Field Data** is **Mutable**, meaning the values are simply replaced or overwritten with new values. The Object Accessor Methods and responsible for making sure the new values are syntactically and semantically correct. Figure {{ref>mutableData}} graphically illustrates the concept of **''mutable''**. Each time the **''setter''** is called, the contents of the **Field Data** within the **Data Object** are changed. **Note:** There can be **''setters''** for **Attribute** and **Property** data. In the example, the first time the **''setter''** is called, the value of the **attribute** is set to **''2''**, the next time it is **''4''**.

<figure mutableData>
{{  :dido:public:ra:1.2_views:3_taxonomic:4_data_tax:screen_shot_2021-10-31_at_6.18.15_pm.png?700  |}}
<caption>Each time the **''setter''** is called, the value of the **''Filed Data''** is changed.</caption>
</figure> 

However, in DIDOs, most of the **Field Data** is considered **immutable**, meaning that updates and modifications to the **Field Data** are made while not destroying the previous data, but a new entry is made for the Field Data that points back to the original value. See Section [[dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:mmutable]] and Figure {{ref>ImmutableDO}}. **Note:** The concepts of **mutable** and **immutable** are different from those built into C/C++, which describes **immutable** more like constants. 

<figure ImmutableDO>
{{   :dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:screen_shot_2021-05-22_at_11.01.39_am.png?600  |}}
<caption>The Immutable Data Chain where the current value of a **Field Data** points to the previous value.</caption>
</figure>

===== DIDO Specifics =====
[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:05_field:start| Return to Top]]

  : <wrap hi><color red> To be added/expanded in future revisions of the DIDO RA </color></wrap>

<color darkblue><todo @nick #char:2022-03-22>Is this page still under construction?</todo></color>\\
<color blue><todo @char #char:2022-03-22>New Section -- review </todo></color>

/**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
/* To add a discussion page to this page, comment out the line that says 
 ~~DISCUSSION:off~~
*/
~~DISCUSSION:on|Outstanding Issues~~
~~DISCUSSION:off~~