dmitryshm, Автор в Антикризисный ларец

Опубликовано 03.02.202506.02.2025 от dmitryshm

Проектирование RUP/ICONIX. 7-ой этап

Содержание других частей.

Это последний этап активного проектирования в ICONIX перед вехой поставки готовой системы. Седьмой этап называется рецензирование окончательного проекта. На этом этапе проверяется, что все ответы на вопрос «как», указанные в диаграммах последовательности и связанных диаграммах классов, которые делались на шестом этапе, связаны с ответами на вопрос «что» в модели прецедентов, которая могла претерпевать изменения на предыдущих этапах.

На этапе 7 в ходе рецензирования окончательного проекта проверяется, что проектирование отвечает стандартам предприятия. Проверяют порядок применения шаблонов проектирования и стандартных для данного предприятия фреймворков. На этом этапе работают исключительно проектировщики и разработчики.

Для всех прецедентов должны быть диаграммы последовательности, созданные на шестом этапе, для всех сценариев прецедентов, как главных, так и альтернативных. Все переходы на диаграммах последовательности должны представляться конкретными методами соответствующих классов. Соответственно и сигнатуры этих методов должны быть ясны, и структуры данных, передаваемые в качестве параметров методов также надо отразить на соответствующих диаграммах классов.

В силу применения шаблонов проектирования на текущем этапе также могут выделиться абстрактные структуры, делающие применение выбранных парадигм программирования более правильным. Если раньше у нас объекты должны были отражать существующие в реальности понятия, то сейчас мы можем себе позволить подойти к проектированию чисто с точки зрения программирования. Многие программисты и рассматривают проектирование как только лишь текущий этап. Но мы с вами видим, сколько работы надо проделать до того, чтобы проектирование связанное с исходным кодом программного обеспечения было привязано к требованиям.

Вот самые распространённые ошибки при рецензировании окончательного проекта.

Не приглашают технических специалистов. Этап 7 нужен только для проектировщиков и разработчиков. Иначе все построения на предыдущих этапах не будут иметь никакого смысла в ходе реализации требований.
Не сверяют тексты прецедентов с диаграммами последовательности. Выбор фреймворков и шаблонов проектирования не должен нарушать работу, проделанную на шестом этапе.
Не проверяют направления стрелок на диаграммах последовательности. Корректная передача управления при реализации прецедентов очень важна. Иначе диаграммы последовательности это всего лишь бесполезные картинки.
Забывают применить шаблоны проектирования и фреймворки в работе над проектом. Не забывайте, что эти модели нужны для программистов и проектировщиков. Иначе это всё бесполезная деятельность. Шаблоны и фреймворки так или иначе будут применены, но получится, что модели и код будут рассинхронизированы. В случае работы со Sparx EA можно привязать проект исходного кода компонентов, которые пишутся программистами в проекте, к диаграммам классов.
Не продумывают все детали реализации. Все детали на этом этапе должны быть учтены. Должно остаться только лишь закодировать.
Рисуют диаграммы последовательности, не привязанные к выбранным фреймворкам реализации. Например выбрали фреймворк, где используется фабрика объектов, а на диаграмме объекты создаются почему-то сами по себе.
Рецензируют диаграммы последовательности не для всех прецедентов и их сценариев. Без подробной проработки на этом этапе вся предыдущая работа будет бесполезной. Ничего «само собой разумеющегося» оставаться в проекте на этом этапе не должно.

Вот мы и завершили описание применения RUP/ICONIX на ваших проектах. Осталось лишь несколько ремарок.

Прошу рассматривать ICONIX как инструмент, решающий задачи на вашем проекте. Если задача простая и не требует проектирования, т.е. нет тех сложностей, ради которых надо выполнять вехи и этапы в них, то можно обойтись и поверхностными ответами на многие вопросы проектирования. Критерий применимости простой. Ценность проектирования должна быть выше затрат на работы. ICONIX даёт понимание о структуре работ, из которой должно быть примерно понятно, какие оценки трудозатрат надо учитывать в вашем конкретном случае.

Сам по себе RUP/ICONIX существует давно, и уже слышатся голоса, что «UML умер». Описание, данное в этом цикле статей, указывает лишь на способ ответа на вопрос «что» и привязке к ответам на вопрос «как» с выводом результатов на этап реализации (кодирования). В любом процессном фреймворке должны существовать ответы на эти вопросы с достаточным количеством связей, чтобы применять в работе. Соответственно спросите ваших «UML умер»альщиков, чем они способны заменить элементы ICONIX в своём понимании о процессе разработки, и как правило не услышите ничего особо вразумительного. В достаточно сложном проекте от того, что отказались от чего-то, необходимость в выполнении определённых ролей не отпадает, т.к. со сложностью всё равно надо что-то делать. Часто «UML умер»альщики это просто несостоявшиеся проектировщики, отрицающие инструмент, т.к. не освоили его, и считают, что и в проекте он не нужен. В этом случае либо задача простая, либо персонал проекта не соответствует поставленным задачам. На мой взгляд на данный момент хорошей альтернативы RUP/ICONIX и проектированию на UML/SysML в проектах средней сложности до 1 млн. строк кода или аналогам — не имеется, а то, что по сложности меньше порядка 100 тыс. строк кода — как правило в таком проектировании и не нуждается, т.к. мало сложностей, и соответственно ценность проектирования будет меньше затрат на него. В иных случаях затраты на проектирование вполне оправданы, и его отсутствие лишь удорожит разработку, т.к. не были применены нужные инструменты. Тоже часто встречающаяся ситуация, т.к. правильно проектировать ещё не научились, и точка зрения, что можно обойтись без проектирования, легко побеждает.

