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

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

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

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

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


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

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

Спасибо

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

Это всё из области логической архитектуры приложений. Проблемы, которые ты перечислил, успешно решаются. Например при помощи SOA и BPM. Я имею в виду логическую архитектуру, а не физическую. Последняя всегда скатывается к вопросам web services, security и прочей технической лабуды, не имеющую никакого отношения к бизнесу. Сначала надо понять бизнес. Понять бизнес-сервисы (наприме, "Зарплата", "Бухгалтерия"), бизнес-процессы ("Начисления зарплаты", фантазия закончилась ), бизнесс-операции ("Расчёт зарплаты", "Выплат денег из кассы", "запуск ядерного реактора"). Если начать с бизнес-объектов, то там же вы и закончите (это принцип объектно-ориентированного анализа и архитектуры). Вот пример, в систему вводиться "Человек" как бизнес-объект (и это в реальном проекте, который кстати провалился). Зачем? Из ОО понятно, что это есть некое обобществление. С точки зрения бизнеса — это полный бред. Почему? Бизнес не имеет дела с человеком, он имеет дело с работниками, кандидатами на работу, провинившимися, покупателями, частными предпринимателями. Всё это бизнес-объекты. Увольняем Буча. Он не писал свою книгу во времена интеграции приложений и бизнес процессов. Он писал приложения, которые всегда были одни во вселенной и не должны были взаимодействовать с другими системами. Кроме того ОО требует чтобы все бизнес объекты были известны наперёд. Это возможно, но нельзя знать все бизнес процессы наперёд. Помещаем части бизнес-процесса в объекты и всё, систему можно выкидывать на свалку, поскольку процессы меняются часто и почти всегда различны в разных фирмах. Зарплату и ту везде по разному начисляют. 1С потому и хорош, что позволяет быстро адаптироваться под требования заказчиков, но это не есть правильное решение с точки зрения логической архитектуры.
Субъективности при моделировании можно избежать очень простым способом — не давать этим заниматься программистам, точнее тем, кто умеет писать код и знает хоть что-то про UML и ОО. Найдите бизнес-аналитика, да-да того самого, который знает бухгалтерию, финансы, кадры, или того кто знает устройство ядерного реактора и как он работает в деталях. То есть человека, который точно значет, что такое "покупатель", "бухгалтерский счёт" и пр. бизнес-объекты. Он всегда говорит на том-же языке, что и пользователи, и потому субъективности быть не может. Далее встаёт проблема взаимодействия бизнес-аналитика и программиста. "Покупатель" для бизнес-аналитика — это "человек, готовый заплатить деньги за услуги или товар", для программиста... что угодно... с вариациями, например C++ класс Customer, запись в Oracl-овой таблице Customer, web-service Customer (за это убивать надо, ну где вы видели, чтобы бизнес обеспечивал сервис под названием "Покупатель" ). Решением несоответствия между реальностью (точка зрения бизнес-аналитика) и "матрицей" (точка зрения программиста, где "покупатель" может прыгать и летать как Супермен ) должен заниматься человек, в задачу которого входит то, что на Западе называют "aligning IT to Business". То бишь заставляет IT смотреть на мир с точки зрения бизнеса (убирает субъективность, а заодно приводит к бизнес-ориентированной методологии разработки ПО, всё остальное — технические проблемы, и потому не интересные). Человек такой должен разбираться в технической архитектуре, а также в бизнес архитектуре. То есть нечто вроде бухгалтера-программиста. И такие люди есть. Да, и они не пишут код, поскольку это влияет на восприятие реальности.
Процесс обычно выглядит так: смортим что нужно закачику, определяем бизнес-процессы (если у вас есть желание их изменить, то вам нужно доказать, что то, как владелец фирмы делает бизнес сейчас — это неправильно, а вы готовы к этому?) и автоматизируем их Конечно для этого нужна инфраструктура, но это технические детали и потом не интересны (если очень хочется то смотрим WfMS, BPMS и пр.).
Да, "фазовые превращения" — это и есть бизнес процесс. "Запустили реактор" -> "Пустили козла в огород" -> "Пытаемся остановить цепную реакцию"


СВ>3. Статичность и динамичность
СВ>Начну с примеров. Разработана база данных, в которой ведется некий учет. Ясен динамический характер ведения учета, данные заносятся в определенные моменты времени, используются (просматриваются, экспортируются) тоже в определенные моменты времени. Поменялись требования, изменилась структура БД, теперь надо возможно переработать все модули (программы, протоколы и стандарты), которые используют эту базу. Виден динамический характер <модели> базы данных.

