Most of the extrinsic properties are easily identifiable from the system. For example, if we want to do an office system (OA, Office Anywhere), then we can be sure of several facts:
(1) This system is always used by some office members;
(2) This system always provides the functions required for the daily work of the above-mentioned personnel;
(3) This system includes both the mapping of real work and the Some try to change the e-demand of current jobs.
These few facts are obvious and are determined by the system itself. Therefore, we can find some components of the system:
(1) To observe the work of office members, so functions such as mail, schedule, attendance, and approval are required;
(2) Considering electronic management, it is necessary to press release, message communication, and document management. , discussion board and other functions.
Based on this, we can quickly describe the architecture of this system, as shown in Figure 2.
But these are just some of the common functions, that is, everyone needs. As your investigation of office members progresses, you are bound to face specific needs, such as:
(1) Manpower, i.e. files, recruitment, training;
(2) Marketing, i.e. customers, activities;
(3) Operations, i.e. assets.
Accordingly, we further supplement the architecture of this system, as shown in Figure 3:
Looking back on the basis for our classification of these "functional modules", we can name the three main parts of the system, namely "daily office", "electronic management" and "specific business", as shown in Figure 4 Show:
The evolution relationship of several architecture diagrams is not difficult to understand, but there is a little difference: the version number in the title of Figure 2 to Figure 3 is "v0.0....x", while in Figure 4 it is "v0.0.0" .1". A deeper question is: why is it considered that the former is not even "a staged version of an architecture", while Figure 4 can be called "a most elementary version of an architecture"?
We can rely on various perspectives to observe the system and add various classifications to arrive at the "v0.0....x" version of the architecture shown in the first two figures. However, these methods of "recognizing" and "separating" will not help you get several key concepts in "v0.0.0.1": daily office, electronic management and specific business. The key difference is that the real-world system (and I mean the client, office member, or department that needs you to develop the system) doesn't present these three concepts to you until you make these definitions; unless you do, Otherwise these concepts would not have any effect on the practice of the real system; unless you isolate the concepts, no one will find out that the real system is indeed intrinsically driven by these laws.
But what kind of way of thinking makes you: "discover" these three knowledges from the real system, and set them as such concepts, and set these concepts on the basis of others?
Or ask: why do you make some settings in the system instead of just stating the actual system
fact?
As mentioned earlier, some specific methods of understanding the system are generally similar to the method tree of a cognitive process shown in Figure 5.
We have in fact only discussed a very small part of cognitive behavior. "Identification" and "distinction" are lower-level methods in this tree. They can obtain systematic knowledge but cannot generalize them, distinguish differences but cannot sort them out, and build functional modules but cannot deduce them. Because induction (concepts), sorting out (relationships), and deduction (logic) these architectural activities require higher-level thinking methods.
In reality, based on the computer system we are facing, most of our system abstraction and modeling process will use the cognitive method of "separation". For example, we plan known requirements into items, then classify them into categories, and then sort out subsystems, modules, services, and plan solutions for servers, clusters, etc. Distinguishing the components, elements, and relationships in the system is the basis of these activities.
And that's just part of the system. If we can "architecture" the system based on this, we can only be lucky: this system is in most cases a number system, so as mentioned above - it can be based on the abstract concept of "number value". "separately".
Or conversely, we cannot architect systems because we cannot build knowledge of systems in this way.