Architecture

From CaseTalk Wiki
Revision as of 03:45, 23 May 2022 by Marcow (talk | contribs) (Created page with "= Architecture = There's simply to much to be said and written about architecture. The short version is architecture is the work of the architect who will look at the system as a whole to design the workings of the whole. From this definition, this page describes topics which are a little bigger than a single screen, or function in CaseTalk, hopefully allowing the reader to understand the bigger picture. == Information == The method FCO-IM is build on the premise that...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Architecture

There's simply to much to be said and written about architecture. The short version is architecture is the work of the architect who will look at the system as a whole to design the workings of the whole.

From this definition, this page describes topics which are a little bigger than a single screen, or function in CaseTalk, hopefully allowing the reader to understand the bigger picture.

Information

The method FCO-IM is build on the premise that data structures need to be communicated. And the key to building data structures is not to build an abstract model, but to capture the concrete communication in the first place.

Employees who work together and communicate, will do so in a concrete manner. When work needs to be discussed, they will rarely use 'a customer', rather they'll refer to a specific customer. In this facts are exchanged. For IT systems to support their work properly, to give employees the tools to manage these facts, and communicate them in in automated fashion with collegues, these systems should align with the communication itself.

Bottom Up

Capturing the communication on a concrete level is a so-called bottom up approach. The very detailed bottom level results in solid and high quality information, and data models, but lack the top-down support.

Even though bottom-up approach is mandatory for CaseTalk to perform model-to-model transformations, architects who describe the whole also need more global functions. Such functions all aspects that come with it, is called the top-down approach.

CaseTalk supports this using Concepts, Containers and Relations. A customer can be entered as a concept, and defined using a business definition, before facts about the customer are communicated, captured and modelled. This is a very top-down approach. Similarly Containers can be created containing the customers, employees and consultants, and whatever more. Again, a top-down approach.

Some hi-level information needs to be drilled down to reach the levels where bottom-up end. This can be accomplished using various methods.

  1. Link concepts and containers to each other
  2. Link concepts and containers to fact/object and label types
  3. Add Fact Expressions to concepts to promote them to Fact/Object types.

Level-0

Architecture recognizes various levels of details. The typical top-down approach would start at a level-0, whereas the bottom-up with the concrete examples is considered a level-4.