Вот тут то и встаёт вопрос о том, кто владелец данных Если все модули владеют "Бух. счётом" (потому что в бухгалтерии всё связано с ним), то надо будет переписывать все эти модули. А как насчёт того, чтобы определить владельца? Одного, который владеет "Бух. счётом". Тогда, чтобы не случилось с БД (если она вообще есть Программеры редко могут представить себе, что "Бух. счёт" может быть вне компьютера, например, в учётной книге, что не меняет бизнес-процесс, между прочим ) единственное что нужно будет изменить — это владельца.

СВ>Другой пример. Разработана огромная, сложная, система с "кучей" модулей-подмодулей, множеством средств хранения данных (базы данных, файлы различных форматов, распределенные данные в сети, контроллеры учета и регистрации и т.п.). Все это четко описано, регламентировано, стандартизировано, определены меры в случае изменения требований. Здесь виден динамический характер самой системы, а также динамический характер модели.

Система не должна быть сложной. Она должна быть модульной. Каждый модуль "владеет" своими данными и полностью не зависим от других модулей. В последнем предложении заменям модуль на сервис и приходим к SOA


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

Зачем? Решение есть. Проблема только в том, что это решение в жизнь не так легко воплотить по одной простой причине — ни программисты, ни бизнес-аналитики, ни менеджеры не готовы к такому повороту дел. Менеджеры понимают, что так надо делать, но и их заносит в технические детали. С архитекторами другая проблема (из моего опыта) — они слишком технические ребята, им тяжело отделить бизнес проблемы от технических проблем. Потому каждая попытка внедрить такое решение скатывается сначала на web servic-ы, потом на недостатки XML, потом на то, что Microsoft не поддерживает транзакции для web-servic-ов. Господи!!! Какое мне дело до web-servic-ов или Microsoft??? SOA тут вообще ни причём!

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

Вот и я о том же. 1 — это 1. Это знают все. А программисты выпендриваются — в "Матрице" видишь ли 1 — это 2 и потому мы не можем выполнить ваш проект в срок, или автоматизировать ваш бизнес-процесс без написания кода (а ещё вчера Нио прыгнул с небоскрёба, упал и разбил себе нос, не повезло — не допрыгнул ).

Здравствуйте, Сергей Воробьев, Вы писали:

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

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

Вот про источники узнать, особеноо касающиеся ООАП ... может не те смотрели?

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

Если говорить про цель, для чего определяются требования -- так это очевидно -- сделать софт, который бы удовлетворял нужды заказчика .

СВ>2. Методики <моделирования>.
СВ>Эти методики плохо подходят для "делящихся" и "сливающихся", "объединяющихся" объектов и процессов. Плохо подходят для описания "фазовых превращений" объектов (модель "личинка-гусеница-куколка-бабочка").

Диаграмма состяний UML это может описать ...

СВ>3. Статичность и динамичность

???

Сергей Воробьев -> Моделирование, проектирование, предметная область, ООП и
не

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

Это не разные подходы — это одно и тоже. Субъективный подход аналитика к
требованиям заказчика. Аналитик потому и нужен, что он приводит понимание
проблемы между заказчиком и исполнителем к одному знаменателю.

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

(тупо) а чо такое "делящиеся" и "сливающиеся" процессы?

СВ> Плохо подходят для описания
СВ> "фазовых превращений" объектов (модель
СВ>
СВ> "личинка-гусеница-куколка-бабочка").

statechart diagram из uml

СВ> Плохо подходят для описания
СВ> принадлежности объекта к разным описательным сущностям (некоторые
СВ>
СВ> называют это "классами"),

Хм... т.е. сущности не привязаны к процессам? Т.е. процессы сам по себе?
Процесс как раз и нужн, чтобы достичь опередленной цели, имя на входе одни
сущности, а на выходе получая другие.

СВ> представлениям знаний об объекте (Иванов:СВ>
СВ> работник предприятия, он же — муж, он же — отец, сын, он же -
СВ> специалист широкого профиля и т.п.), здесь опять вклинивается
СВ> "субъективный подход" (см. п.1)

Это не проблема моделирования — это проблема warp hands

СВ> 3. Статичность и
СВ> динамичность
СВ> Начну с примеров. Разработана база данных, в которой
СВ> ведется некий
СВ> учет. Ясен динамический характер ведения учета, данные
СВ> заносятся в
СВ> определенные моменты времени, используются
СВ> (просматриваются,
СВ> экспортируются) тоже в определенные моменты
СВ> времени. Поменялись
СВ> требования, изменилась структура БД, теперь надо
СВ> возможно
СВ> переработать все модули (программы, протоколы и стандарты),
СВ> которые
СВ> используют эту базу. Виден динамический характер <модели>
СВ> базы
СВ> данных.

