Привет всем!
Здесь приведены некоторые мои рассуждения, прошу только об одном: ваше мнение исходя из вашего опыта

Рассуждения будут касаться вопросов моделирования систем, процессов, объектов, представления знаний о предметной области в информационных системах (простите, это все я буду называть <моделирование>). Эта область очень обширная, но я коснусь только некоторых вопросов, мало или совсем не обсуждавшихся в исследованных мною источниках.

1. "Субъективный" подход к <моделированию>.
Ясно, что любое <моделирование> выполняет человек, поэтому у разных проектировщиков возникают свои ассоциации о предметной области, каждый наделяет систему своими свойствами, выделяет видимые ему процессы, описывает по своему свойства объектов, т.е. налицо "субъективность". Это нормально и это не плохо, хотя иногда приводит к проблемам непонимания между заказчиками, постановщиками, проектировщиками и кодерами. В некоторых случаях для решения этих проблем используют общепринятые мнения, разрабатываются рекомендации, вводят и четко определяют "термины" и "понятия", описывают и вводят стандарты и протоколы.
Другой подход: "идти от требований". Т.е. четко определить конечную цель <моделирования>, для чего оно выполняется, какие результаты надо получить (данные, отчеты, графики, расчеты, ..., регистрация, учет, ..., токи, напряжения, ..., быстродействие, аппаратная база, ...) Далее уже неважно как проектировщик спроектирует <модель>, т.к. он понимает конечный результат и он будет получен. Здесь важно, чтобы максимально были ясны требования, когда же это не так (заказчик пока точно не знает чего хочет), этот способ плохо подходит.
Это коротко, основная мысль, хотя и не все..

2. Методики <моделирования>.
Существуют различные методики <моделирования>: ООП ( "опять это ООП", Буч), автоматное (более подходит для процессов: "состояния", "входные и выходные воздействия"), событийное, алгоритмическое, а также различные комбинации этих и других методик.
Однако все исследованные мною методики плохо учитывают или не учитывают "модели времени" (см. п.4), "статичность и динамичность" (см. п.3) представления данных и самой <модели>. В результате ООП, которая "наиболее близко отражает реальные объекты", оказывается "не близко" и "не отражает РЕАЛЬНЫЕ объекты", т.к. оно не отражает их поведение и см. далее.
Эти методики плохо подходят для "делящихся" и "сливающихся", "объединяющихся" объектов и процессов. Плохо подходят для описания "фазовых превращений" объектов (модель "личинка-гусеница-куколка-бабочка"). Плохо подходят для описания принадлежности объекта к разным описательным сущностям (некоторые называют это "классами"), представлениям знаний об объекте (Иванов: работник предприятия, он же — муж, он же — отец, сын, он же — специалист широкого профиля и т.п.), здесь опять вклинивается "субъективный подход" (см. п.1)

3. Статичность и динамичность
Начну с примеров. Разработана база данных, в которой ведется некий учет. Ясен динамический характер ведения учета, данные заносятся в определенные моменты времени, используются (просматриваются, экспортируются) тоже в определенные моменты времени. Поменялись требования, изменилась структура БД, теперь надо возможно переработать все модули (программы, протоколы и стандарты), которые используют эту базу. Виден динамический характер <модели> базы данных.
Другой пример. Разработана огромная, сложная, система с "кучей" модулей-подмодулей, множеством средств хранения данных (базы данных, файлы различных форматов, распределенные данные в сети, контроллеры учета и регистрации и т.п.). Все это четко описано, регламентировано, стандартизировано, определены меры в случае изменения требований. Здесь виден динамический характер самой системы, а также динамический характер модели.
Так вот, различные методики <моделирования>, средства проектирования, теории и парадигмы, по моему мнению, не позволяют четко описать как работать с динамическими <моделями> знаний. И каждый проектировщик по своему выходит из ситуации. Т.е. сама модель очень хорошо описана, стандартизирована и понятна (хорошо бы) всем участникам проектирования, пользователям, субразработчикам, НО плохо описан динамический характер модели, как поступать в случае изменений системы, изменения поведения сущностей модели и т.п. Понятно, что нельзя же предсказать как поведет себя <модель>, ведь неизвестно же какие будут требования.
Но можно выйти и из этой ситуации, "в случае часто меняющихся требований" (не посредством XP), есть одна идея.
Но нужно не просто учесть изменяющийся характер модели, нужно также, чтобы можно было вернуться к старой модели ("назад в будущее"), т.е. посмотреть на систему в тот момент времени (с данными актуальными на тот момент и структурой и состоянием системы на тот момент).
Зачем?
Во-первых, чтобы просто посмотреть, "что же там было и как это было". С новой <моделью> представление будет неверным.
Во-вторых, чтобы попытаться применить текущие процессы, объекты, данные на "старую модель", либо старые процессы, объекты, данные в новой модели (самое простое — это конвертирование).
На этом пока остановимся..


4. Модель времени
Не понимаю, почему в различных методиках очень плохо рассматривается модель времени. В результате это приводит к неправильной постановке задаче и плохой реализации динамических систем, процессов.
Классифицирую следующие модели времени: (напоминаю, что речь идет о представлении времени в информационных системах)
— "непрерывное время", реальное. Часто используется при моделировании физических, химических процессов, биологических и эволюционных моделях;
— "событийное время". Т.е. когда важны только моменты времени при наступления определенных событий. Используется, например, в системах учета и регистрации;
— "пошаговое время". Когда важно все состояние системы в четко заданные моменты времени (шаги, этапы). Например, модель игры "Жизнь", различные компьютерные игры с пошаговыми стратегиями (не знал как точно выразить).
— "периодическое время". Что то среднее между "пошаговым" и "непрерывным" временем.
Предполагаю, что полезно использовать и различные комбинации этих моделей.

Пока остановлюсь на этом, жду ваших мнений. Стоит ли это дальше обсуждать.

Спасибо

P.S. Буквально недавно произошло, высказывание одного электронщика схемника: "У вас программистов все не так, и один — не один, а два, потому что есть еще ноль!"