Дико извиняюсь, но в статье всё смешалось в кучу, а теория систем, как мне кажется, так вообще притянута за уши и осталась не понятой автором. Например следующие фразы оставили в моей голове одни вопросы.
Примером эмерджентности в программировании ожет служить поведение распределенной системы, где простое взаимодействие отдельных узлов порождает новые паттерны работы.
Разве в этом примере сумма узлов не даёт ответ на вопрос, какая вариативность будет на выходе? По мне, так это просто конгломерат компонентов. Это как набор из 4-х ножек, одного сидения и одной спинки, сложенных рядом, нельзя считать стулом. В общем, не увидел здесь эмерджентных свойств.
Самоорганизация — это способность системы к спонтанной организации и адаптации.
А далее идёт фрагмент кода. О каких порождающихся новых паттернах речь, хотелось бы услышать. Как код смог адаптироваться к условиям внешней среды, мобилизовать свои ресурсы, измениться или создать внутри себя что-то новое, чтобы можно было говорить об адаптаци? Не уловил.
Ашби утверждает, что для эффективного управления системой ее внутренняя сложность должна соответствовать сложности ее окружения. В программировании это означает, что система должна быть достаточно гибкой и масштабируемой, чтобы адаптироваться к меняющимся требованиям и условиям.
Эшби предполагал, что сложность управляющей системы должна соответствовать сложности управляемой системы. В вашем примере есть абстрактная система, которая почему-то должна адаптироваться к внешним условиям, т.е. связи по управлению не прослеживается.
Влияние NP-полноты на системную аналитику
В ряде профильных пабликов за "системную аналитику" вообще могут предать анафеме))
Делал в PlantUML, а, если быть точнее, то в её онлайн-версии (http://www.plantuml.com/). В PlantText тоже будет работать.
Метадерево в виде кода
@startmindmap
<style>
mindmapDiagram {
node {
backgroundColor lightGoldenRodYellow
lineColor fireBrick
}
arrow {
LinkeThickness 0.5
LineColor fireBrick
}
}
</style>
* Что рассматриваем?
** Стейкхолдеры
*** Что именно?
**** Выявление категорий стейкхолдеров
***** Луковичная диаграмма
***** Матрица ответственности
**** Вовлечённость стейкхолдеров в проект
***** Матрица ответственности
**** Выстраивание взаимодействия со стейкхолдерами
***** Радарная диаграмма
***** Матрица стейкхолдеров
** Предметная область
*** Что именно?
**** Термины и классификация
***** Ментальная карта
**** Модель предметной области
***** Диаграмма классов UML
***** ER-диаграмма
***** Концептуальная карта
**** Стадии жизненного цикла
***** Диаграмма состояний UML
***** OSTN IDEF3
** Бизнес
*** На чём фокусируемся?
**** Выполняемая работа и её состав
***** IDEF0
***** Дерево функций ARIS
**** Передача и обработка данных
***** Диаграмма потоков данных
**** Бизнес-процессы
***** Точка зрения?
****** Процессный ландшафт
******* Диаграмма диалогов BPMN
****** Отдельный процесс (последовательность действий/работ)
******* Требуемый уровень описания?
******** Высокий
********* Диаграмма хореографии BPMN
********* Диаграмма деятельности UML
********* ARIS eEPC
******** Низкий
********* Диаграмма процесса BPMN
********* Диаграмма взаимодействия BPMN
********* Диаграмма деятельности UML
********* FPDD IDEF3
**** Организационная структура компании
***** Организационная диаграмма ARIS
**** Распределение обязанностей и поиск перекосов
***** Матрица ответственности
** Информационная система
*** Что именно?
**** Архитектура
***** Точка зрения?
****** Системный ландшафт
******* Диаграмма коммуникации UML
******* Диаграмма системного ландшафта C4
******* Карта экосистемы RML
****** Отдельная система
******* На чём фокусируемся?
******** Система и её окружение (пользователи и др.системы)
********* Контекстная диаграмма (не IDEF0)
********* Диаграмма системного контекста C4
******** Структура и элементы системы
********* Диаграмма компонентов UML
********* Диаграмма компонентов C4
********* Диаграмма контейнеров C4
******** Физическое расположение компонентов системы
********* Диаграмма развёртывания UML
********* Диаграмма развёртывания C4
******** Распределённый характер системы
********* Диаграмма взаимодействия [Клеппман]
**** Функциональность
***** Точка зрения?
****** Пользователь
******* На чём фокусируемся?
******** Категории пользователей, роли
********* Диаграмма классов UML
********* Диаграмма вариантов использования UML
******** Доступы к системе
********* Иерархия ролей
********* Диаграмма Венна
******** Функциональные возможности для пользователей (верхнеуровнево)
********* Диаграмма вариантов использования UML
********* Диаграмма системного контекста C4
******** Взаимодействие пользователей с системой
********* Важен конечный дизайн и детали?
********** Нет
*********** Каркас (Wireframe)
*********** Варианты использования [Кобёрн]
*********** Поток пользовательского интерфейса RML
********** Да
*********** Карта экранов
****** Система или комплекс систем
******* На чём фокусируемся?
******** Основные функциональные блоки и связи между ними
********* Диаграмма вариантов использования UML
******** Элементы системы/комплекса и имеющиеся между ними взаимодействия
********* Диаграмма коммуникации UML
********* Диаграмма пригодности ICONIX
******** Последовательность взаимодействий систем или элементов системы
********* Диаграмма последовательности UML
******** Действия и поведенческие зависимости между ними
********* Диаграмма деятельности UML
******** Имеющиеся состояния, шаги workflow и переходы между ними
********* Диаграмма состояний UML
****** Бизнес-заказчик
******* Дерево характеристик RML
******* Диаграмма требований SysML
**** Алгоритмы
***** Диаграмма деятельности UML
***** Схема программы ГОСТ 19.701-90
***** Дерево решений
**** Данные
***** На чём фокусируемся?
****** Сущности и отношения между ними
******* ER-диаграмма
******* IDEF1x
****** Статусная модель сущности
******* Диаграмма состояний UML
****** Передача и обработка данных
******* Где основная сложность?
******** В обработке и трансформации данных
********* Таблица маппинга
******** В процессах
********* Точка зрения?
********** Системы и компоненты
*********** Диаграмма коммуникации UML
********** Выполняемые процессы и операции
*********** Диаграмма потоков данных
****** Сходства и различия наборов данных
******* Диаграмма Венна
@endmindmap
С этого мы и начинали. Для бэка 1-й компании основная сущность — "Заявка". Там она и рождается как сущность, хотя и с названием статуса, который вам кажется неудачным:)
Этот раздел, как мне кажется, очень спорный. Да, знать SQL полезно, но вот как SQL позволит в человеке развить логическое мышление, я не уловил. Да и логика вообще бывает у всех своя и сильно разная:)
Понимая, как устроен запрос и какие ресурсы он потребляет, можно заранее предусмотреть необходимые ограничения.
Почему-то в тексте во главу угла ставится именно запрос. Звучит так, словно предлагается не проработать решение задачи, а найти объяснение, почему что-то будет работать не в полной мере или не так, как хотелось заказчику.
В конце концов, мы же можем любой запрос переписать, индекс на таблицу навешать или ещё какие-то манипуляции на уровне БД произвести. А если пообщаться с архитектором, то может оказаться, что спектр вариантов решения бизнес-задачи ещё шире (например, СУБД стоит заменить, данные зарезервировать, шардировать, сделать кэш и пр.). Не SQL-ом единым, так сказать.
Позволяет с ходу оценивать реализуемость требований.
С ходу оценивать что-либо сложно. И знание SQL точно не будет ответом на все вопросы.
Я уже не уверен, что мне удастся вас убедить в том, что время это эктор. Просто попробуйте на это посмотреть как часть модели. Модель это всегда упрощение, но которое несёт практическую пользу.
Что такое "безликая сущность с генерализованным названием"?
Там фигурирует сущность "Операция". Поэтому и говорю, что безликая. Через эту сущность (фактически транспортный объект) в бэк передаётся всё что угодно: запрос какой-то информации, передача чего-то. Через эту сущность попадает, среди прочего, и заявка, просто "Заявка" как сущность создаётся именно в бэке, когда внутрянку проанализировали и поняли, что речь в данном конкретном объекте типа "Операция" идёт о необходимости открыть договор.
Такое ощущение, что вы пытаетсь меня убедить пойти и переписать системы, исходя из своего понимания прекрасного:)
1. "Принята" - значит, принят, получен объект. Никак не создан.Создание - это создание объекта, никак не его передача/получение.
"Принята" это в терминах бэковой системы. Они заявку приняли. То, что приём предполагает создание записи в соответствующей табличке БД,— это уже технические детали. Даже не понимаю, как можно не соглашаться с тем, кто как назвал в своей системе состояния. Это факт.
Или заявка как объект создан на фронте (один из признаков этого события - присваивается уникальный идентификатор), или бэк получает запросна создание объекта (заявки), валидирует запрос и создаёт объект. Хоть убейте, но другого варианта пока не вижу.
Формируется базово на фронте, но там оперируют понятием операции (безликая сущность с генерализованным названием) и, коль скоро для решаемой задачи этот сегмент процесса был признан несущественным, то приклеивать 3-ю сущность ("операцию") не понадобилось. Схема стала формироваться, начиная с 1-го бэка, а там термин "Заявка" в ней был основным.
Это продолжение предыдущего, на самом деле.Вот интересно, а что мешает 2-й системе сделать то же самое для основного сценария, чтобы бэк, как владелец объекта, со спокойной совестью завершил жизнь объекта? Почему только для неуспеха?
А вот тут мы приходим к 2-м тезисам.
Во-первых, это частично и приводило к сложностям обслуживания. Но решать это выстраиванием петель обратной связи и сшиванием статусных моделей 2-х разных компаний посчитали не лучшей затеей. Да и системе мониторинга, которая живёт отдельно, это никак не помогает.
Во-вторых, владельцы систем и жили в парадигме границ: одна система отвечает за заявки, другая уже занимается договорами. И это обусловлено тем, что это 2 разные компании, которые жили каждая своей счастливой жизнью, но при выстраивании сквозного процесса (чтобы 1-я компания могла продавать через себя продукты 2-й) пришлось "подружить" системы.
И кто б сомневался, что в итоге передающей системе надо знать и решение принимающей стороны по переданному объекту! Теперь это с такой кровью пытаются сделать
Безусловно, такое тоже может иметь место. Даже допускаю, что статус "Заявка отклонена" и появился в ходе проработки подобной потребности (был один конечный статус, а бизнес пришёл и сказал, что желает знать об отказах). Но надо понимать, что задачи переделать системы и/или их взаимодействие не было (на это были свои резоны). Мне тоже не всё в имеющемся процессе нравилось, но это жизнь.
Эктором может быть что угодно, чьё поведение выступает триггером для функциональности. Это может быть конечный пользователь систем (самый очевидный вариант), другая система или время.
Вот пример из другой сферы. Раз в год компания формирует некоторую отчётность и отправляет её в регулирующие органы. Формирование отчётов можно представить как вариант использования, а человека признать эктором. Но тут вопрос: человек разве по своему разумению отправляет отчёты? Нет. Он не просыпается утром с мыслью: "Вот сегодня задам жару, отправлю отчёт". Тут обстоятельства, бизнес-правила, расписание вынуждают его это сделать. В такой конфигурации время будет наиболее логичным вариантом эктора. Ну и надо понимать, что не обязательно отчёт в данном случае формируется системой автоматически, тот самый человек вполне может требоваться, чтобы войти в систему, ввести параметры и нажать большую красную кнопку. Руками человека исполняется логика иного уровня.
Во всех примерах вместо Time очень чётко встаёт конкретная система.Выгрузку сделок в хранилище делают именно Торговая система А и Торговая система Б.
Выгружают действительно Торговые системы А и Б, это и показано в форме эллипсов (варианты использования). Но они выполняют внешнюю логику, как описал двумя абзацами выше.
Да, это не так просто принять, поэтому практика применения эктора Time в диаграммах вариантов использования и в диаграммах последовательности не так распространена. Но тем не менее она есть и имеет свой смысл.
Если выполнение сценария инициируется по расписанию, введите в рассмотрение эктора Time (время), тогда жизнь сильно упрощается. Как я отметил в статье, это не моё изобретение, но это довольно слабо применяемая практика. Вот, например здесь ещё в 2009 году задавались вопросом, а правда ли так можно, и ответом было «да» со ссылкой на эту страницу.
Что касается границ системы, то тут был фокус как раз в применении системного подхода (почему-то большинство системных аналитиков его не изучало, но это тема для отдельной статьи:)). Так вот, собственно, системы входят в системы более высокого уровня (суперсистемы, надсистемы) и делятся на системы более низкого уровня (подсистемы). Системы любого уровня — это всё равно системы. А раз так, то можно не решать задачу в лоб, а обыграть это на синтаксисе UML.
Здесь у меня была логика, чем-то сходная с п.2. Если можно создать свою сущность, тогда формально ты не нарушаешь ничего. В конце концов, любая сущность при проектировании (та же «Заявка» и «Договор») — это не более чем модель, объект-заменитель, а значит изначально содержит определённый уровень условностей и допущений. А раз так, мы тоже можем создать свою сущность, которая тоже будет отражать в некотором приближении понятие реального мира, и уже её смоделировать доступными средствами.
Только сущностей - 4 штуки, сейчас только у одной выделены статусы, и есть сложные обратные ветвления процессов с рождением ещё "вспомогательных" объектов одной сущности; мозг уже 2-й месяц взрывается.
Вот это звучит действительно серьёзно. Из опыта могу посоветовать посмотреть на всю эту красоту сверху и попытаться выстроить целевую статусную модель только с критически важными состояниями исходных процессов. Если не пытаться переносить все состояния на целевую схему, то внезапно может оказаться, что картинка сильно упростится за счёт того, что «схлопнутся» некоторые состояния с переходами между ними. Опять же, если это подходит под решаемую вами задачу, а если нет, то могу только пожелать терпения:)
Первый же статус сущности "Заявка" - Принята. А где создание объекта, как это сделано для Договора?
Здесь "Принята", по сути, и означает факт создания заявки. Заявка порождалась, когда поступала из фронт-энда. Это можно читать как "мы приняли заявку из фронта".
Где финальный статус Заявки в положительном сценарии? Ну ведь не Доставлена, да?
Конкретно в этом случае была некоторая недосказанность в статусной модели мастер-системы для заявок. Разработчики этой системы исходили из того, что отправили заявку в систему 2-й компании, получили успешный ответ о доставке (грубо говоря, не сломались, не было тайм-аута и хорошо), значит заявка переходит в состояние «Заявка доставлена». Это и было финальным состояние.
Создан был договор или нет, по факту 1-я система не знала, об этом я и писал выше: «Более того, состояние «Заявка доставлена» вообще не гарантирует того, что сущность «Договор» была создана (вторая компания могла принять запрос на открытие договора, но по какому-то трагическому стечению обстоятельств так этого и не сделала).».
Но вот «Заявка отклонена» — это было состояние на всякий непредвиденный случай. Случай, когда во 2-й системе (там, где должны были породить сущность «Договор») эксперт принял бы решение, что договор завести никак нельзя, выявлена какое-то неустранимое препятствие. Для такого кейса был предусмотрен вызов 1-й системы из 2-й, в таком случае 1-я система бы получила сведение, что конкретно эту заявку забраковали. И тогда 1-я система переводила заявку, которую считала до того уже в финальном статусе, в новое состояние (ещё более финальное, если так вообще можно сказать:)).
В единой диаграмме, если появится финальный статус Заявки, то он и "Договор создан" обязаны быть не последовательными между сущностями, а одновременными. Нельзя иметь закрытую Заявку, но ещё не созданный Договор. Хотя в данном случае можно сначала создать Договор, и по факту успеха создания уже закрыть Заявку. В некоторых процессах статусы взаимозависимых объектов должны меняться одновременно.
Чуть выше я описал, что договор создавался уже после того, как заявка доставлена. Это были не одномоментные события в картине мира этих 2-х компаний. Да, если бы 2-я компания по факту приёма информации о заявке сразу создавала договор, то эти 2 статуса были бы одновременными, но в описанном мною случае эти этапы разрывались. Задачи править реализации обеих компаний не было, поэтому работали с тем, что есть.
Ну и, естественно, если бы финальный статус заявки означал начальный статус договора, то в единой статусной модели процесса был бы представлен только 1 статус (2 статуса «схлопнулись» бы в рамках созданной сущности «Процесс»).
Кстати, с софтом мы оказались сразу очень продуманными: вендорский иностранный не рассматривался в принципе в первых приоритетах, только опенсорс или отечественный
Софт для АСУ ТП тоже отечественный? Не Siemens какой-нибудь?
Соглашусь, что это не самое лёгкое чтиво. И, чтобы не было ложных ожиданий, я и маркировал статью "средним" уровнем. Помимо маркировки я надеялся донести мысли до аудитории и поэтому в тексте воспроизводил порядок событий, которые происходили на проектах, чтобы не было резких переходов от "было" до "стало", а также проиллюстрировал основные тезисы и соображения. Надеюсь, получилось.
Что же касается вебинара, то мысль интересная. Возможно, созрею до этого формата:) Хорошего дня!
Что касается PlantUML, то делал в онлайн-версии. В ней схема по умолчанию выглядит совсем невзрачно. Поэтому пришлось немного поколдовать, задав стили:
skinparam state {
BorderColor FireBrick
BackgroundColor LemonChiffon
}
skinparam arrow {
Color FireBrick
}
А далее уже по необходимости переопределял цвет фона:
...
state Created as "Договор создан" #PaleGreen
...
Смысл моего сообщения был в другом. Я не призываю делать так, как написал, я говорю, что такие подходы встречаются. Это просто данность в копилку кейсов, описанных автором статьи.
Спасибо за интересную статью. Я бы к ней добавил ещё 2 неоднозначных момента, с которыми сталкивался в жизни.
Есть мнение, что в случае, когда клиент обеспечивает идемпотентность (сам генерирует ID создаваемого ресурса и его передаёт в сервис через параметр или HTTP-заголовок), то лучше использовать PUT, а не POST.
Код 404 (Not Found) может возвращаться намеренно, когда на стороне сервиса определяется, что клиент не имеет доступа и надо в целях безопасности скрыть сам факт существования сервиса/ресурса.
Всё зависит от правил в конкретной компании. API могут проектировать разработчики, системные аналитики или архитекторы. У кого как заведено. Явных противопоказаний я не вижу.
Я верно понял, что предпроект и ТЗ вы делаете за отдельную плату? С согласен, что это тоже работа, притом довольно трудозатратная и требующая определённого уровня компетенций от её исполнителей. Но вот как, из вашей практики, обычно клиенты реагируют на предложение оплатить такие изыскания (ведь по их итогу клиент не получит тот конечный продукт, который рассчитывал)?
Дико извиняюсь, но в статье всё смешалось в кучу, а теория систем, как мне кажется, так вообще притянута за уши и осталась не понятой автором. Например следующие фразы оставили в моей голове одни вопросы.
Разве в этом примере сумма узлов не даёт ответ на вопрос, какая вариативность будет на выходе? По мне, так это просто конгломерат компонентов. Это как набор из 4-х ножек, одного сидения и одной спинки, сложенных рядом, нельзя считать стулом. В общем, не увидел здесь эмерджентных свойств.
А далее идёт фрагмент кода. О каких порождающихся новых паттернах речь, хотелось бы услышать. Как код смог адаптироваться к условиям внешней среды, мобилизовать свои ресурсы, измениться или создать внутри себя что-то новое, чтобы можно было говорить об адаптаци? Не уловил.
Эшби предполагал, что сложность управляющей системы должна соответствовать сложности управляемой системы. В вашем примере есть абстрактная система, которая почему-то должна адаптироваться к внешним условиям, т.е. связи по управлению не прослеживается.
В ряде профильных пабликов за "системную аналитику" вообще могут предать анафеме))
Делал в PlantUML, а, если быть точнее, то в её онлайн-версии (http://www.plantuml.com/). В PlantText тоже будет работать.
Метадерево в виде кода
С этого мы и начинали. Для бэка 1-й компании основная сущность — "Заявка". Там она и рождается как сущность, хотя и с названием статуса, который вам кажется неудачным:)
Думаю, мы прояснили все моменты. С праздником!
Этот раздел, как мне кажется, очень спорный. Да, знать SQL полезно, но вот как SQL позволит в человеке развить логическое мышление, я не уловил. Да и логика вообще бывает у всех своя и сильно разная:)
Почему-то в тексте во главу угла ставится именно запрос. Звучит так, словно предлагается не проработать решение задачи, а найти объяснение, почему что-то будет работать не в полной мере или не так, как хотелось заказчику.
В конце концов, мы же можем любой запрос переписать, индекс на таблицу навешать или ещё какие-то манипуляции на уровне БД произвести. А если пообщаться с архитектором, то может оказаться, что спектр вариантов решения бизнес-задачи ещё шире (например, СУБД стоит заменить, данные зарезервировать, шардировать, сделать кэш и пр.). Не SQL-ом единым, так сказать.
С ходу оценивать что-либо сложно. И знание SQL точно не будет ответом на все вопросы.
Я уже не уверен, что мне удастся вас убедить в том, что время это эктор. Просто попробуйте на это посмотреть как часть модели. Модель это всегда упрощение, но которое несёт практическую пользу.
Там фигурирует сущность "Операция". Поэтому и говорю, что безликая. Через эту сущность (фактически транспортный объект) в бэк передаётся всё что угодно: запрос какой-то информации, передача чего-то. Через эту сущность попадает, среди прочего, и заявка, просто "Заявка" как сущность создаётся именно в бэке, когда внутрянку проанализировали и поняли, что речь в данном конкретном объекте типа "Операция" идёт о необходимости открыть договор.
Такое ощущение, что вы пытаетсь меня убедить пойти и переписать системы, исходя из своего понимания прекрасного:)
"Принята" это в терминах бэковой системы. Они заявку приняли. То, что приём предполагает создание записи в соответствующей табличке БД,— это уже технические детали. Даже не понимаю, как можно не соглашаться с тем, кто как назвал в своей системе состояния. Это факт.
Формируется базово на фронте, но там оперируют понятием операции (безликая сущность с генерализованным названием) и, коль скоро для решаемой задачи этот сегмент процесса был признан несущественным, то приклеивать 3-ю сущность ("операцию") не понадобилось. Схема стала формироваться, начиная с 1-го бэка, а там термин "Заявка" в ней был основным.
А вот тут мы приходим к 2-м тезисам.
Во-первых, это частично и приводило к сложностям обслуживания. Но решать это выстраиванием петель обратной связи и сшиванием статусных моделей 2-х разных компаний посчитали не лучшей затеей. Да и системе мониторинга, которая живёт отдельно, это никак не помогает.
Во-вторых, владельцы систем и жили в парадигме границ: одна система отвечает за заявки, другая уже занимается договорами. И это обусловлено тем, что это 2 разные компании, которые жили каждая своей счастливой жизнью, но при выстраивании сквозного процесса (чтобы 1-я компания могла продавать через себя продукты 2-й) пришлось "подружить" системы.
Безусловно, такое тоже может иметь место. Даже допускаю, что статус "Заявка отклонена" и появился в ходе проработки подобной потребности (был один конечный статус, а бизнес пришёл и сказал, что желает знать об отказах). Но надо понимать, что задачи переделать системы и/или их взаимодействие не было (на это были свои резоны). Мне тоже не всё в имеющемся процессе нравилось, но это жизнь.
Эктором может быть что угодно, чьё поведение выступает триггером для функциональности. Это может быть конечный пользователь систем (самый очевидный вариант), другая система или время.
Вот пример из другой сферы. Раз в год компания формирует некоторую отчётность и отправляет её в регулирующие органы. Формирование отчётов можно представить как вариант использования, а человека признать эктором. Но тут вопрос: человек разве по своему разумению отправляет отчёты? Нет. Он не просыпается утром с мыслью: "Вот сегодня задам жару, отправлю отчёт". Тут обстоятельства, бизнес-правила, расписание вынуждают его это сделать. В такой конфигурации время будет наиболее логичным вариантом эктора. Ну и надо понимать, что не обязательно отчёт в данном случае формируется системой автоматически, тот самый человек вполне может требоваться, чтобы войти в систему, ввести параметры и нажать большую красную кнопку. Руками человека исполняется логика иного уровня.
Выгружают действительно Торговые системы А и Б, это и показано в форме эллипсов (варианты использования). Но они выполняют внешнюю логику, как описал двумя абзацами выше.
Да, это не так просто принять, поэтому практика применения эктора Time в диаграммах вариантов использования и в диаграммах последовательности не так распространена. Но тем не менее она есть и имеет свой смысл.
Спасибо за комментарий.
Добавлю несколько ремарок.
Если выполнение сценария инициируется по расписанию, введите в рассмотрение эктора Time (время), тогда жизнь сильно упрощается. Как я отметил в статье, это не моё изобретение, но это довольно слабо применяемая практика. Вот, например здесь ещё в 2009 году задавались вопросом, а правда ли так можно, и ответом было «да» со ссылкой на эту страницу.
Что касается границ системы, то тут был фокус как раз в применении системного подхода (почему-то большинство системных аналитиков его не изучало, но это тема для отдельной статьи:)). Так вот, собственно, системы входят в системы более высокого уровня (суперсистемы, надсистемы) и делятся на системы более низкого уровня (подсистемы). Системы любого уровня — это всё равно системы. А раз так, то можно не решать задачу в лоб, а обыграть это на синтаксисе UML.
Здесь у меня была логика, чем-то сходная с п.2. Если можно создать свою сущность, тогда формально ты не нарушаешь ничего. В конце концов, любая сущность при проектировании (та же «Заявка» и «Договор») — это не более чем модель, объект-заменитель, а значит изначально содержит определённый уровень условностей и допущений. А раз так, мы тоже можем создать свою сущность, которая тоже будет отражать в некотором приближении понятие реального мира, и уже её смоделировать доступными средствами.
Вот это звучит действительно серьёзно. Из опыта могу посоветовать посмотреть на всю эту красоту сверху и попытаться выстроить целевую статусную модель только с критически важными состояниями исходных процессов. Если не пытаться переносить все состояния на целевую схему, то внезапно может оказаться, что картинка сильно упростится за счёт того, что «схлопнутся» некоторые состояния с переходами между ними. Опять же, если это подходит под решаемую вами задачу, а если нет, то могу только пожелать терпения:)
Здесь "Принята", по сути, и означает факт создания заявки. Заявка порождалась, когда поступала из фронт-энда. Это можно читать как "мы приняли заявку из фронта".
Конкретно в этом случае была некоторая недосказанность в статусной модели мастер-системы для заявок. Разработчики этой системы исходили из того, что отправили заявку в систему 2-й компании, получили успешный ответ о доставке (грубо говоря, не сломались, не было тайм-аута и хорошо), значит заявка переходит в состояние «Заявка доставлена». Это и было финальным состояние.
Создан был договор или нет, по факту 1-я система не знала, об этом я и писал выше: «Более того, состояние «Заявка доставлена» вообще не гарантирует того, что сущность «Договор» была создана (вторая компания могла принять запрос на открытие договора, но по какому-то трагическому стечению обстоятельств так этого и не сделала).».
Но вот «Заявка отклонена» — это было состояние на всякий непредвиденный случай. Случай, когда во 2-й системе (там, где должны были породить сущность «Договор») эксперт принял бы решение, что договор завести никак нельзя, выявлена какое-то неустранимое препятствие. Для такого кейса был предусмотрен вызов 1-й системы из 2-й, в таком случае 1-я система бы получила сведение, что конкретно эту заявку забраковали. И тогда 1-я система переводила заявку, которую считала до того уже в финальном статусе, в новое состояние (ещё более финальное, если так вообще можно сказать:)).
Чуть выше я описал, что договор создавался уже после того, как заявка доставлена. Это были не одномоментные события в картине мира этих 2-х компаний. Да, если бы 2-я компания по факту приёма информации о заявке сразу создавала договор, то эти 2 статуса были бы одновременными, но в описанном мною случае эти этапы разрывались. Задачи править реализации обеих компаний не было, поэтому работали с тем, что есть.
Ну и, естественно, если бы финальный статус заявки означал начальный статус договора, то в единой статусной модели процесса был бы представлен только 1 статус (2 статуса «схлопнулись» бы в рамках созданной сущности «Процесс»).
Софт для АСУ ТП тоже отечественный? Не Siemens какой-нибудь?
Соглашусь, что это не самое лёгкое чтиво. И, чтобы не было ложных ожиданий, я и маркировал статью "средним" уровнем. Помимо маркировки я надеялся донести мысли до аудитории и поэтому в тексте воспроизводил порядок событий, которые происходили на проектах, чтобы не было резких переходов от "было" до "стало", а также проиллюстрировал основные тезисы и соображения. Надеюсь, получилось.
Что же касается вебинара, то мысль интересная. Возможно, созрею до этого формата:) Хорошего дня!
Интересно, спасибо!
Спасибо)
Что касается PlantUML, то делал в онлайн-версии. В ней схема по умолчанию выглядит совсем невзрачно. Поэтому пришлось немного поколдовать, задав стили:
А далее уже по необходимости переопределял цвет фона:
У меня 2 вопроса:
На C2 2-го уровня стрелки от экторов идут до системы "Единое окно", а не до входящих в неё модулей. Просьба уточнить, это было сделано намеренно?
Я верно понял, что у вас в банке заказчик задачу приносят именно архитектору? Или я неверно трактовал вводные?
Смысл моего сообщения был в другом. Я не призываю делать так, как написал, я говорю, что такие подходы встречаются. Это просто данность в копилку кейсов, описанных автором статьи.
Спасибо за интересную статью. Я бы к ней добавил ещё 2 неоднозначных момента, с которыми сталкивался в жизни.
Есть мнение, что в случае, когда клиент обеспечивает идемпотентность (сам генерирует ID создаваемого ресурса и его передаёт в сервис через параметр или HTTP-заголовок), то лучше использовать PUT, а не POST.
Код 404 (Not Found) может возвращаться намеренно, когда на стороне сервиса определяется, что клиент не имеет доступа и надо в целях безопасности скрыть сам факт существования сервиса/ресурса.
Всё зависит от правил в конкретной компании. API могут проектировать разработчики, системные аналитики или архитекторы. У кого как заведено. Явных противопоказаний я не вижу.
Я верно понял, что предпроект и ТЗ вы делаете за отдельную плату? С согласен, что это тоже работа, притом довольно трудозатратная и требующая определённого уровня компетенций от её исполнителей. Но вот как, из вашей практики, обычно клиенты реагируют на предложение оплатить такие изыскания (ведь по их итогу клиент не получит тот конечный продукт, который рассчитывал)?