Поборникам Agile и процессных фреймворков на основе Scrum или аналогов также можно использовать ICONIX, т.к. в рамках итераций также можно выполнять работы из ICONIX и работать с его артефактами. Только итерации будут часто месячные, а не недельные. Если двигаетесь недельками, то либо задачи нетяжёлые, либо кто-то уже их качественно для вас поставил, и сложности не мешают формировать бэклог понятным образом без больших переделываний своей работы вновь и вновь. Если всё же переделываний много, то это как раз случай, когда не применяются все необходимые для проектирования инструменты, из-за чего стоимость разработки выше возможной. Высокую цену тоже можно себе позволить, если рынок этого требует. Но я слишком часто вижу, как рынком просто прикрывают свою некомпетентность. Слишком много «специалистов по рынку» развелось, чтобы просто проигнорировать их попытки поучаствовать в обсуждении важных вещей для проекта.

PS: те из вас, кто хотел бы создать или укрепить свою компетенцию аналитиков — пожалуйста обращайтесь. Для вас хорошо подойдут эти услуги: раз, два, три, четыре.

Опубликовано 26.01.202506.02.2025 от dmitryshm

Проектирование RUP/ICONIX. 6-ой этап

Содержание других частей.

Начинается новая веха ICONIX — окончательный проект. Веха предварительного проекта завершилась на этапе 5. На текущем этапе номер 6 наступает очередь детального проектирования. Откройте проект Sparx EA, в которым работали на предыдущих этапах, и добавьте модель для диаграмм последовательностей.

В новой модели для последовательностей решаются следующие задачи.

Распределяют поведение между сущностными и управляющими объектами.
Определяют детали взаимодействия между объектами.
Распределяют операции по методам классов объектов.

В ICONIX диаграммы последовательности это основной инструмент детального проектирования. Для каждого прецедента модели предметной области и соответственно каждой диаграмме пригодности (т.к. тоже создавались на каждый прецедент на этапе 4) в новой модели для диаграмм последовательности добавьте диаграмму, на которой изобразите основные последовательности и альтернативные последовательности прецедента. Диаграммы последовательности можно организовывать по-разному, но рекомендуется следующий порядок.

Слева оставьте место для словесного описания шагов последовательности. Текст разбирается на фрагменты, соответствующие шагам.
Из соответствующей прецеденту диаграммы пригодности перенесите объекты (диаграммы пригодности создавались на этапе 4 и уточнялись на этапе 5).
Добавьте сообщения между объектами, обозначаемые стрелками.
Для каждого сообщения добавьте методоы в классы объектов, куда направлены стрелки. Сообщение — это передача информации тому, кому сообщение направляется в параметрах метода. По сути вызов метода у класса.

Рекомендуемый порядок, расписанный более подробно, при конструировании последовательности такой.

Скопировать текст прецедента из его спецификации в текстовую область слева.
Добавить сущностные объекты из диаграммы пригодности прецедента.
Добавить граничные объекты из диаграммы пригодности прецедента.
Сформулировать последовательность прецедента без дополнительных контроллеров диаграммы пригодности, формулируя взаимодействия объектов в виду вызовов методов с соответствующими параметрами или дополнительными структурами. Если не получается, то добавить объекты контроллеров на диаграмму последовательности и направляйте сообщения сперва в них, потом от контроллеров к сущностным объектам и обратно. При добавлении контроллеров старайтесь в них инкапсулировать сложное поведение, перемещая преобразования в них. В ходе работы применяйте паттерны объектно-ориентированного анализа и проектирования (ООП). Сейчас для них самое время.
Формировать вспомогательную диаграмму классов для каждой последовательности.

В ходе детальной проработки последовательностей допускают следующие ошибки.

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

Таким образом на этапе 6 все прецеденты у вас превратятся в детальные последовательности и добавятся детальные диаграммы классов с методами и детализированными связями. С этим уже будет удобно работать при оформлении детального окончательного проекта на следующем этапе, где вы уже чётко будете понимать, какие конкретно класссы с какими конкретно методами. Появятся мысли по корректной упаковке классов в пакеты соответственно применяемому фреймворку, выбранному для реализации.

Опубликовано 18.01.202506.02.2025 от dmitryshm

Проектирование RUP/ICONIX. 5-ый этап

Содержание других частей.

Пятый этап ICONIX рецензирует преварительный проект перед началом следующей вехи — окончательного проекта. На прошлом этапе в отдельной модели выполнялся анализ пригодности. Рецензирование предварительного проекта на этом этапе включает в себя проверку, что модель с диаграммами пригодности соответствует всем текстам прецедентов. Отдельно проверяют, что все сущностные объекты представлены в диаграмме пригодности и расписаны взаимодействия с ними. Откройте проект Sparx EA, с которым работали на предыдущих этапах.

