A class represents a blueprint for objects. It’s a template for creating instances with a specific set of attributes (properties) and behaviors (methods).

Properties are characteristics of a class. They can be simple attributes (like a string, number, date) or associations (relationships with other classes).

Attribute: Intrinsic properties of the class (e.g., a person’s name or age).

Association: A relationship between two classes. There are different types:

Split and Join Names:

In ADCS, field names are concatenated and shortened with underscore (‘‘). Start by splitting these names at each underscore (‘‘) and then join them with a space. For example, ‘Reporting_Amount’ becomes ‘Reporting Amount’.

Resume Original Words from Abbreviations:

Convert abbreviations into their full forms based on context. For instance, ‘JE’ should be expanded to ‘Journal Entry’. This step requires domain knowledge to accurately interpret each abbreviation.

Reinterpret Data Types:

Where ADCS uses specific data types and representations (e.g., ‘Decimal’ with representation ‘%22.4f’), redefine these to more semantically meaningful types in AWI Semantic model. For example, ‘%22.4f’ as ‘Decimal’ becomes ‘Amount’ in AWI Semantic model, clarifying its semantic meaning as a monetary value.

To refine the descriptions according to ISO 11179-4 standards, they should be clear, unambiguous, singular, and stand-alone. The current descriptions have issues like embedding procedural information, relying on external references, and not being self-contained. Let’s refine a few examples:

These refined descriptions are singular, precise, and stand-alone, adhering to ISO 11179-4 guidelines. They avoid procedural details and external references while clearly stating the essence of each concept.

Identify Repeated Field Patterns:

Look for sets of fields that frequently appear together in ADCS. For example, a pair like ‘Reporting_Amount’ (Decimal, %22.4f) and ‘Reporting_Currency_Code’ (String, %3c) is a common pattern.

Create Reusable Structures:

In AWI Semantic model, define these repeated patterns as reusable structures or classes. For instance, an ‘Amount-Currency’ class could encapsulate fields for monetary amount and currency code, reflecting their repeated use across different contexts.

Class and Property Structuring:

Use the revised names and data types to structure classes and properties in AWI Semantic model. Ensure that each class and property reflects its real-world entity or concept accurately.

Handling Associations and Specializations:

For fields forming associations (like reference keys), clearly define their relationship types (association, aggregation, composition) in AWI Semantic model.

Where specialization is evident (e.g., subclasses for different types of activities), define these relationships, ensuring inheritance from appropriate superclasses.

Finalizing the AWI semantic model:

After restructuring the fields with semantic names and data types, and defining classes with their properties and relationships, review the AWI semantic model for completeness and accuracy.

Ensure that the AWI semantic model is a true representation of the original semantic intent of the ADCS table, with clear, meaningful class structures and relationships.

By following these steps, you will be able to transform the flat, abbreviated structure of the ADCS table into a more meaningful and semantically rich AWI semantic model, facilitating better understanding and utilization of the data.

Preliminary tasks for semantic model resumption involve understanding and modifying the structure and naming in the ADCS data.

In financial systems, the “Monetary Amount” data type is crucial, consisting of:

The Currency Code Class is introduced to enhance this structure:

Understanding these components is vital for ensuring precision in financial transactions.

For handling multiple currencies, a “Multicurrency Monetary Amount” class becomes essential. Here’s how it can be structured:

Each amount is paired with its corresponding currency code, offering a comprehensive view of financial transactions in various currencies.

Representing this in UML using PlantUML script:

Even though above class diagram is a straight implementation of ADCS table structure but introducing Currency Code is more meaningful when we define Monetary Amount Class.

Each monetary amount type in Multicurrency Monetary Amount class is associated with a Currency Code instance, representing the respective currency type.

Following UML class diagram is more clear that Monetary Amount class is defined with attribute amount and a

Each “Amount” is a Decimal, and each “Currency Code” is a String. This design encapsulates the complexity of handling multiple currencies in a single class.

To further enhance the Multicurrency Monetary Amount class, an association with another class, Currency Code, is established. The Currency Code class has the following attributes:

Each currency code in the Multicurrency Monetary Amount class is defined as an association, referencing the Currency Code class. This association is crucial to retrieve information about the minor unit, ensuring precise financial calculations and compatibility with international standards.

Designing for multicurrency support requires careful consideration of both the monetary values and their associated currencies. By ensuring each amount is paired with a relevant currency code, financial systems can accurately manage and report monetary data across different currencies.

In this scenario, we assume ‘Activity’ as a superclass that represents general actions or events within a system. This superclass might include attributes like ‘ActivityID’, ‘Timestamp’, and ‘UserID’.

Now, let’s define a specialized class:

Superclass: ‘Activity’

L: level, M: multiplicity

Specialized Class: ‘Created’

L: level, M: multiplicity

In the GL details context, ‘Created’ represents a specific type of activity related to GL entries. It inherits common attributes from ‘Activity’.