книги / Проектирование автоматизированных информационных систем на основе объектно-ориентированного подхода

6.0Дополнительные Нет. замечания

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

дисциплине» включают прецедент «Регистрация преподавателя

в системе». Поэтому, разместив все три прецедента на дополнитель­ ной диаграмме, мы должны установить между ними включающее от­ ношение. Для этого необходимо на панели инструментов щелкнуть на пиктограмму «Dependency or instantiates», провести связи анало­ гично тому, как это было сделано на основной диаграмме, и опреде­ лить стереотип «include».

Окончательный вид дополнительной диаграммы представлен на рис. 4.16.

4.3. Подведение итогов

Построение диаграммы прецедентов является самым первым этапом процесса проектирования информационной системы, цель ко­ торого - представить совокупность требований к поведению проек­ тируемой системы. Спецификация требований к проектируемой сис­ теме в форме диаграммы прецедентов представляет собой самостоя­ тельную модель, которая в языке UML получила название модели прецедентов (вариантов использования) и имеет свое специальное стандартное имя или стереотип «UseCaseModel».

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

Перед именем атрибута может быть указан квантор видимости. Квантор видимости принимает одно из трех возможных значений и, со­ ответственно, отображается при помощи специальных символов [2]:

-символ «+» обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости досту­ пен или виден из любого другого класса пакета, в котором определе­ на диаграмма;

-символ «#» обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недос­ тупен или не виден для всех классов, за исключением подклассов данного класса;

-и, наконец, знак «-» обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недос­ тупен или не виден для всех классов без исключения.

Квантор видимости может быть опущен. В этом случае его отсут­ ствие просто означает, что видимость атрибута не указывается. До­ пускается вместо графических символов указывать стереотип: «public», «protected», «private».

Операцией (operation) называется реализация услуги, которую можно запросить у любого объекта класса для воздействия на пове­ дение. Иными словами, операция - это абстракция того, что позволе­ но делать с объектом [1]. У всех объектов класса имеется общий на­ бор операций. Класс может содержать любое число операций или не содержать их вовсе. Операции указываются после перечисления атрибутов (рис. 5.3).

Датчик

Тип

Марка

Расположение Мин. уровень Макс, уровень Ед. измерения

Сбросить

Операции

Опросить

Рис. 5.3. Операции класса

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