На этом этапе рецензирования предварительного проекта проверяют по ходу потока данных от граничных объектов на диаграммах пригодности до сущностных объектов, что все данные, которые вводит пользователь, осядают либо в виде отдельных сущностных объектов, либо в их атрибутах (полях классов). Все экранные формы на прототипах должны соответствовать граничным объектам. Выделяют классы и добавляют в них поля, как правило приватные для обеспечения должной инкапсуляции. Иногда уже на этапе рецензирования предварительного проекта может выясниться, что забыли какие-то классы сущностей. Тогда и предыдущие этапы надо будет учесть, если такая сущность добавится.

Рецензирование предварительного проекта хорошо проводить с представителем заказчика, т.к. в ICONIX это последний этап перед тем, как заказчику на текущей итерации разрешено вносить изменения. В ходе рецензирования все участвующие лица должны выполнить следующее:

Перебирая все прецеденты выбрать очередной прецедент и прочитать его сценарии.
На диаграмме пригодности, отвечающей выбранному прецеденту (1) визуально проследить ассоциации.
Убедиться в соответствии текстовок (1) и картинки (2).

Таким образом поведение всех прецедннтов будет классифицировано при помощи преполагаемых управляющих объектов-контроллеров. Следует отдельно подчеркнуть, что контроллеры на этапе предварительного проекта не обязаны ещё присутствовать на диаграмме классов. Не все контроллеры будут инкапсулировать взаимодействие граничных объектов и сущностных, т.к. часть такого взаимодействия будет простой и не достойной на отдельного класса. Принимать решение, какие методы должны войти в граничные и сущностные объекты, а также о том, какие контроллеры станут настоящими управляющими объектами мы не можем на этом этапе, т.к. не обладаем достаточной информацией об этом. Мы можем на этом этапе выбрать фреймворки и библиотеки для реализации, и многое из сказанного будет уже напрашиваться. Но бежать впереди процесса не стоит, чтобы лишний раз не переделывать работу. Это делается на этапе работы с диаграммами последовательности, т.е. на следующем этапе.

На текущем этапе рецензирования хорошо проверяется единый стиль написания прецедентов и их сценариев, если текстовки писались несколькими людьми.

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

Этап рецензирования предварительного проекта это конечный пункт перед работой над окончательным проектом. Вот распространённые ошибки на этапе рецензирования предварительного проекта.

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

Таким образом на этапе предварительного проекта вы проходите с заказчиком на детальный окончательный проект — следующую веху, где поведение системы в проекте нельзя менять. Это будет слишком дорого.

Опубликовано 11.01.202506.02.2025 от dmitryshm

Проектирование RUP/ICONIX. 4-ый этап

Содержание других частей.

Этап 4 начинает вторую веху проектирования после первой вехи, где подготовили требования. Вторая веха называется «предварительный проект». И начинается он — с анализа пригодности, 4-го этапа проектирования.

В проект Sparx EA, где работали на предыдущих этапах, добавьте модель для ведения анализа пригодности. Sparx EA называет её моделью с диаграммами коммуникации, а мы будем это называть как полагается в ICONIX — анализом пригодности.

Модель для проведения анализа пригодности в рамках вехи предварительного проекта связывает статическую модель предметной области и динамическую модель прецедентов. Анализ пригодности отвечает на вопрос — какие объекты из модели предметной области нужны для каждого прецедента. Ранее, создавая матрицу отношений модели предметной области и модели прецедентов мы поверхностно отвечали на этот вопрос, но лишь для того, чтобы проверить себя, не забыли ли что в каждой из моделей.

Диаграммы пригодности — это по существу диаграммы классов UML, но с проставленными стереотипами классов. Классы классифицируются по 3 видам:

граничные: с объектами этих классов взаимодействуют актёры для вхаимодействия с проектируемой системой;
сущностные: объекты этих классов обычно фигурируют прямо в предметной области один в один, это либо классы источники информации, либо классы стоки информации, либо и то, и другое; часто это классы т.н. модели данных;
управляющие: нужны для обеспечения корректной передачи управления от граничных к сущностным объектам, их ещё называют контроллерами.

Анализ пригодности служит звеном, позволяющим переходить от вопросов «что» к вопросам «как». В вехе предварительного проектирования ICONIX уже начинают задумываться о возможных альтернативных стратегиях реализации и архитектурах, выбор которых зависит от применяемых технологий. Выбор ещё не осуществлён, но анализ пригодности сужает поиск и подсказывает с выбором. В ходе анализа пригодности мы в прецедентах уже имеем описания сценариев, изложенных с учётом требований заказчика. В ходе анализа пригодности уточняются и тексты прецедентов, и модель предметой области. Классификация объектов на граничные, сущностные и управляющие может заставить добавить недостающие классы. Анализ пригодности связывает объекты, но уже накладывает ограничения на связи. Далее это сильно поможет при проектировании последовательностей в окончательном проекте.

Для каждого прецедента в модели пригодности создайте отдельную диаграмму. Диаграмма пригодности должна показать какие объекты как взаимодействуют, чтобы реализовать сценарии прецедента. На диаграммах пригодности размещают актёров, которые в модели прецедентов размещались на диаграммах вариантов использования и взаимодействуют с анализируемым прецедентом. На диаграммах пригодности размещают прецеденты, с которыми взаимодействует анализируемый прецедент. Связи на диаграммах пригодности являются направленными и означают, что один объект обращается к другому. Если есть 2 связи в обе стороны, то вместо них можно создать одну двунаправленную. Для диаграммы пригодности есть 4 правила.