Как ты ловко определения даешь, у меня аж слюни на клавиатуру закапали
Синие не являются стеклянными, потому они волнистые

СВ> Другой пример. Разработана огромная, сложная, система
СВ> с "кучей"
СВ> модулей-подмодулей, множеством средств хранения данных
СВ> (базы данных,
СВ> файлы различных форматов, распределенные данные в сети,
СВ> контроллеры
СВ> учета и регистрации и т.п.). Все это четко описано,
СВ> регламентировано, стандартизировано, определены меры в случае
СВ> изменения требований. Здесь виден динамический характер самой
СВ> системы, а также динамический характер модели.

Ага, т.е. бывают статичные большие системы? "У рыбы шерсти нет, но если
бы она была, то у нее были бы блохи"(с)анек

СВ> Так вот, различные
СВ> методики <моделирования>, средства
СВ> проектирования, теории и
СВ> парадигмы, по моему мнению, не позволяют
СВ> четко описать как работать с
СВ> динамическими <моделями> знаний.

Это не проблема в методологиях — проблема в голове и во времени.

СВ> И каждый проектировщик по своему
СВ> выходит из ситуации.

Проектировщик не анализирует предметную область

<skipped>
СВ> На этом пока остановимся..

ура, а то я читать устал

СВ>
СВ> 4. Модель времени
СВ> Не понимаю, почему в различных методиках
СВ> очень плохо рассматривается
СВ> модель времени.

Это саботаж, однозначно! 3 года расстрела деревянными пулями без права
переписки. Чтобы знали, чьи ягоды в ягодицах.

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

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

Будь проще — не городи лишних сущностей. Есть 3 типа систем (если мы будет
говорить про обработку событий) — синхронные, асинхронные и их помесь

<!-- Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева! -->

Здравствуйте, Mishka, Вы писали:

M>Это всё из области логической архитектуры приложений.
"Логическая архитектура приложения" — нигде не нашел такого термина или определения. Дайте пожалуйста ваше понятие для разъяснения.

M>Проблемы, которые ты перечислил, успешно решаются. Например при помощи SOA и BPM.
Спасибо, почитал.. Буду еще анализировать. Но на первый взгляд мне кажется, что это больше близко к уровню реализации, а не моделирования, проектирования, представления предметной области. Например, если представить уровни так: анализ предметной области — проектирование | моделирование — логическая | физическая реализация. Сразу говорю, что эти уровни в общем смысле несколько размыты.

M>Я имею в виду логическую архитектуру, а не физическую. Последняя всегда скатывается к вопросам web services, security и прочей технической лабуды, не имеющую никакого отношения к бизнесу. Сначала надо понять бизнес. Понять бизнес-сервисы (наприме, "Зарплата", "Бухгалтерия"), бизнес-процессы ("Начисления зарплаты", фантазия закончилась ), бизнесс-операции ("Расчёт зарплаты", "Выплат денег из кассы", "запуск ядерного реактора"). Если начать с бизнес-объектов, то там же вы и закончите (это принцип объектно-ориентированного анализа и архитектуры). Вот пример, в систему вводиться "Человек" как бизнес-объект (и это в реальном проекте, который кстати провалился). Зачем? Из ОО понятно, что это есть некое обобществление. С точки зрения бизнеса — это полный бред. Почему? Бизнес не имеет дела с человеком, он имеет дело с работниками, кандидатами на работу, провинившимися, покупателями, частными предпринимателями. Всё это бизнес-объекты. Увольняем Буча. Он не писал свою книгу во времена интеграции приложений и бизнес процессов. Он писал приложения, которые всегда были одни во вселенной и не должны были взаимодействовать с другими системами. Кроме того ОО требует чтобы все бизнес объекты были известны наперёд. Это возможно, но нельзя знать все бизнес процессы наперёд. Помещаем части бизнес-процесса в объекты и всё, систему можно выкидывать на свалку, поскольку процессы меняются часто и почти всегда различны в разных фирмах. Зарплату и ту везде по разному начисляют. 1С потому и хорош, что позволяет быстро адаптироваться под требования заказчиков, но это не есть правильное решение с точки зрения логической архитектуры.

