PS: This article is a bit messy and tends to be some personal
thinking for Elemental Modeling.
In a nutshell, looking at various languages, their grammatical components are
aggregated to form a set of key concepts. —Leonard Talmy
In the previous series of articles on the cloud R&D system, we have been abstracting, defining, and modeling various software development elements such as requirements and codes. As this abstraction process deepens step by step, we find that we also need to do a layer of abstraction for modeling.
Modeling is a really fun thing, and we’re always abstracting, abstracting, abstracting, and defining, defining, defining. As we continue to go deeper into the design of software architecture, we will also continue to try a series of different methods, such as my colleague @小小 semicolon in the article ” Modeling Method Metamodel: How to Design a Modeling Method ” “In the article, a brief introduction to different modeling methods, and related disassembly and analysis are carried out.
Each modeling method has its own advantages and disadvantages, the trade-off between accuracy-time-cost-maintenance cost, and also depends on different system types and depends on our experience. As a result, developing and implementing a new modeling approach is a difficult process that necessitates thorough testing and validation.
Coming back to this article, my intention was to find some commonalities in modeling methods. Exactly, combined with some recent thinking about the relationship between models and concepts.
From human language to programming language
Going back to Cognitive Semantics’ distinction between languages, languages can be divided into two main types according to the typical forms of lexicalization used to refer to entities and substances:
- Object-dominant languages, languages that tend to use nouns, most languages fall into this category
- Action-dominant language is a language that tends to use verbs.
English is, by this definition, a thing-dominant language, as it tends to use nouns to refer to the tangible materiality of physical entities. Mapping the above human languages with programming languages, we get the current mainstream programming paradigm:
- Object-Oriented Programming.
- ~~Functional Programming (TBD)~~.
PS: In terms of meaning, the contrast between action-led languages and functional programming is not so appropriate, just GET some inspiration from the book. The accuracy of these needs to be verified in the future.
In terms of similarity, the two dominant languages in different ways are more like two different driven design paradigms: model-driven and event-driven.
Model-driven vs event-driven
The following is the Wikipedia definition of event-driven:
Event-driven programming is a programming paradigm in which the flow of a programme is governed by events such as user actions (mouse clicks, key presses), sensor outputs, or messages delivered from other programmes or threads, according to Wikipedia's description.
And for model-driven, it’s developed so well that it can be turned into a branch of engineering:
Model-Driven Engineering (MDE, Model-Driven Engineering) is a branch of software engineering that expands models and modeling to all aspects of software development, forming a multi-dimensional modeling space, thereby establishing engineering activities on the mapping and over the conversion. The basic principle of MDE is to treat the model as the first entity and all software artifacts as models or model elements.
From a software engineering point of view, model-driven is quite mature – we can use the model as a starting point, and then build a layered architecture, boundaries, etc. around the system. At the same time, it can also use events as an auxiliary input method to help improve the model design of the entire system when adopting a domain-driven design approach.
PS: From this perspective, we can also build a complete software development model around event-driven. Going back to the language communication itself used by humans, we record sentences composed of a series of content such as verbs and nouns. It is quite interesting to regard sentences as use cases one by one. At the same time, since we can store models, it’s okay to store events, whether it’s code or something else is another story.
Going back to the point of object orientation, modeling becomes a very interesting thing.
Modeling “Modeling”: From Concept to Model
Back in the software system, we developed, the core components of the system are composed of concepts. How well we understand systems, in a cognitive sense, also depends on how well we understand and use these concepts. We only had a few notions in the early phases of system design. As the system evolves, we introduce more and more concepts and organize them in a way that we understand. Inspired by the book Cognitive Semantics: A Concept-Building System, I tentatively explore their previous connections.
From a semantic point of view, if concepts from patterns within specific conceptual categories, these conceptual categories can be called schemas categories. Schema categories are clustered in broader, complete systems of conceptual structures, which can be called schemas systems. By the way, in terms of classification, common schema systems are:
- Configurational structure. It includes the schematic structure or geometric outline of space, time, and other qualitative domains that can be expressed in the form of closed classes (which can be referred to as entities).
- Perspectives. The perspective is used to observe this class of entities, and can also be expressed in closed-class form.
- Note the distribution of attention. It consists of attention patterns of different intensities assigned to the referent or scene.
In model-oriented software development systems, most of them are schema systems that can be attributed to configuration structures. For example, when implementing a software system, entities are used to represent these concepts, and the corresponding implementation method on the code is the model. By combining a variety of different schema categories, there are many different software modeling methods, such as domain-driven design, which combines domain, state of boundedness, etc.
Modeling method: “fact-based” software modeling
PS: For facts, from the perspective of language, it may be more appropriate to use documentary and narration.
All software development is driven in the direction of satisfying user concerns: capturing user concerns, designing the system to implement those concerns, and testing whether the system satisfies those concerns.
Again, let’s pull the camera back, back to software development, and take a preliminary look at some of today’s software modeling methods. They need to build models around these “facts” in order to “standardize”.
PS: The “facts” here refer to objective information, such as events, use cases, credentials, and a series of elements that do not depend on the human experience. At first, I tried to use the term representation, which is defined as a system of symbols obtained by transforming objective information. In a sense, the use of the word “fact” also appears to be inaccurate.
Use-Case-Based Modeling: Use-Case-Driven Design
Use Case Driven Design is an “old” software engineering design method. Among them, a use case (UseCase) is a textual description of the interaction process when an actor uses a function of the system. Use case analysis will design the system in the following ways:
- Look for use cases and detail them.
- Design each use case.
- Design and implement each class.
- Test each use case.
In this process, the use case is the “fact” here, and around this known “fact”, experienced developers can also rely on this to conduct standardized development.
Event-Based Modeling: Event Storming and Domain-Driven Design
In domain-driven design, using an event storm to design a system is a more modal engineering method. One of the core elements of the idea is that events are keyframes for system state changes. An event storm consists of three main steps:
- Brainstorm to identify domain events.
- Identify event triggers (decision commands).
- Identify aggregates (service bearers).
In this process, the event is the “fact” here, revolving around this known “fact”. Experienced developers can also use this to build a reasonable system architecture.
Credential-Based Modeling: Fulfillment Modeling
Fulfillment modeling is a relatively new modeling method that designs systems based on credentials. Its core elements are: as a business credential, there is only creation, no modification, and deletion. The key steps are as follows:
Find the contract context and clarify the parties involved in the contract;
- Find the main performance items of the contract, and find the vouchers according to the four-color modeling;
- For the main performance items, look for a breach of contract, set up new performance items, and search for vouchers according to four-color modeling;
- In this process, the evidence is the “fact” here, around this known “fact”. Experienced developers can also use this to build a reasonable system architecture.
modeling modeling
In a sense, the process of finding these “facts” is the process of representing the state of the system.
Representation is the way in which information is presented in the mind, the way in which information is recorded or expressed, a formal system that can clearly express certain entities or certain types of information, and a number of rules that explain how the system performs its functions.
So, the steps around how these “facts” are modeled can be abstracted as:
- Determine state (or data) based on determinable “facts”.
- Orchestrate state with the help of patterns.
- Mapping and filtering to remove impact factors. Separate the elements of change to get the basic concept.
- Refine concepts to get model elements and behaviors.
- Concept clustering. Context Boundary Division
This procedure is comparable to that of data processing: collect-map-filter-reduce, and so on.
Summary
A model is just our mapping and understanding of things. This article is just some preliminary thoughts on modeling~, which needs to be further improved in the future.