Актёры могут взаимодействовать только с граничными объектами.
Граничные объекты могут общаться только с контроллерами и актёрами.
Сущностные объекты могут общаться только с контроллерами.
Контроллеры могут общаться со всеми, кроме актёров.

Граничные и сущностные объекты надо называть существительными, а контроллеры — глаголами. Таким образом правила легче запомнить как «существительные не общаются с сущетвительными напрямую, только через глаголы».

В результате анализа пригодности могут подвергнуться серъёзным уточнениям модели первой вехи: модели предметной области (выявятся новые сущности, старые сущности притерпят изменения), модели прецедентов (сценарии перепишутся, т.к. для реализации некоторых более выгодны будут другие глаголы и сущетвительные; часть прецедентов будет дисквалифицирована, поделена или объединена), и как следствие модель требований также потребует изменений, что может повлиять на согласования, проведённые на этапе рецензии требований. Но если на этапе анализа пригодности поменялись требования, то повторно утверждать их на этом этапе не надо — надо подождать окончательного проекта (т.е. позже).

В ходе анализа пригодности часто совершают следующие ошибки.

Нарушают правила взаимодействия объектов, описанные выше.
Не меняют тексты прецедентов в ходе анализа. Правила взаимодействия объектов должны коснуться и самих текстов прецедентов, т.к. объекты и их взаимодейсвтия реализуют сценарии прецедента.
Игнорируют альтернативные сценарии прецедентов в анализе пригодности. Альтернативные сценарии надо реализовывать так же, как и основные. Это порядок реакции на ошибки и т.п..
Имена классов модели пригодности и тексты прецедентов не согласуются.
На этапе анализа пригодности нет достаточной информации для выделения методов, которые нужны классам. Не надо указывать методы у классов на этом этапе. Это делается позже.
Если на диаграмме пригодности для прецедента становится слишком много контроллеров (более 10), то прецедент получился слишком большой, и его надо делить на несколько. Если контроллеров мало, один или два, значит прецедент недостаточно обусловлен, как отдельный, и надо его отнести к какому-то существующему. Либо прецедент недостаточно проанализирован.
Зацикливаются на диаграммах пригодности и пытаются всё дальнейшее проектирование провести на них. Повторимся, для анализа операций и выделения методов классов пока недостаточно информации. Кто с кем объается это ещё не методы.
Не выполняют сверку диаграммы пригодности и текстов прецедента.
Ленятся обновлять статическую модель. Не добавляют новых классов на диаграммы классов, модель предметной области идёт вразнобой с анализом пригодности, т.е. становится непригодной.

Выполняйте анализ пригодности качественно, чтобы на следующем этапе при анализе операций не выполнять слишком много правок.

Опубликовано 05.01.202506.02.2025 от dmitryshm

Проектирование RUP/ICONIX. Третий этап

Содержание других частей.

Третьим этапом завершается первая веха проектирования — рецензирование требований. В ICONIX этих вех всего 4

требования
предварительный проект
окончательный проект
поставка готовой системы

При описании этапов вехи намеренно пропущены, чтобы не загромождать повествование. Третьим (текущим) этапом завершается первая веха.

Задача этого этапа — выяснить и явно зафиксировать, что модель предметной области и модель прецедентов соответствует всем требованиям заказчика. В проект Sparx EA, где на прошлых этапах мы добавили модель предметной области и модель прецедентов, добавьте модель требований.

В модели требований необходимо решить несколько задач.

Собрать всё что говорит заказчик, со слов, с документов, с писем и т.п.. Все материалы важны со ссылками на источники.
Внести (1) в структуру требований модели. Между элементами структуры имеются отношения, которые хорошо отображать как при помощи матрицы отношений, диаграммы требований и самой спецификации требований.
Согласовать (2) с заказчиком.
Задокументировать (3) и при необходимости экспортировать в документ, годный для заказчика (например выполнив по ГОСТ, применив или разработав подходящий шаблон отчёта Sparx EA).
Утвердить подписями при необходимости. Требования можно превратить в формальный документ, по которому можно сверяться, трассируя выполнение обязательств на него и фиксируя это, например в ПМИ (в программе и методике испытаний).

Каждый элемент (1) структуры (2) трассируйте на элементы предметной области и элементы прецедентов. Должно получиться 2 новые матрицы, где нет пробелов по строкам и столбцам. Спецификация требований должна выгружаться в документ (4) и быть хорошо читаемым заказчиком. Вообще, заказчик может вообще не знать, что вы применяете ICONIX в работе. Но каждый элемент требований желательно делать самостоятельным, ёмким и атомарным.

Когда будете трассировать элементы модели требований на элементы модели прецедентов — выполняйте грамматический анализ текстов прецедентов (названий и связанных с ними словесных описаний сцераниев). Рекомендуется использовать действительный залог (активный), а не страдательный (пассивный) для формулировки действий пользователя.

В ходе этого этапа избегайте следующих ошибок.

Создают слишком абстрактные прецеденты, которые связаны со слишком большим количеством требований заказчика.
Фиксируют слишком абстрактные требования заказчика, трассирующиеся на слишком большое количество прецедентов.
Забывают, что объекты предметной области должны отвечать объектам реального мира, где работает система.
В ходе правки модели прецедентов не перепроверяют связности этой модели с моделью предметной области (т.е. не проверяют, что работа второго этапа не ломается при выполнении третьего).
Игнорируют описания альтернативных последовательностей прецедентов при моделировании требований. Заказчика надо выспрашивать и про альтернативные сценарии тоже.
Тексты элементов требований и тексты описаний сценариев делают слишком объёмными, не делят требования на элементы и прецеденты на элементы более атомарных прецедентов.