M>Субъективности при моделировании можно избежать очень простым способом — не давать этим заниматься программистам, точнее тем, кто умеет писать код и знает хоть что-то про UML и ОО. Найдите бизнес-аналитика, да-да того самого, который знает бухгалтерию, финансы, кадры, или того кто знает устройство ядерного реактора и как он работает в деталях. То есть человека, который точно значет, что такое "покупатель", "бухгалтерский счёт" и пр. бизнес-объекты. Он всегда говорит на том-же языке, что и пользователи, и потому субъективности быть не может. Далее встаёт проблема взаимодействия бизнес-аналитика и программиста. "Покупатель" для бизнес-аналитика — это "человек, готовый заплатить деньги за услуги или товар", для программиста... что угодно... с вариациями, например C++ класс Customer, запись в Oracl-овой таблице Customer, web-service Customer (за это убивать надо, ну где вы видели, чтобы бизнес обеспечивал сервис под названием "Покупатель" ). Решением несоответствия между реальностью (точка зрения бизнес-аналитика) и "матрицей" (точка зрения программиста, где "покупатель" может прыгать и летать как Супермен ) должен заниматься человек, в задачу которого входит то, что на Западе называют "aligning IT to Business". То бишь заставляет IT смотреть на мир с точки зрения бизнеса (убирает субъективность, а заодно приводит к бизнес-ориентированной методологии разработки ПО, всё остальное — технические проблемы, и потому не интересные). Человек такой должен разбираться в технической архитектуре, а также в бизнес архитектуре. То есть нечто вроде бухгалтера-программиста. И такие люди есть. Да, и они не пишут код, поскольку это влияет на восприятие реальности.
M>Процесс обычно выглядит так: смортим что нужно закачику, определяем бизнес-процессы (если у вас есть желание их изменить, то вам нужно доказать, что то, как владелец фирмы делает бизнес сейчас — это неправильно, а вы готовы к этому?) и автоматизируем их Конечно для этого нужна инфраструктура, но это технические детали и потом не интересны (если очень хочется то смотрим WfMS, BPMS и пр.).
M>Да, "фазовые превращения" — это и есть бизнес процесс. "Запустили реактор" -> "Пустили козла в огород" -> "Пытаемся остановить цепную реакцию"
Все ваши примеры, ориентированные на "бизнес-процессы": зарплата, кадры, склады и т.п. А есть ведь и другие области: автоматика и механика, АСУТП и САПР, схемотехника и микроэлектроника, биология и химия, экология, эволюционные процессы, вы сами можете продолжить этот список. Везде здесь при использовании информационных систем тоже используется <моделирование>. И что-то я сомневаюсь, что тут помогут UML, SOA, BPM, ОО и т.п. Может тогда нужно ограничить область применения этих средств?

СВ>>Другой пример. Разработана огромная, сложная, система с "кучей" модулей-подмодулей, множеством средств хранения данных (базы данных, файлы различных форматов, распределенные данные в сети, контроллеры учета и регистрации и т.п.). Все это четко описано, регламентировано, стандартизировано, определены меры в случае изменения требований. Здесь виден динамический характер самой системы, а также динамический характер модели.
M>Система не должна быть сложной. Она должна быть модульной. Каждый модуль "владеет" своими данными и полностью не зависим от других модулей. В последнем предложении заменям модуль на сервис и приходим к SOA
А я и не говорил, что она не модульная. Она сложная, потому что там "много всего". "Полностью независим" — это в идеале, все равно есть случаи, когда при изменении какой-либо части не удается полностью добиться независимости. Вот тогда и начинается "подгонка" с нарушением всех правил "моделирования". А потом все это нарастает как снежный ком и приводит к провалу проекта. Иногда конечно спасает рефакторинг, но не всегда это возможно.

СВ>>Пока остановлюсь на этом, жду ваших мнений. Стоит ли это дальше обсуждать.
M>Зачем? Решение есть. Проблема только в том, что это решение в жизнь не так легко воплотить по одной простой причине — ни программисты, ни бизнес-аналитики, ни менеджеры не готовы к такому повороту дел. Менеджеры понимают, что так надо делать, но и их заносит в технические детали. С архитекторами другая проблема (из моего опыта) — они слишком технические ребята, им тяжело отделить бизнес проблемы от технических проблем. Потому каждая попытка внедрить такое решение скатывается сначала на web servic-ы, потом на недостатки XML, потом на то, что Microsoft не поддерживает транзакции для web-servic-ов. Господи!!! Какое мне дело до web-servic-ов или Microsoft??? SOA тут вообще ни причём!
И все-таки я думаю, исследовать это надо. И чем больше разносторонних и противоречащих взглядов будет, тем лучше. Это позволит взглянуть на проблему с разных сторон. И я надеюсь позволит выйти на новый уровень <моделирования>, не сочтите меня максималистом. Это как фундаментальные науки.

