Непрограммные сущности

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

Моделирование непрограммных сущностей производится следующим образом:

1. Смоделируйте сущности, абстрагируемые в виде классов.

2. Если вы хотите отличить эти сущности от предопределенных строительных блоков UML, создайте с помощью стереотипов (см. главу 6) новый строи­тельный блок, опишите его семантику и сопоставьте с ним ясный визуаль­ный образ.

3. Если моделируемый элемент является аппаратным средством с собствен­ным программным обеспечением, рассмотрите возможность смоделиро­вать его в виде узла (см. главу 26), которая позволила бы в дальнейшем рас­ширить его структуру.

Применение UML предназначен в первую очередь для моделирования программ -ных систем, однако в сочетании с текстовым языком моделирова­ния аппаратных средств, таким как VHDL, его вполне допустимо использовать и для моделирования аппаратных систем

.

Как видно из рис. 4.11, абстрагирование людей (AccountsReceivableAgent -АгентПоДебиторскойЗадолженности) и аппаратуры (Robot) в виде классов вполне естественно, поскольку они представляют собой множества объектов с общей струк­турой и поведением. Сущности, внешние по отношению к системе, часто модели­руются как актеры (см. главу 16).

Примитивные типы

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

Моделирование примитивных типов производится следующим образом:

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

2. Если требуется задать связанный с типом диапазон значений, воспользуй­тесь ограничениями (см. главу 6).

Рис. 4.12 показывает, что такие сущности можно моделировать в UML как типы (см. главу 11) или перечисления, которые изображаются точно так же, как классы, но с явно указанным стереотипом. Сущности, подобные целым числам (представленные классом Int), моделируются как типы, а с помощью ограниче­ний вы можете явно указать диапазон принимаемых значений. Перечислимые типы (скажем, Boolean и Status) допустимо моделировать как перечисления, причем их конкретные значения становятся атрибутами.

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

Советы

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

• является четко очерченной абстракцией некоторого понятия из словаря про­блемной области или области решения;

• содержит небольшой, точно определенный набор обязанностей и выполняет каждую из них;

• поддерживает четкое разделение спецификаций абстракции и ее реализации;

• понятен и прост, но в то же время допускает расширение и адаптацию к но­вым задачам.

Изображая класс в UML, придерживайтесь следующих правил:

• показывайте только те его свойства, которые важны для понимания абстрак­ции в данном контексте;

• разделяйте длинные списки атрибутов и операций на группы в соответствии с их категориями;

• показывайте взаимосвязанные классы на одной и той же диаграмме.