Названия «этап», «веха» могут оттолкнуть от методологии ICONIX. Но несмотря на названия вы не обязаны выполнять эти этапы и вехи длительное время затрачивая большие ресурсы. Как раз ICONIX позволит выполнить работу качественнее и быстрее, делая проектирование инструментом, уменьшающим риски на ранних этапах проекта.

Опубликовано 30.12.202406.02.2025 от dmitryshm

Проектирование RUP/ICONIX. Второй этап

Содержание других частей.

Вторым этапом ICONIX является моделирование прецедентов. В существующий проект с моделями Sparx EA, в котором работали на первом этапе , надо добавить модель прецедентов.

Работа системы зависит от того, как к ней обращаются и что хотят добиться. В моделировании прецедентов двигаются снаружи внутрь: рассматривают внешних по отношению к системе актёров и те действия, которые эти актёры производят с системой. Подчеркну, что на прошлом этапе при создании модели предметной области движение было изнутри наружу: определяли ключевые объекты внутри системы и их отношения с объектами, с которыми они взаимодействуют. Начали мы с модели предметной области, со статической части, для того, чтобы в контексте этой статической части работать с динамической частью — с моделью прецедентов. При этом обновляться и уточняться при моделировании прецедентов могут обе модели если обнаружится, что забыли какие-то моменты.

Важно на этапе моделирования прецедентов начинать представлять границу нашей системы, для которой проектируется программное обеспечение. Актёры не являются частью нашей системы. Это могут быть как люди, так и системы, с которыми взаимодействует наша.

Продумайте, какие имеются актёры, внешние по отношению к проектируемой системе, взаимодействующие с ней. В модели прецедентов создайте диаграмму прецедентов, добавьте туда своих актёров и связанные с ними прецеденты. Старайтесь называть прецеденты 1-2 словами, точно и емко. Подробные словесные описания в Sparx EA можно составлять при помощи описания словесных сценариев, связанных с этими прецедентами.

Подобно элементам модели предметной области, элементы модели прецедентов также надо делать с одной стороны ёмкими, а с другой повторно используемыми, атомарными. Некоторые варианты использования вашей системы могут повторно пригодиться при работе с несколькими разными актёрами. Переходы в один и тот же прецедент возможен из разных других прецедентов, и т.д.. Таким образом у вас образуется структура прецедентов, объединённая в модель. У каждого прецедента в модели будет словесное описание в виде сценария. Сценарии очень похожи на пользовательские требования. Если от заказчика у вас имеются материалы, содержащие такие требования — их как раз нужно структурировать при моделировании прецедентов.

Главный принцип при выявлении прецедентов — их тесная связь с будущим руководством пользователя. Связь каждого прецедента и соответствующим разделом будущего руководства должна быть очевидной. Модель прецедентов это та часть проекта системы, которая базируется на восприятии её пользователями. Таким образом если в проекте системы на этом этапе есть прототипы пользовательских интерфейсов, например в Figma, то это будет большим подспорьем. На этом этапе аналитик и дизайнер максимально продуктивны в проектировании как внешнего вида, так и поведения будущей системы и её программного обеспечения.

Сценарии в основе словесного описания прецедентов должны состоять из утверждений по форме «существительное-глагол-существительное». Вы уже наверняка догадались, что эти существительные — это классы модели предметной области, а глаголы это связи между ними. Если в ходе описания прецедентов появляются существительные, не описываемые какими-либо классами модели предметной области — уточняйте эту модель, внося туда классы и корректируя существующие. Со связями аналогично.

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

В модели прецедентов таким образом наберётся существенное количество прецедентов и связей между ними. То, каким образом можно корректно их связывать между собой через отношения включения или расширения UML — решать вам. Но выбрав один раз способ построения связей — не путайте этот способ с другими, например со связями типа вызова и предшествования, которые тоже будут в меню выбора типов связей. Далее прецеденты нужно будет объединить в пакеты, чтобы облегчить себе работу с ними. Хорошим кандидатом на помещение очередного прецедента в пакет с другими прецедентами будет прецедент, сильно связанный с остальными прецедентами из этого пакета.

Не стремитесь изобразить все прецеденты на одной диаграмме. Если система достаточно сложная, то различные её грани вариантов использования удобно располагать на различных диаграммах прецедентов. В идеале, каждый пакет прецедентов соответствует главе или разделу будущего руководства пользователя.

Для того, чтобы проверять взаимное соответствие модели предметной области и модели прецедентов, в Sparx EA есть инструмент под названием «матрица отношений», на которой можно просталвять связи между элементами как одной модели, так и элементами разных моделей. Таким образом матрица соответствия модели предметной области и модели прецедентов со связями типа «реализует» должна быть без пробелов по строкам и столбцам.

Переходить к следующему этапу проектирования следует только после того, как будут достигнуты цели модели прецедентов:

