Проектирование. 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, например, сразу структурируя их. Существительные имеют большие шансы стать классами, а глаголы связями между ними.

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

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