Draft discussed and generated with ChatGPT, then edited through personal understanding.
This article is intended as a learning record.

Mapping Semantic(Meaning) to Object Models

The previous article only explained the basic definitions of the elements in Object-oriented programming, but in practice, it usually starts from mapping Semantic into the required program.

Various AI tools (conversational AI) can directly perform the task of mapping Semantic into object models.

1. Semantic(Meaning)

In this document, Semantic(Meaning) refers to 「the meaning expressed by language」.

1.1 Semantic(Meaning) and “Business Semantic”

Semantic(Meaning)

🎯 Metaphor

Semantic is like the intention of a letter — although the words are clear, the real intent depends on context, the recipient’s background, and the situation.

📘 Explanation

Semantic refers to the analysis of a statement’s intention, logical structure, and function.
Requirements can come from:

• Verbal descriptions (requirement discussions, etc.)
• Analysis or planning documents (presentation summaries, specification drafts, planning briefs)
• Specification documents (API specs, standards, contract models)

Business Semantic

「Business Semantic」 refers to the linguistic logic used within a company to express 「business concepts」. For example, each department may have different interpretations and focuses regarding an order.
The goal is to transform 「requirements」 into software as expected through 「consistent understanding」.

Establishing Consistent Semantic

In collaborative environments, it’s necessary to use clear mechanisms to 「align」 Semantic and maintain 「consistency」:

• Glossary:
  Based on usage scope, define nouns and terminology such as customer, order, approval, etc., as reference standards.
  Use consistent terminology across names, from requirements to models, for easy identification.

• Collaboration Tools:
  Use interactive tools (like Figma, Miro, BPMN workflows) for cross-department validation, allowing participants to directly manipulate and simulate models. This process helps gradually align Semantic within the model.

Semantic from High-Level to Low-Level Concepts

1.2 Mapping Semantic to Model Elements

Map Semantic to model elements and align (bidirectional mapping).
After mapping, validate both directions.

Classification of Semantic and Corresponding Model Elements

Example: 「A user logs into the system. If the account is already bound to Google, they can log in quickly; otherwise, verification is required.」

| Semantic Type | Semantic Fragment | Description | Corresponding Model Element | |---------------|----------------------------|--------------| | Entity | Account (User) | Has state (bound or not) and behaviors (login, bind) | Class | | Behavior | Login, Quick Login, Verify | Each action has its own logic | Method | | Attribute | Is Google Bound | Affects quick login logic | Attribute (value type) | | Constraint | If not bound, must verify | Logic branch in method | Conditional logic (if-else) |

Identifying Class, Abstract Class, Interface

「Entities」 in Semantic can be converted into Class or Abstract Class.

Identifying Method

「Actions」 or 「described actions」 in Semantic can be converted into 「methods」.
Consider:

• The 「subject」 of the action: Class/Abstract Class/Interface
• The action and its conditions: reflected in method names and logic
• Related or dependent nouns describing 「conditions」 or 「results」: variables, parameters, return values, possibly representing data or another Class
  • Use UML relationships for dependent or associated Class

Identifying Constructor

If Semantic contains 「create」, 「new」, or 「generate」 + 「entity」, it usually maps to a Constructor.

Identifying Attribute

Attributes can be:

• Class: entity, using UML relationships
• Value: data, non-entity
• Collection: contains multiple entities or values

1.3 Determining UML Relationships from Semantic

In Semantic, when both subject and object are entities, they correspond to UML relationships.

Example Steps

Two entities have an 「instance relationship」:

1. Is it a 「one-way」 「use」, 「trigger」, or 「temporary relationship」?

   • Yes → Use Dependency (meaning “use”).
   • No → Continue.

2. Does it imply a 「part-whole」 or 「composition」 meaning?

   • No → Use Association (persistent relationship, lifecycle independent).For example, it is used in properties that can be nullable.
   • Yes →
     • Can the referenced entity be shared by multiple entities?
       • Yes → Use Aggregation (meaning 「has a」).
       • No → Use Composition (meaning 「is a part of」, child cannot exist independently).

Two entities have a 「Class hierarchy」 relationship:

• Is the meaning 「is a kind of (is a)」?

  • Yes → Use Generalization.

• Does one entity 「provide concrete implementation」, 「realizes」?

  • Yes → Use Realization.

Other cases:

1. If multiple conditions apply

   • Check for potential hidden entities.
   • If yes → separate them and re-evaluate relationships.
   • If no → discuss or clarify meanings to resolve conflicts.

2. If ambiguous

   • Use Association temporarily; refine later or discuss.

Is there a strict priority rule for determining relationships? There are multiple valid answers—it may depend on how quickly you can infer from Meaning or existing definitions, or by referencing existing modules or known design patterns.

Mapping of UML Relationships and Entity Types

1.4 Workflow Separation by Semantic Concept Layer

1. Concept Layer

• Source: User stories, interview notes, requirement discussions.
• Input Conditions:
  • Sentences contain clear entities and action meanings.
  • 「Who did what」 can be identified in conversations or records.
• Output: Semantic Marking Table: Entities, actions, data, and constraints.

2. Alignment and Transformation Layer (Analysis & Planning)

• Source: Semantic classification table, glossary, temporary notes, prior designs.
• Input Conditions:
  • Entities mapped to model elements (Class, attributes).
  • Action meanings transformed into methods, I/O data, and constraints.
• Cases:
  • If Semantic has unmapped elements → return to Concept Layer.
  • If data types are unclear → use generic types (string).
  • Migration of existing models corresponds to design and process.
• Output: UML draft diagrams.

3. Design Layer

• Input Conditions:
  • All Semantic within the scope classified (Class / attributes / methods / relationships).
• Output: UML documents or equivalent design documents.

Tools and Document Descriptions

Thank you for reading!