созданные прецеденты описывают всю требуемую функциональность системы
для каждого прецедента чётко и кратно описана главная последовательность действий, а также все альтернативные последовательности
выделены (чаще всего в отдельные прецеденты) сценарии, общие для нескольких прецедентов (не допускайте дублирования при описании)

Вот распространённые ошибки в моделировании прецедентов.

Словесный сценарий прецедентов в стиле «существительное-глагол-существительное» это не функциональные требования. Объекты и взаимодействие между ними — вот что главное.
Сконцентрируйтесь на порядке использования, а не на атрибутах и методах. Не надо ссылаться на поля экранных форм. Детали с атрибутами и формами учитываются потом.
Не экономьте слов при описании прецедентов. Лучше описать слишком много, чем упустить что-то из виду.
Нельзя абстрагироваться от интерфейса пользователя. Если есть прототипы интерфейса — используйте их на 100%. Нет прототипов — нарисуйте схему сами.
Описывайте прецеденты строго с точки зрения пользователя (в действительности, актёра, т.к. пользователями тут могут быть и не люди вовсе).
В описании прецедентов не игнорируйте реакцию системы. Пользователи зачем-то обратились к системе — скорее всего для того, чтобы что-то получить. Это «что-то» и есть реакция системы, в том числе ошибки.
Повторюсь, не игнорируйте альтернативные последовательности сценариев.
И ещё раз повторюсь, один раз решите что использовать в UML — включение или расширение, и дальше придерживайтесь этого подхода. Не переходите между одним и другим. Потеряете время без пользы проекту.

Опубликовано 26.12.202426.12.2024 от dmitryshm

Когда нужна нейронка

В этой статье предложу метод фильтрации полезной информации про ныне модные темы искусственного интеллекта и нейронных сетей. Аудиторией статьи считаю людей с образованием, достаточным для понимания пары формул. Должен признать, что без такового люди очень внушаемы, и никакие слова их не уберегут от недобросовестных предложений на «рынке ИИ». Постараюсь быть кратким. Начало — страшное душнилово, но необходимое для слитного повествования. Если хотите, читайте с фразы «но если есть классические численные методы, то зачем все эти нейронки».

Давайте мысленно представим себя на месте проектировщика, когда на основе дискретного набора данных вам надо вывести решение, либо представить набор таких решений (класс решений с регуляризацией), если задача некорректная. В случае некорректной задачи далее выбирают из класса решений наиболее подходящее по какой-либо метрике.

Простой пример. Пусть надо создать софт, который по входному набору картинок сгенерирует видеоролик с сюжетами из них. Массив файлов изображений будет входным набором данных. Т.к. для данного набора картинок существует бесконечное множество роликов, подходящих под сюжеты в них, то автор такого софта некоторые параметры, влияющие на решение, выведет в настройки, с которыми даст играться пользователям (а что-то намеренно не выведет). Эти настройки и будут задавать регуляризацию этой некорректной задачи, чтобы получить единственное решение.

Для того, чтобы не душить и не копипастить тематику — ускорюсь. Подобные задачи, как в примере выше, сводятся к задачам на применение численных методов вычисления приближений к функциям и их классам. Тогда входные данные из примера трактуются как измерения значений исследуемой функции, которую надо приближенно вычислить. Приведу сразу ссылку для ознакомления. Важную роль тут играют несколько моментов. Первое — достаточно ли данных, чтобы точно приблизить своё решение, и если недостаточно, то до каких пор и каким образом добывать новые данные, чтобы всё-таки получить решение.

Для читателя, который не погружался в тематику нейронных сетей, полезно ознакомиться с их обзором. Не фундаментальный труд, но для первого раза достаточно.

Таким образом применение нейронных сетей также входит в вышеобозначенную постановку. Это тоже численный метод. Нейронку надо обучить, чтобы с помощью неё получить решение или некоторый их класс. Точное. Решение. Т.е. численный метод на основе нейронной сети должен сходиться. Увеличение количества данных, скармливаемое сети, должно приводить к уточнению решения, не уводя в сторону. Иначе это не работа профессионала, а гадание на кофейной гуще без гарантии на получение результата. Все речевые и языковые модели Open AI ChatGPT и аналоги в заметной своей части (да, это не целиком нейронные сети) это обученные заранее нейронные сети, которые на прямом прогоне выдают решения или их классы с возможностью выбрать для себя во фронтенде.

В вышеобозначенной постановке для получения точного решения для массива данных с элементами размерности N согласно теореме Колмогорова-Арнольда необходима лишь полносвязная двухслойная нейронная сеть с 2N+1 нейронами на каждом слое. Теорема Цыбенко даже уменьшает оценку. Только процесс обучения таких сетей будет неоптимально долгим. Для получения обученной нейронки, являющейся по сути решением некоего нужного класса задач, надо уметь её обучать. Т.е. покрыть множество предполагаемых решений примерами, и настроить свободные параметры сети. Но не перенастроить, чтобы не переучить (чтобы для некорректных задач получать не слишком узкие и тем самым неточные классы решений). При этом набор данных надо правильно делить на тот, которым обучаем и тот, на котором проверяем обученность. Это вообще большая область, иногда называется «глубокое обучение».