Здравствуйте, byur, Вы писали:

B>Здравствуйте, Сергей Воробьев, Вы писали:

B>Вот про источники узнать, особеноо касающиеся ООАП ... может не те смотрели?
Ну из фундаментальных Буч, и "книга четырех: Гамма и пр.", ну и попроще: различные статьи из журналов, из Интернета.
Весь список указать?

B>может не те смотрели?
Может.. Тогда подскажите "те". Мне это интересно..

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

Мой вывод такой: между требованиями и решением "сделать софт" еще много ступенек, которые иногда неплохо бы не переступать..

Реальный случай: мне стало грустно, когда узнал, что в небольшой фирме, чтобы просто выписывать счета на оплату поставили 1С, хотя остальной учет был вручную..

СВ>>3. Статичность и динамичность
B>???
???

Здравствуйте, hrg, Вы писали:

СВ>> Эти методики плохо подходят для "делящихся" и "сливающихся",
СВ>> "объединяющихся" объектов и процессов.
hrg>(тупо) а чо такое "делящиеся" и "сливающиеся" процессы?
Имел ввиду "процесс", как любое явление, событие проистекающее во времени.
Два процесса, которые описываются каждый по своему могут привести к одному процессу, который рассматривается как одна единая сущность, которая образовалась из предудущих процессов (возможно переняла их свойства).
"Делящиеся" и "сливающиеся" — это в общем смысле на интуитивном уровне. Думаю, можно привести и конкретный пример (например из химии).

СВ>> Плохо подходят для описания
СВ>> принадлежности объекта к разным описательным сущностям (некоторые
СВ>>
СВ>> называют это "классами"),
hrg>Хм... т.е. сущности не привязаны к процессам? Т.е. процессы сам по себе?
Несколько раз перечитал. Не понял почему?

СВ>> представлениям знаний об объекте (Иванов:СВ>
СВ>> работник предприятия, он же — муж, он же — отец, сын, он же -
СВ>> специалист широкого профиля и т.п.), здесь опять вклинивается
СВ>> "субъективный подход" (см. п.1)
hrg>Это не проблема моделирования — это проблема warp hands
Хотел сказать, что один и тот же объект в модели можно представить относящимся к разным классам. Например, когда выполняется поиск по всем "отцам" или "специалистам широкого профиля" и т.п. выходим на "Иванова" со всеми сопутствующими ему свойствами, атрибутами, связями. Это уже ближе к ООП, хотя идеология ООП не позволяет такого.

СВ>> Другой пример. Разработана огромная, сложная, система
СВ>> с "кучей"
СВ>> модулей-подмодулей, множеством средств хранения данных
СВ>> (базы данных,
СВ>> файлы различных форматов, распределенные данные в сети,
СВ>> контроллеры
СВ>> учета и регистрации и т.п.). Все это четко описано,
СВ>> регламентировано, стандартизировано, определены меры в случае
СВ>> изменения требований. Здесь виден динамический характер самой
СВ>> системы, а также динамический характер модели.
hrg>Ага, т.е. бывают статичные большие системы?
Бывают.
"Сложность системы" исходит из степени моделирования. Если наш земной шар смоделировать просто как шар, то это будет простая система. А если разложить на материки и океаны, страны, исторические процессы, анализировать физические и биологические факторы, тут можно до бесконечности идти, вот тогда это будет "сложная" система!!!
Поэтому можно получить модель сложной статичной системы, хотя это и не значит, что система такова, а это значит, что в этом приближении модель нас устраивает (исходя из требований и целей моделирования)

СВ>> Так вот, различные
СВ>> методики <моделирования>, средства
СВ>> проектирования, теории и
СВ>> парадигмы, по моему мнению, не позволяют
СВ>> четко описать как работать с
СВ>> динамическими <моделями> знаний.

hrg>Это не проблема в методологиях — проблема в голове и во времени.

Почему же? "Проблема в голове и времени" есть всегда, но если есть хорошая методология (ООП, АОП), применяются современные средства (ЯВУ, визуальные средства проектирования, тот же UML), то все равно результата можно достичь более качественного и в более короткий срок.

СВ>> И каждый проектировщик по своему
СВ>> выходит из ситуации.

hrg>Проектировщик не анализирует предметную область
Просто у нас с вами разное понимание "проектировщика".

СВ>> 4. Модель времени
СВ>> Не понимаю, почему в различных методиках
СВ>> очень плохо рассматривается
СВ>> модель времени.

