Цели имеют иерархическую структуру. Есть цель пописать. Она разбивается на цели: найти туалет и цель — успеть до него добежать. Но цель пописать возникает из желания выжить. И так далее. Вы скажите, какого уровня цель вы имеете ввиду?
Я потратил около 10 лет на попытку понять некоторые вещи. Оказалось, что существующий state of art бизнес-анализа не способен ответить на мои вопросы. Мне понадобилось еще 2 года, чтобы самостоятельно ответить на них. Теперь у меня есть запрос от коллег по цеху, которые просят описать эту позицию в виде текста, а не в виде устного творчества. Я выполняю этот запрос.
Цели я обозначил сразу — неудовлетворенность существующими методами моделирования предметной области и тотальное невежество. Но это мое мнение. Я не пытаюсь убедить других в том, что я прав. Я могу ошибаться. Просто исследую эту область методами мне доступными. А вот зачем Вам обязательно меня убедить в том, что я не прав — не понимаю. У Вас свое мнение, у меня — свое. Это хорошо. Я не вижу смысла Вас переубеждать. Я не вижу смысла в том, чтобы Вы меня убедили в чем-то. Давайте закроем эту тему и продолжим работать. Это ведь гораздо интереснее, чем холиварить?
Вы хотите, чтобы я представил Вам доказательства необходимости моего подхода? Зачем Вам это? Я не пытаюсь никого ни в чем убедить. Я пытаюсь дать видение, которое у меня есть, но не стремлюсь заставить верить в него. Если Вам оно не нужно, — не пользуйтесь им.
Да. Я с самого начала говорю о том, что, если Вам достаточно тех методов, которыми Вы пользуетесь, — пользуйтесь ими. Мне не достаточно ER диаграмм. Я искал другие методы проектирования и нашел их. Теперь делюсь ими с теми, у кого есть такая же потребность. Я не настаиваю на том, что всем надо переходить на эти методы. Просто рассказываю про свой опыт и свое видение.
ER диаграммы я не отметаю, я лишь рассказываю про их ограничения. И я привожу даже не свои исследования на этот счет. Эти исследования сделал не я. Я просто их иллюстрирую своими примерами.
Я думаю, что мы не понимаем друг друга, потому что я априори считаю, что перед разработчиками стоит задача описания предметной области. Если не стоит такая задача, то «нет тела, нет преступления». То есть, нет смысла говорить о том, чего нет.
Под разработкой понимается весь процесс от идеи до остановки сопровождения. Весь жизненный цикл. Понятно, что в процессе разработки появляются множество артефактов, но три перечисленные — возникают как правило. Хотя никто не говорит о том, что можно обойтись без одного из них. Даже работу кода можно симулировать. Так что ни один из артефактов не являясь обязательным, тем не менее присутствует как правило.
Начнем с того, что мы не описываем сущее. Мы описываем наше восприятие сущего. В нашем восприятии существует пространство и время. Далее мы постулируем тот факт, что любое подпространство этого пространства — объект. Просто аксиоматически. Называется он экстент. Затем экстент начинаю классифицировать. Например, слона можно классифицировать как весящего 1 грамм. Это ошибка? Нет до тех пор, пока не будут придуманы методы отнесения объекта к этому классу, указаны методы измерений, обработки погрешностей и так далее. Но это не гарантирует нам того, что сам метод будет непротиворечивым. Может случиться, что завтра весы, на которых мы взвешиваемся, покажут нам 1 кг живого веса при тех же условиях. Просто мы столкнемся с новым для нас явлением. Поэтому есть экстенты и есть классы. Экстены классифицируются субъектом и обладают всеми субъективными свойствами: возможностью переклассифицирования и так далее.
Я заметил одну важную деталь в Ваших рассуждениях, на которую хочу обратить внимание. Вы просите определить требования. когда водитель считается уснувшим. Это абсолютно законное желание. Однако, Вы забываете указать интервал значений, при которых переход из одного состояния в другой будет считаться выполненным. Допуск — вот что Вы забыли. А он как раз решает философский вопрос о том, что есть событие? Если ввести допуск, то момент времени превратится в интервал времени. То есть водитель считается уснувшим не в момент времени, а в интервале времени. И так со всеми событиями. Кроме того, надо добавить погрешности измерений. И тогда на сцену появляется новый игрок — вероятность получения достоверных данных на основе проведенных испытаний. И это делает наш интервал не просто интервалом, но еще и вероятностным интервалом.
Я говорю с чужих слов, — тех людей, которые считают себя профессионалами. Одни из них — системные аналитики, другие — архитекторы, третьи — программисты, четвертые — бизнес-аналитики. Каждый имеет что сказать про свою работу.
До сего момента я рассказывал про информационные системы. Информационная система — объект, но информационный. Его также можно моделировать, как и любой другой объект, но об этом я писал ранее. Если мы говорим про другие системы — то Вы скажите, какие Вы имеете ввиду и мы рассмотрим их подробно.
Программист не разрабатывает систему. Он программирует. разработкой системы занимается системный аналитик и архитектор. Если программист выполняет роль системного аналитика или архитектора, то это совмещение ролей. Но не одна роль!
Я не знаю, в чем отличие, потому что мой интерес — модели предметной области, а не модели системы или реализации. Хотя, я знаком с ними и с принципами их разработки, но это не мое.
Опять не понятно. Система не содержит модель. Она есть модель.
Системный аналитик настолько хорошо разбирается в технологиях, что на него и на архитектора возлагаются задачи проектирования системы.
А вот тут я не понимаю, о чем Вы. Есть предметная область. Есть информационная модель предметной области. И это разные вещи. Они могут стать одной только в том случае, когда байты станут признаваться в качестве аргумента в суде. Но до этого пока далеко.
Модель реализации — это и есть модель системы. Потому что система — есть реализация. Система моделирует предметную область. Модель предметной области создает бизнес-аналитик. Модель системы — системный аналитик. Эти аналитики делают так, чтобы модель предметной области нашла свое отражение в реализации. А реализация была описана простым и понятным для программиста образом.
Я сказал, что я согласен с Ларманом. ИМХО.
Про ИСО я знаю мало — это лучше Левенчука почитать. Его команда делает адаптеры для информационных систем и, насколько я знаю, успешно.
Насчет непротиворечивости моделей. Непротиворечивость рождается на основе непротиворечивого базиса. Пока программисты пользовались быстрыми методами проектирования и реализации, которые (методы) имеют внутренние противоречия. В своих статьях я пытаюсь вслед за Крисом Партриджем описать эти противоречия. И пытаюсь познакомить читателя с подходом, лишенным этих противоречий. Однако, как Вы правильно заметили, ресурсы на создание моделей и кода на основе этой методологии — огромны. У Криса ест ьрисунок в его книге, которую я рекомендую всем прочитать, тех затрат, которые требуются на создание непротиворечивой модели и тех кейсов, при которых эта модель себя окупает.
Модель предметной области создает бизнес-аналитик. Модель системных объектов и системных функций — системный аналитик. Иногда, и очень часто, эти роли совмещены.
Что касается domain-driven design. Какую бы методику проектирования мы не взяли, к ней можно применить слова Крега Лармана:
На странице 36-37 его книги написано:
Программные объекты в некотором смысле соответствуют объектам реального мира, но не являются их точными моделями или копиями. Хотя полученная диаграмма классов проектирования не до конца соответствует модели предметной области, некоторые имена классов и их характеристики совпадают. Объектно-ориентированные проектные решения и языки позволяют уменьшить разрыв между представлением информации в виде программных компонентов и ментальными моделями предметной области. Это улучшает образность представления.
Есть методика, которая позволила бы сделать непосредственное моделирование предметной области в коде. ИСО 15926 для этого и создавалось. Но посмотрите на ресурсы, которые требуются для реализации этой методики (как интеллектуальные так и машинные), и поймете, что пока эта желанная цель не достигнута.
Как я вижу профдеформацию программистов? Программируя, они часто забывают о том, что они на самом деле делают. Если программист создает информационную систему, то через некоторое время он забывает, что создаваемые им сущности — информационные объекты, несущие информацию о предметной области. Сами информационные объекты в воображении программиста становятся объектами предметной области. Это верно, если он занимается моделированием информационных объектов системы, а не объектов предметной области. Но, моделирую информационные объекты, он связывает их жесткой связью с объектами предметной области. И с этого момента он становится непригодным как аналитик предметной области, да и как системный аналитик — тоже. Если же он, глядя на таблицу под названием договора, будет видеть записи таблицы, хранящие информацию о классе объектов, каждый из которых (объектов) — есть экземпляр договора, то шанс быть аналитиком у него есть. Кроме того, он должен знать ограничения тех инструментов моделирования, которые он использует в работе. Но этого часто не знают и сами аналитики(.
Попробуйте прочитать статью, в которой на примере термина договор я рассказываю про то, как видят мир программисты. Возможно, будет интересно и полезно
В процессе разработки появляются три артефакта: описание предметной области, описание информационной системы и код.Вы согласны с этим?
До сего момента я рассказывал про информационные системы. Информационная система — объект, но информационный. Его также можно моделировать, как и любой другой объект, но об этом я писал ранее. Если мы говорим про другие системы — то Вы скажите, какие Вы имеете ввиду и мы рассмотрим их подробно.
Программист не разрабатывает систему. Он программирует. разработкой системы занимается системный аналитик и архитектор. Если программист выполняет роль системного аналитика или архитектора, то это совмещение ролей. Но не одна роль!
Опять не понятно. Система не содержит модель. Она есть модель.
А вот тут я не понимаю, о чем Вы. Есть предметная область. Есть информационная модель предметной области. И это разные вещи. Они могут стать одной только в том случае, когда байты станут признаваться в качестве аргумента в суде. Но до этого пока далеко.
Я сказал, что я согласен с Ларманом. ИМХО.
Про ИСО я знаю мало — это лучше Левенчука почитать. Его команда делает адаптеры для информационных систем и, насколько я знаю, успешно.
Что касается domain-driven design. Какую бы методику проектирования мы не взяли, к ней можно применить слова Крега Лармана:
На странице 36-37 его книги написано:
Программные объекты в некотором смысле соответствуют объектам реального мира, но не являются их точными моделями или копиями. Хотя полученная диаграмма классов проектирования не до конца соответствует модели предметной области, некоторые имена классов и их характеристики совпадают. Объектно-ориентированные проектные решения и языки позволяют уменьшить разрыв между представлением информации в виде программных компонентов и ментальными моделями предметной области. Это улучшает образность представления.
Есть методика, которая позволила бы сделать непосредственное моделирование предметной области в коде. ИСО 15926 для этого и создавалось. Но посмотрите на ресурсы, которые требуются для реализации этой методики (как интеллектуальные так и машинные), и поймете, что пока эта желанная цель не достигнута.