Но если есть классические численные методы, то зачем все эти нейронки. Обучать ещё их зачем-то. Для сложных задач объём необходимых данных для получения решения может оказаться неподъёмным. Количество степеней свободы у сложных задач велико, и для получения решения непонятно, где ещё подмерить, какие данные ещё получить, чтобы заметно улучшить решение по ходу его получения. Это ключевое. Здесь и нужны нейронки, которые обучены получать класс решений, и дальше по входным данным они ещё немного могут доуточниться, чтобы сойтись к решению по выбору пользователя. Именно поэтому им надо быть обученными это раз, но не переобученными это два.

Поэтому в задачах, где вы можете всегда получить достаточный массив данных измерений (примеров, если угодно) и заранее знать, что точное решение получается понятным образом увеличивая этот объём данных (например делая его более плотным), то в этом случае никакие нейронки не нужны. Точка.

Теперь про ИИ. Нейронки сами по себе никаким ИИ не являются. Это просто градиентные численные методы. Не надо покупаться на болтовню, что если у нас решение постепенно приближается к искомому, то это вследствие некоего интеллекта. Нет, не следствие. Так любой градиентный метод работает. И нейронки это тоже они (тут чтобы быстро найти примеры надо чуть уметь искать, поэтому раз и два, для начала). Поэтому не давайте запудрить себе мозги тем, как нейронки к чему-то там подстраиваются. И не захватят они мир. Как не захватит мир растянутая резинка, стремящаяся вернуться в исходное положение.

Ещё про ИИ. В конструктивном плане (а не в философском для поговорить) ИИ это рациональный агент, см. обстоятельное введение Норвига и Рассела, ну или хотя бы это. ИИ существует. Например современные боевые роботы в известной своей части это ИИ. Хорошие роботы пылесосы тоже. Будущие автономные такси тоже. Но всегда эти рациональные агенты снабжены моделью, за пределами которой действия бессмысленны, и поэтому с энергетической точки зрения ничем не обусловлены. Подробный экскурс в ИИ как рациональный агент м.б. предметом следующей статьи. Поэтому закругляюсь и подхожу к выводу.

Читая очередной опус про чудеса ИИ пожалуйста проверяйте себя на необходимые и достаточные причины применимости ИИ или нейронки (ещё раз — нейронка это НЕ ИИ) в решении задачи. Не позволяйте очередным имитаторам запудрить себе мозги своей гуманитарной постановкой проблемы. Старайтесь дойти до формального описания задачи, чтобы уже после этого выбрать наиболее подходящий метод её решения.

Опубликовано 25.12.202406.02.2025 от dmitryshm

Проектирование. RUP/ICONIX. Первый этап

Содержание других частей.

Первая статья из цикла про этапы разработки программного обеспечения, про его проектирование. Здесь и далее все этапы ICONIX про выстраивание полезного прироста (дельты) к программному обеспечению или системе. Напомню также согласно анонсу, что в качестве CASE-инструмента используется Sparx EA, хотя похожие работы могут выполняться и на других CASE-инструментах.

Первым этапом ICONIX при работе над нашей дельтой полезных изменений является моделирование предметной области. В руках есть CASE-инструмент и с самого начала всё, что мы можем сделать (если раньше этого не делали) — создать модель. В целом существует множество доменов моделирования. В используемом нами Sparx EA для первого этапа есть модель предметной области.

ICONIX, как упрощение RUP, на первом этапе предлагает сразу заняться моделированием предметной области. И в случае простых и средних по сложности программ и систем это смесь потоков работ бизнес-моделирования и моделирования требований. Моделирование предметной области является строго говоря этапом анализа требований, но если в проекте не было никакой бизнес-модели или как часто это бывает вообще никаких моделей, то придётся как раз при анализе требований в моделировании предметной области учитывать как бизнес так и требования технического характера.

В Sparx EA создайте пока пустую модель предментной области. Если работа происходит над существующим программным обеспечением или системой, и проект предполагает выстроить прирост относительно существующего, то сразу на первом этапе надо создавать не одну, в две модели. Первая модель — это модель предметной области того, как есть (As Is), а вторая модель предметной области того, как заказчик мыслит себе то, что должно получиться в ходе проделанной работы (To Be). И сначала валидируется с заказчиком As Is, а потом уже To Be, подсвечивая разницу между ними. Идеальной разницей будет добавление новых классов, а не изменение старых (принцип открытия-закрытия, среди прочих).

Модель предметной области это статическая модель UML. Её особенностью является то, что это часть анализа требований, когда особое внимание в словах заказчика отдаётся существительным и их отношениям между собой. Эти существительные как правила являются объектами реального мира, про которые говорит заказчик. Все эти объекты являются хорошими кандидатами на абстракции в модели предметной области, существование которых подкрепляется существованием реальных объектов. А в модели предметной области, как в способе упрощённо смотреть на мир, выделяя главное из него, существенное для модели, вы как раз концентрируетесь на этих абстракциях.

Каждая абстракция, создаваемая в модели предметной области ICONIX, является экземпляром класса UML, но т.к. созданная модель — это именно модель предметной области, то главными типами отношений между создаваемыми классами должны быть обобщение (generalization) и агрегирование (отношение целое-часть, аggregation).

Те из вас, кто уже всерьёз моделировал в UML могут задаться вопросом, не стоит ли модель предметной области связывать с прецедентами (Use Case — обсуждаются в стадующей статье). Сразу отвечу, что нет. В ICONIX намеренно начинают с модели предметной области с тем, чтобы при моделировании прецедентов рассматривать их уже в контексте объектной модели предметной области, связывая далее статические и динамические части.

