dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:05_field:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:05_field:start [2021/11/07 01:22] nick ↷ Links adapted because of a move operation |
dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:05_field:start [2022/05/27 19:41] (current) nick grammar |
||
|---|---|---|---|
| Line 7: | Line 7: | ||
| **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. | **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#named_constants | Named Constants]]** and **[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility#literal_constants | Literal COnstants]]**. **Note:** **Constants** can be scoped to the particular procedure, the package of procedures or during the execution of the program. | + | **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: | 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 a 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. | + | **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(( | **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]] | 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 have spherical properties. | + | )). 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**(( | 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**(( | ||
| Line 21: | Line 21: | ||
| [[https://www.javatpoint.com/uml-association-vs-aggregation-vs-composition]] | [[https://www.javatpoint.com/uml-association-vs-aggregation-vs-composition]] | ||
| )), while **Property** is best represented by **Aggregation** (( | )), while **Property** is best represented by **Aggregation** (( | ||
| - | Aggregation is a subset of association, is a collection of different things. It represents has a relationship. | + | 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 is more specific than an association | ||
| * It describes a part-whole or part-of relationship | * It describes a part-whole or part-of relationship | ||
| * It is a binary association, i.e., it only involves two classes | * 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 its parent. | + | * 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]] | [[https://www.javatpoint.com/uml-association-vs-aggregation-vs-composition]] | ||
| )). | )). | ||
| Line 38: | Line 38: | ||
| )), "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)." | )), "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 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** is 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''**. | + | 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> | <figure mutableData> | ||
| Line 45: | Line 45: | ||
| </figure> | </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 See Figure {{ref>ImmutableDO}}. **Note:** The concepts of **mutable** and **immutable** are different from those built into C/C++, which describes **immutable** more like constants. | + | 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> | <figure ImmutableDO> | ||
| Line 55: | Line 55: | ||
| [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:05_field:start| Return to Top]] | [[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> | ||
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||
dido/public/ra/1.2_views/3_taxonomic/4_data_tax/08_objects/05_field/start.1636262536.txt.gz · Last modified: 2021/11/07 01:22 by nick