hrg>Это саботаж, однозначно! 3 года расстрела деревянными пулями без права
hrg>переписки. Чтобы знали, чьи ягоды в ягодицах.


hrg>Будь проще — не городи лишних сущностей. Есть 3 типа систем (если мы будет
hrg>говорить про обработку событий) — синхронные, асинхронные и их помесь
Хорошо если бы так. Изучи эти три типа досконально, их свойства, прикладные области и ... смоделируешь любую систему

Здравствуйте, Сергей Воробьев, Вы писали:

СВ>Здравствуйте, Mishka, Вы писали:

M>>Это всё из области логической архитектуры приложений.
СВ>"Логическая архитектура приложения" — нигде не нашел такого термина или определения. Дайте пожалуйста ваше понятие для разъяснения.

Как строить ПО не основываясь ни на каких технических решениях. Например, объектно-ориентированная архитектура — логическая. Моделируем всё в терминах объектов (Платон вроде бы был основателем). J2EE — физическая ОО архитектура. То есть имеется вполне осязаемый код (или стандарт), накладывающий ограничения на проектирование ПО. Из-за несоответствия между логической архитекутрой (идеал) и физической (то, что позволяет текущее развитие технологий) появляются всякие design patterns.

M>>Проблемы, которые ты перечислил, успешно решаются. Например при помощи SOA и BPM.
СВ>Спасибо, почитал.. Буду еще анализировать. Но на первый взгляд мне кажется, что это больше близко к уровню реализации, а не моделирования, проектирования, представления предметной области. Например, если представить уровни так: анализ предметной области — проектирование | моделирование — логическая | физическая реализация. Сразу говорю, что эти уровни в общем смысле несколько размыты.

Забудь про реализацию! SOA = service-oriented architecture. BPM = business process management. Обе вещи можно рассматривать отдельно от IT. Например, возьмём университет. Если думать в смысле SOA, то он обеспечивает определённый сервис — обучение, исследования, пр. Если в смысле OOA, то он состоит из кафедр, студентов, профессоров, исследований и пр.
Две разные точки зрения на один и тот же объект. Ни больше, ни меньше. На сегодняшний день SOA считается лучшим вариантом, поскольку намного ближе отображает действительность корпоративного мира. Возможно другие миры (наука, искусство и пр.) могут быть смоделированы при помощи других средств, но меня этот вопрос как-то не занимает
Управление бизнес процессами принимает за аксиому то, что весь бизнес состоит из процессов. Улучшение процессов и их оптимизация — это основная цель бизнеса, поскольку это улучшает сам бизнес. Из другой области, химическая реакция — это тоже бизнес процесс, изменить его может и нельзя, но управлять (контролировать, обеспечивать условия, ресурсы) всё равно необходимо.

Как работает корпорация? Люди из отдела маркетинга, занимающие позиции product managers, выясняют что нужно рынку, то есть определяют продукт. Продукт — это набор физических вещей и услуг, объединённый под одним названием (брандом). Например, продукт Microsoft Office — включет в себя программы, руководство пользователя, техническую поддержку, рекламную компанию и пр. Product Managers отвечают за дизайн продукта. Они точно знают что должно быть в продукте, чтобы его можно было продать. Далее, отделы корпорации получают задание на разработку продукта. Конкретнее, отдел IT получает документ с требованиями к функциональности программы (программа — это не продукт, это обычно малая его часть). В этот момент бизнес аналитики начинают исследовать предметную область, а технические архитекторы — строить необходимую инфраструктуру. Когда всё готово, программисты садятся и пишут код.
Так это происходит в больших конторах. В маленьких, обычно product managers — это бизнес аналитики, а архитекторы — программисты.
Логическая архитектура должна применяться на уровне product manager-ов, поскольку они владельцы продукта. Для них ООА не шибко замечательный подход, а вот SOA — самое то. Бизнес обеспечивает сервисы для своих клиетов. Каждый сервис состоит из бизнесс-процессов. Это product managers понимают и готовы описывать требования к функциональности ПО в этих терминах. Если затем имеется подходящая инфраструктура (BPMS, WfMS), то разработка ПО сильно упрощается.

M>>Система не должна быть сложной. Она должна быть модульной. Каждый модуль "владеет" своими данными и полностью не зависим от других модулей. В последнем предложении заменям модуль на сервис и приходим к SOA
СВ>А я и не говорил, что она не модульная. Она сложная, потому что там "много всего". "Полностью независим" — это в идеале, все равно есть случаи, когда при изменении какой-либо части не удается полностью добиться независимости. Вот тогда и начинается "подгонка" с нарушением всех правил "моделирования". А потом все это нарастает как снежный ком и приводит к провалу проекта. Иногда конечно спасает рефакторинг, но не всегда это возможно.