Модель предметной области должна стать словарём терминов, глоссарием проекта. Для записи модели предметной области ICONIX используются диаграммы классов. Классы используются как возможность обозначать абстракции и устанавливать между ними связи. На данном этапе всё, и действительно всё. Этапы в ICONIX нельзя переусложнять, хотя некоторые из нас уже знают, что классы в UML это ещё и место для атрибутов (полей) и операций (методов). В модели предметной области же ни атрибутов, ни операций указывать нельзя.

Что всё же можно учесть в модели предметной области, так это возможное повторное использование. Классы в модели должны ясно описывать абстракции реального мира. Рекомендуется следовать методикам OMT (object modelling technique — техника объектного моделирования), когда начинают с ключевых объектов, а потом рассматривают, с какими ещё объектами они взаимодействуют. Источниками для модели предметной области являются различные высокоуровневые описания задачи от заказчика или записанное со слов заказчика. Кстати, такие записи можно делать в модели требований Sparx EA, например, сразу структурируя их. Существительные имеют большие шансы стать классами, а глаголы связями между ними.

В итоге модель предметной области адекватно опишет аспекты задачи, не зависящие от времени, но без лишних деталей на этом этапе работ: без атрибутов у связей между классами (например не надо писать кратности у ассоциаций между ними), без операций и полей классов, без споров чем является отношение целое-частное (агрегацией или композицией), без обсуждений деталей реализации модели, без имён классов от программистов согласно их фреймворкам, без применения шаблонов проектирования.

Опубликовано 22.12.202406.02.2025 от dmitryshm

Проектирование. Анонс цикла статей.

Содержание других частей.

Анонсирую цикл статей про этапы разработки программного обеспечения, в особенности про его проектирование. Не буду особо останавливаться на важных стандатрах, например таких, как их комплекс ГОСТ 34 серии и прочих. Знание стандартов либо уже осознанно специалистом, либо ещё предстоит. Целью данной статьи является краткое описание RUP/ICONIX, активно применяемое у нас.

RUP/ICONIX используется как методология проектирования для небольших и средних проектов, сложность которых косвенно оценивается до 1 млн. строк кода и меньше. Для более сложных проектов рекомендуется RUP без упрощений. Модели строятся в Sparx EA, что позволяет генерировать документы, связанные с изменениями в проекте, выполнять обратный инжиниринг и многое из того, что упрощает работу по приведению документации, моделей и кода в соответствие друг другу. Читатель без труда выберет для себя удобный CASE-инструмент, кроме Sparx EA, т.к. описываемое здесь выполнимо и с другими инструментами.

Повествование в целом согласуется с методичкой «Применение объектного моделирования с использованием UML и анализ прецедентов на примере разработки книжного Internet-магазина» Кендалла Скотта и Дуга Розенберга. Хотя обстоятельное освоение UML как такового рекомендуется начать с «UML 2.0. Объектно-ориентированное моделирование и разработка» Джеймса Рамбо и М. Блаха.

В цикле статей в основном затрагивается структура работ для таких ролей, как бизнес аналитик, системный аналитик и системный архитектор. И если в полноценном RUP легче провести грань между этими ролями как по отдельным работам, так и по артефактам, производимыми ими, то в ICONIX, как в упрощённом RUP, роли бизнес аналитика и системного аналитика смешиваются, а часть артефактов общая с системным архитектором.

Также обращу внимание, что в анонсируемом цикле статей в явном виде используется объектно-ориентированное проектирование. Т.е. упор делается на формировании объектов, их классов, и сообщения между ними, а не фукнций, как последовательности действий, переводящих систему из одного состояния в другое. Одно с другим связано, хотя подход с фукнциями мыслится уже как давно архаичный из 70-ых годов.

Статьи будут полезными как для начинающих аналитиков, так и для тех, кто хочет укрепиться во владении своей профессией. Конечно же статьи также полезны и ИТ-архитекторам разных уровней. Любителям масала-диаграмм и проектирования на коленке в особенности рекомендуется прочесть анонсируемый материал, как возможность освоить профессию, пройдя от стадии отрицания до стадии принятия методологии и связанного с ней инструментария. Многим аналитикам на рынке труда, чья роль сводится сейчас к передаче слов заказчика с оформлением в Word и прикладыванием пары Visio-картинок на UML также очень рекомендуется к прочтению, т.к. у них появляется шанс всё-таки начать осваивать свою профессию.

Опубликовано 16.12.202417.12.2024 от dmitryshm

Дистрибутивы

С обилием отечественных операционных систем приходит обилие штатных репозиториев и нежелание переусложнять свои системы на ровном месте просто из-за того, что кто-то захотел поставить эту операционную систему, а не ту, которая поддерживается инженерами предприятия. Скажем, принято в компании пользоваться Astra Linux или Alt Linux, и значит желательно пользоваться дистрибутивами программного обеспечения именно под эту операционную систему. И далеко не всегда свободно распространяемый пакет (deb или rpm) сразу подходит. Это и разные системные окружения (например, версии базовых библиотек другие) и разные механизмы работы с пакетами (rpm для Alt Linux отличается от rpm для Red Hat).

В связи с этим появляются запросы по перепаковке какого-то существующего программного обеспечения. Становится актуальной отдельная услуга по созданию дистрибутивов под заказчика.