Object Modeling
Connecting Design and Implementation
Why Choose Object Modeling?
In many projects, the issue of "development not aligning with design" is repeated. This stems from abstract designs, insufficient understanding of tasks, and poor communication.
ThingsFlow - Object Modeling fundamentally addresses these shortcomings.
By modeling the State and Activity of the managed Object, it enables design and development to share the same language and structure.
Executable
ThingsFlow’s Object Modeling begins with a clear definition of what is being managed.
First, the entity to be managed—the object—is defined, and then its transitions through various states over time are systematically designed step by step.
When handling an order that contains multiple products,
it is necessary to separately manage information about the order and the product list.
Object Definition
- Objects are tangible entities the system manages.
- They have lifecycles, and their states/attributes change by activities.
- Example: ‘Order’, ‘Product’ as management objects.
State Definition
- States represent lifecycle stages of an order.
- Example: Created when paid, consumed when delivered.
Activity Definition
- Activities cause state/attribute changes.
- Explicit: Payment, Staff Acceptance, Packaging, Invoice, Delivery
- Implicit: Time elapsed, Automated equipment signals
As shown in the diagram above, an object such as ‘Order’ can have states like ‘Created’, ‘Received’, and ‘Delivered’.
Each state transitions based on user activities or system-triggered events. ThingsFlow enables this state transition process to be visually modeled, and APIs are automatically generated based on the definitions of each state and activity. In other words, the modeling itself becomes the foundation of implementation.
The object is placed at the center, surrounded by organically connected state changes and activities. Activities such as ‘Receive’, ‘Inspect’, and ‘Ship’ act as elements that change the object’s state. This process goes beyond simple design documentation, transforming into a form that can be directly executed in the actual system.
Thanks to this structure, developers do not need to reinterpret or redefine requirements. Instead, they can build a stable and consistent backend architecture based on the designed object model.
Usecase
Traditional systems required separate development for each factory or line, even for the same material.
With ThingsFlow Object Modeling, a single material model can be reused across factories,
with only minor adjustments to states, activities, or conditions — eliminating the need for full redevelopment.
Value
The value created by Object Modeling is an innovation in the manufacturing environment.
By securing design assets that can be shared and reused across the organization,
costs are ultimately reduced.
Models directly connect design and development
Stored in Object Portal, reusable across projects
Unified systems across orgs, factories, and equipment
Accurate data structures linked to KPI, analytics, quality