Конечно, в диаграмме, которую автор выбрал для разбора, есть ошибки. Однако они вовсе не в том, что автор статьи определил как ошибки. И автор выдумал, для якобы упрощения, какую-то свою интерпретацию диаграммы. Бог бы с ним, если бы для внутреннего пользования. Но он же пытается нести это доброе и вечное в массы. Да еще помогает на этом обучать ИИ :) Ну, а потом да, будем говорить UML умер! Туда ему и дорога мол.
Соглашусь с автором, чаще используется программная инженерия, технология программирование, чем термин конструирование. Возможно в советские и постсоветские годы такой термин встречался чаще, но с вводом Болонской системы и активным изменением ГОС, такой термин стал считаться устаревшим.
Монолитная архитектура не является оксюмороном, потому что она не сочетает взаимоисключающие понятия. Это просто описание структуры системы, где все компоненты тесно связаны.
Если взять к примеру здание - как монолит, т.е. нечто цельное, которое не может быть разобрано без потери этой целостности. Но по сути это относится к способу производства такого здания, архитектура все равно предполагает наличие частей, структуры, принцип соединения и т.п. архитектурные качества, т.е. в здании возведенном по монолитной технологии есть несущие конструкции, есть входы и выходы - тоже что и в сборной хрущевке.
Давно замечаю, что многие, кто использует UML и вот такие "методики" как ОО анализ, совершенно не владеют синтаксисом и семантикой такого языка.
Как может бизнес-потребность зависеть от подхода бизнес-анализа. Если используешь собственную нотацию, то следует потрудиться над представлением легенды.
Мне кажется, там простым (на английском, что редкость) языком и очень лаконично, но емко разобраны как вообще разрабатывать use case. Конечно, книга издана давно. Предисловие написано Иваром Якобсоном. В аннотации можно найти следующее.
In Use Case Modeling, experienced use case practitioners Kurt Bittner and Ian Spence share their tips and tricks for applying use cases in various environments. They delve into all aspects of use case modeling and management, demonstrating how development teams can capitalize on the approach's simplicity when modeling complex systems.
In this ready reference, readers will discover how to:
Introduce a development team to use cases and implement a use case approach
Identify the key elements of a use case model, including actors; and the components of a use case, including basic flow, preconditions, post-conditions, sub-flows, and alternate flows
Master the objectives and challenges of creating detailed descriptions of use cases
Improve their descriptions' readability and consistency
Prevent and remedy common problems arising from the misuse of include, extend, and generalization use case relationships.
Organize and conduct a review of a use case model to realize the best possible approach
Книгу могу дать, хотя Вы ее легко найдете в открытом доступе.
Я не являясь математиком в смысле эксперта, запросил консультацию у математика, изучающего и преподающего матлогику в течение нескольких десятков лет. Получил аналогичный ответ сходу. Т.е. это у человека сработал математический инстинкт.
Это не статистика. Это ваше субъективное наблюдение, возведенное в ранг обобщения. Так вам угодно строить диалог с читателями, манипулируя и провоцируя их внимание к вашим идеям.
Вы никак не можете уяснить и запомнить, что иметь в виду пишется вот так, а не иначе. Какой-то психологический залом у вас?
Понятно, что мир большой, и я не слышал ни одного аналитика, который бы говорил подобным образом. Это, конечно, не приводит к тому, что нет аналитиков так говорящих. Заметьте, я не делаю общих выводов из своего ограниченного наблюдения, а вы почему-то делаете. Не придерживаетесь ни формальной, ни о более строгой математической логике.
я набрел на две ключевые идеи, которые мне не дают покоя, потому что переворачивают все классические представления о том как происходит принятие решений
А почему дальше идут три пункта. И в чем их особость? В том, что мышление субъект группы? И только группы? Мне кажется, это слишком смелое утверждение. Или ты предполагаешь, что индивидуум, даже если он один, все равно ведет себя как группа, общаясь, так сказать, с внутренним собеседником?
Да, я сразу хотел пометить статья как перевод. И в комментариях там писал модератору, если он не затерся. А можно ли прямо сейчас пометить как перевод?
Чем инклюд отличается от экстенда на рисунке? Если по UML там логика простая базовый ВИ, тот от которого идет стрелка в случае инклюд, включает некое поведение в обязательном порядке, а в случае экстенда стрелка идет в сторону базового ВИ, т.е. его расширяет при соблюдении какого-то условия.
Тут же получается, что фотографирование лица включает заполнения профиля. Не ясна логика чтения схемы.
Конечно, в диаграмме, которую автор выбрал для разбора, есть ошибки. Однако они вовсе не в том, что автор статьи определил как ошибки. И автор выдумал, для якобы упрощения, какую-то свою интерпретацию диаграммы. Бог бы с ним, если бы для внутреннего пользования. Но он же пытается нести это доброе и вечное в массы. Да еще помогает на этом обучать ИИ :) Ну, а потом да, будем говорить UML умер! Туда ему и дорога мол.
Соглашусь с автором, чаще используется программная инженерия, технология программирование, чем термин конструирование. Возможно в советские и постсоветские годы такой термин встречался чаще, но с вводом Болонской системы и активным изменением ГОС, такой термин стал считаться устаревшим.
Монолитная архитектура не является оксюмороном, потому что она не сочетает взаимоисключающие понятия. Это просто описание структуры системы, где все компоненты тесно связаны.
Если взять к примеру здание - как монолит, т.е. нечто цельное, которое не может быть разобрано без потери этой целостности. Но по сути это относится к способу производства такого здания, архитектура все равно предполагает наличие частей, структуры, принцип соединения и т.п. архитектурные качества, т.е. в здании возведенном по монолитной технологии есть несущие конструкции, есть входы и выходы - тоже что и в сборной хрущевке.
Обзоры устаревают. Раньше делал, что-то. Одно время использовал https://www.3ds.com/products-services/catia/products/no-magic/magicdraw/. Есть даже академическая лицензия.
Был знаком даже с основателем вот этого проекта: https://www.modeliosoft.com/en
Давно замечаю, что многие, кто использует UML и вот такие "методики" как ОО анализ, совершенно не владеют синтаксисом и семантикой такого языка.
Как может бизнес-потребность зависеть от подхода бизнес-анализа. Если используешь собственную нотацию, то следует потрудиться над представлением легенды.
In Use Case Modeling, experienced use case practitioners Kurt Bittner and Ian Spence share their tips and tricks for applying use cases in various environments. They delve into all aspects of use case modeling and management, demonstrating how development teams can capitalize on the approach's simplicity when modeling complex systems.
In this ready reference, readers will discover how to:
Introduce a development team to use cases and implement a use case approach
Identify the key elements of a use case model, including actors; and the components of a use case, including basic flow, preconditions, post-conditions, sub-flows, and alternate flows
Master the objectives and challenges of creating detailed descriptions of use cases
Improve their descriptions' readability and consistency
Prevent and remedy common problems arising from the misuse of include, extend, and generalization use case relationships.
Organize and conduct a review of a use case model to realize the best possible approach
Книгу могу дать, хотя Вы ее легко найдете в открытом доступе.
Понятно, что мир большой, и я не слышал ни одного аналитика, который бы говорил подобным образом. Это, конечно, не приводит к тому, что нет аналитиков так говорящих. Заметьте, я не делаю общих выводов из своего ограниченного наблюдения, а вы почему-то делаете. Не придерживаетесь ни формальной, ни о более строгой математической логике.
А почему дальше идут три пункта. И в чем их особость? В том, что мышление субъект группы? И только группы? Мне кажется, это слишком смелое утверждение. Или ты предполагаешь, что индивидуум, даже если он один, все равно ведет себя как группа, общаясь, так сказать, с внутренним собеседником?
Вопрос не простой, но к.м.к таким человеком (или группой людей) может быть архитектор решения.
Как минимум, когда решение достаточно типовое, ну и не прибавляет стоимости и не будет увеличивать сроки поставки.
Тут же получается, что фотографирование лица включает заполнения профиля. Не ясна логика чтения схемы.