Modeling 101: What, Who, How, When, Where

Objective

Taking a leaf from Wittgenstein who once defined philosophy as a synopsis of trivialities, it may be interesting to supplement the Book of Fallacies and the Reflections for the Perplexed with some trivial distinctions that could be more easily agreed across the system engineering community.

What’s in a Model (Norman Rockwell)

As far as systems engineering is concerned, basic trivialities should focus on systems, architectures, and engineering processes. And as a mother of all, yet all too often ignored, a clear understanding of problems and solutions.

It must be noted that trivialities are not be taken for definitions; their only objective is to provide a sound and undisputed basis for robust definitions that could then be used to build clear and useful principles. As a corollary, one should not try to extend the suggested trivialities but to trim and distill their meaning to an undisputed core.

Systems & Components

1. To begin with the scope under consideration, systems can be first understood as a collection of interacting agents, devices, and computers.
2. Within that scope, a computer system is a container of software components, some of them with the capability to interact with the environment: users, other computer systems, or devices.
3. Finally, software components are symbolic objects representing agents, objects, or activities identified in the business environment.

Enterprise Architectures & Business Processes

1. Enterprises are social constructs with continuous identity.
2. Enterprise architectures describe enterprise’s assets and organization.
3. Business processes describe how enterprises interact with their environment.

Enterprise Architectures & Information Systems

1. Information systems are meant to manage the symbolic representations of enterprise environments, assets, processes, and commitments.
2. The relationship between enterprise and systems architects is one of customers and providers.
3. Enterprise architecture should provide the basis of requirements for systems architectures.

Engineering Processes & Models

1. Engineering processes describe how to design and build computer systems.
2. Engineering processes begin with requirements capture and wind up with the deployment of software components.
3. Models are intermediate artifacts used along engineering processes.

Problems & Solutions

1. Business problems are set by enterprise environments and their solutions are not to be found in systems functionalities.
2. Functional problems are defined by business solutions and are meant to be met by software architecture.
3. Technical problems are defined by functional solutions and are meant to be met by technology and programming solutions.

Further Readings

WHAT IS TO BE REPRESENTED

• Objects
• Physical Objects
• Non Physical (aka Symbolic) Objects
• Digital Objects
• Features
• Operations
• Activities
• Actual Activities
• Symbolic Activities
• Objects & Aspects
• Domains
• Collections
• Containers

WHO IS INTERACTING WITH SYSTEMS

• Agents
• Roles
• People should not be Confused with their Personas

HOW TO REPRESENT OBJECTS AND ACTIVITIES

• Symbolic Representations
• Individuals
• Persistency Units
• Execution Units
• Focus: Individuals in Models
• Links
• Functional Connectors
• Structures
• Rules
• Actual Rules
• Symbolic Rules
• Making the Rules
• Derivations
• Focus: Rules & Architecture
• Abstractions
• Abstraction Layers
• Partitions
• Specialization vs Generalization

WHEN SURROGATES ARE TO BE PROCESSED

• A Time For Every Purpose
• Events
• Time
• Real Time Activities
• Synchronization (objects)
• Synchronization (activities)
• A Brief Ontology Of Time
• Event Oriented Analysis & Object Oriented Design

WHERE SURROGATES ARE TO BE PROCESSED

• Objects Location
• Activities Location