Рефакторинг придуман людьми от XP, которые таким образом борются с изначальным отсутствием дизайна. Маленькие проекты так ещё можно делать, но большие — нет. Всё равно нужна логическая архитектура, физическая архитектура и инфраструктура. А полной независимости можно добиться при использовании event-driven architecture, только там модули уж слишком независимы

Сергей Воробьев -> Re[2]: Моделирование, проектирование, предметная область,
ОО

СВ>>> Эти методики плохо подходят для "делящихся" и "сливающихся",
СВ>>> "объединяющихся" объектов и процессов.
hrg>>(тупо) а чо такое "делящиеся" и "сливающиеся" процессы?
СВ> Имел ввиду "процесс", как любое явление, событие проистекающее во
СВ> времени.
СВ> Два процесса, которые описываются каждый по своему могут привести к
СВ> одному процессу, который рассматривается как одна единая сущность,
СВ> которая образовалась из предудущих процессов (возможно переняла их
СВ> свойства).
СВ> "Делящиеся" и "сливающиеся" — это в общем смысле на интуитивном
СВ> уровне. Думаю, можно привести и конкретный пример (например из
СВ> химии).

Так, а теперь покажи пример, где все плохо в твоем понимании.

СВ>>> Плохо подходят для описания
СВ>>> принадлежности объекта к разным
СВ> описательным сущностям (некоторые

СВ>>> называют это
СВ> "классами"),
hrg>>Хм... т.е. сущности не привязаны к процессам?
СВ> Т.е. процессы сам по
hrg>>себе?
СВ> Несколько раз перечитал. Не понял
СВ> почему?

из твоих утверждений

СВ>>> представлениям знаний об объекте (Иванов:СВ>
СВ>>> работник
СВ> предприятия, он же — муж, он же — отец, сын, он же -
СВ>>> специалист
СВ> широкого профиля и т.п.), здесь опять вклинивается
СВ>>> "субъективный
СВ> подход" (см. п.1)

hrg>>Это не проблема моделирования — это проблема warp
hrg>>hands

СВ> Хотел сказать, что один и тот же объект в модели можно
СВ> представить
СВ> относящимся к разным классам. Например, когда выполняется
СВ> поиск по
СВ> всем "отцам" или "специалистам широкого профиля" и т.п.
СВ> выходим на
СВ> "Иванова" со всеми сопутствующими ему свойствами,
СВ> атрибутами,
СВ> связями. Это уже ближе к ООП, хотя идеология ООП не
СВ> позволяет
СВ> такого.

Почему? Множественные интерфейсы и вперед.

hrg>>Ага, т.е. бывают статичные большие

СВ> системы?
СВ> Бывают.
СВ> "Сложность системы" исходит из степени
СВ> моделирования. Если наш
СВ> земной шар смоделировать просто как шар, то
СВ> это будет простая
СВ> система. А если разложить на материки и океаны,
СВ> страны, исторические
СВ> процессы, анализировать физические и
СВ> биологические факторы, тут
СВ> можно до бесконечности идти, вот тогда это
СВ> будет "сложная"
СВ> система!!!
СВ> Поэтому можно получить модель
СВ> сложной статичной системы, хотя
СВ> это и не значит, что система такова,
СВ> а это значит, что в этом
СВ> приближении модель нас устраивает (исходя из
СВ> требований и целей
СВ> моделирования)

(тщетно пытаясь выпрямит единственную извилину) и чем в товем понимании
отличается статическая система от динамической?

СВ>>> Так вот, различные методики <моделирования>, средства
СВ>>> проектирования, теории и парадигмы, по моему мнению, не позволяют
СВ>>> четко описать как работать с динамическими <моделями> знаний.

hrg>>Это не проблема в
СВ> методологиях — проблема в голове и во времени.

СВ> Почему же? "Проблема в
СВ> голове и времени" есть всегда, но если есть
СВ> хорошая методология (ООП,
СВ> АОП), применяются современные средства
СВ> (ЯВУ, визуальные средства
СВ> проектирования, тот же UML), то все равно
СВ> результата можно достичь
СВ> более качественного и в более короткий
СВ> срок.

хм... всегда думал что методология — это что то типа RUP, XP, MSF
и опять — ты отвечаешь сам себе на свой же заданный вопрос не относяшийся к
теме. Ты сказал:
"различные методики <моделирования>...не позволяют четко описать... ". А
потом разразился абацем текста, из которого ничего не поняно

