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 [2022/03/22 13:52] char ToDo checked: Is this page still under construction? |
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 11: | Line 11: | ||
| 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 darkblue><todo @nick #char:2022-03-22>Is this page still under construction?</todo></color>\\ | ||
| - | <color blue><todo @char>New Section -- review </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.1647971561.txt.gz · Last modified: 2022/03/22 13:52 by char