СВ>>> И каждый
СВ> проектировщик по своему
СВ>>> выходит из ситуации.

hrg>>Проектировщик не

СВ> анализирует предметную область
СВ> Просто у нас с вами разное понимание
СВ> "проектировщика".

Возможно, но я беру трактовку из RUP.

СВ>>> 4. Модель времени
СВ>>> Не понимаю, почему
СВ> в различных методиках
СВ>>> очень плохо рассматривается
СВ>>> модель
СВ> времени.

hrg>>Будь проще — не городи лишних сущностей. Есть 3 типа
СВ> систем (если мы
hrg>>будет
hrg>>говорить про обработку событий) -
СВ> синхронные, асинхронные и их
hrg>>помесь
СВ> Хорошо если бы так. Изучи
СВ> эти три типа досконально, их свойства,
СВ> прикладные области и ...
СВ> смоделируешь любую систему
онально, их свойства,
СВ> прикладные области и ... смоделируешь любую систему

Типа спасибо за совет, но у меня к тебе просьба — пиши короче и постарайся
донести своб мысль до собеседника, а то тебя читать очень тяжело.

<!-- Yury Kopyl aka hrg | Гордость мешает доходам! -->

Здравствуйте, Сергей Воробьев, Вы писали:

СВ>Здравствуйте, byur, Вы писали:

B>>Здравствуйте, Сергей Воробьев, Вы писали:

B>>Вот про источники узнать, особеноо касающиеся ООАП ... может не те смотрели?
СВ>Ну из фундаментальных Буч, и "книга четырех: Гамма и пр.", ну и попроще: различные статьи из журналов, из Интернета.
СВ>Весь список указать?

Бучь это "очень высокоуровневая", GOF врядли поможет дать ответы на поставленные вопросы.

B>>может не те смотрели?
СВ>Может.. Тогда подскажите "те". Мне это интересно..

K. Larman, A. Cockburn, M. Fowler, S. Ambler ... к этим стоит прислушаться.


B>>Если говорить про цель, для чего определяются требования -- так это очевидно -- сделать софт, который бы удовлетворял нужды заказчика .
СВ>По моему не совсем, как что так "сразу сделать софт".
СВ>Вот например, самое простое: есть требования — организовать "удобный" складской учет, минимизировать людские и прочие ресурсы для этого. И еще чтобы на основе этого учета можно было легко проводить анализ для принятия бизнес-решений. Конечно, сразу приходит в голову мысль все это сделать на компьютере с помощью софта. Читал где-то в недрах Инета статью про "Автоматизацию без компьютера". Там "гениально и просто", а главное грамотно организован складской учет большого ассортимента товаров на нескольких торговых точках. Если коротко, по сути: там все было расписано до мелочей в инструкциях каждого из участников — продавца, водителя, менеджера склада, даже советы управленцу. Конечно, там не учтены некоторые непредвиденные ситуации, но на это там и есть человек. И эта система успешна работала!!! (а может еще и работает).


Так ... очевидно путаем понятия. "организовать "удобный" складской учет" и "минимизировать людские и прочие ресурсы"-- это все-таки не требование, это stakeholder request, причем в самом сыром виде. Причем это относится к БИЗНЕСУ, а не к инженерии ПО. Нужно таки отделять построение и оптимизация бизнес-процессов от создания ПО для поддержки этих процессов. Можно посмотреть у Коберна о возможных подходах, но у него там кратко но внятно "от бизнеса к технологиям", "от технолгий к бизнесу", и т.п. это все во "Writting effective use cases".

СВ>Мой вывод такой: между требованиями и решением "сделать софт" еще много ступенек, которые иногда неплохо бы не переступать..

Да, и эти ступеньки должны сделать аналитики бизнеса (не важно свои или внешние консалтеры, или представители компании-интегратора). Не нужно мыслить столь глобально и столь же неконкретно.


СВ>Реальный случай: мне стало грустно, когда узнал, что в небольшой фирме, чтобы просто выписывать счета на оплату поставили 1С, хотя остальной учет был вручную..

Самая короткая дорога та -- котрую знаешь . Наверное этот какраз этот случай .

СВ>>>3. Статичность и динамичность
B>>???
СВ>???

Что-то слишком сложно написано. UML позволяет описать как статику, так и динамику ... причем не важно чего бизнес-процессов или ПО ... что еще не хватает? Да и UML это НЕ МЕТОДОЛОГИЯ ... это язык.