Для получения более точной диаграммы далее нужно проанализировать каждый прецедент. Для этого нужно выписать все возможные сценарии, которые могут входить, использовать, уточнять или расширять данные прецедент. Полученные сценарии для каждого прецедента нужно попытаться сгруппировать в несколько более общих прецедентов. Если полученный прецедент является важным аспектом функционирования системы, то его нужно включить на диаграмму, связав каким-либо отношением с уже существующим прецедентом. Если же наличие выписанных сценариев очевидно из основного прецедента, то их можно на диаграмме опустить.
1) Определить возможных пользователей системы.
2) Определить актеров.
3) Определить возможные действия каждого актера.
4) Определить прецеденты.
5) Определить возможные расширения прецедентов.
6) Нарисовать диаграмму прецедентов
1) Цель работы.
2) Задание по лабораторной работе.
3) Диаграмма прецедентов.
4) Описание всех этапов построения диаграммы.
5) Выводы по проделанной работе.
1) Что такое актер? Приведите примеры.
2) Что такое прецедент? Приведите примеры.
3) Каким отношениями могут быть связаны между собой актеры? прецеденты? актеры и прецеденты?
4) Чем отличаются стереотипы «extend» и «include»?
5) В каких случаях на диаграмме прецедентов может использоваться отношение обобщение?
6) Какие элементы диаграммы прецедентов отображаются в проводнике по моделям MS Visio?
7) Для каких элементов на диаграмме прецедентов можно указать стереотип?
Цель работы: изучение элементов UML, присутствующих на диаграммах классов, и их расширений, получение навыков построения диаграммах классов.
Класс представляют собой описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.
Графически класс изображается прямоугольником с несколькими полями, как показано на рис. 12. Обычно полей три. Первое поле это название класса. Второе – атрибуты (члены класса, которые в зависимости от языка программирования также могут называться полями или свойствами). В примере на рисунке класс «Класс1» имеет один атрибут «x» целого типа. Перед атрибутом можно указывать тип его видимости (другое название – модификатор доступа), в данном случае значок «-» означает, что атрибут имеет тип «protected».
Третье поле в изображении класса отведено под операции (член класса, которые также называются методами, функциями или процедурами). На рисунке это поле пока пустое, но показаны окна, добавляющие операцию в класс.
Рис. 12. Графическое представление класса UML и его свойств в MS Visio
Верхнее окно показывает свойства класс. Как видно в левом поле этого окна операции (как и атрибуты) являются свойством класса. В правом поле этого окна приведена таблица со списком операций, и кнопки для редактирования списка операций. В этой таблице указаны основные свойства операции, например, тип возврата.
Более подробно свойства операций можно установить, нажав кнопку «свойства» в верхнем окне. Появиться окно свойств операции (на рисунке – нижнее левое). В левом поле этого окна приведен список свойств. В примере выбрано свойство параметр операции (другим словами это аргумент функции класса). Основные свойства параметра приведены в таблице справа окна, и, аналогично свойствам операции, более подробно свойства параметров можно задать, нажав кнопку свойства (нижнее правое окно).
Подробное описание всех свойств классов заняло бы очень много времени, поэтому рекомендуется их изучать по мере использования, используя в качестве справочной информации книги по объектно-ориентированному программированию [1].
Совокупность всех классов в информационной системе образует так называемый словарь системы. Составление словаря – это наиболее важная и сложная часть проектирования объектно-ориентированной системы. Кроме того, эта часть проекта наиболее часто подвергается переделке. Существует много способов, методов и рекомендации по поводу того, как нужно составлять словарь системы. Мы рассмотрим лишь некоторые приемы по созданию диаграммы классов.
Наиболее известным формальным методом создания словаря системы является метод CRC-карт или таблиц (Class-responsibility-collaboration, класс-ответственность-кооперация или сущность-связь-ответсвенность). Идея заключается в том, что при проектировании словаря основное внимание должно уделяться сущности класса, т.е. его функциям и отношениям с другими классами, а не деталям реализации, таким как конкретные атрибуты и операции. Поэтому для каждого класса заводиться карточка (или строка в таблице), на которой отображаются существенные детали класса: название класса, его ответственность (за что класс отвечает) и кооперация или связь (т.е. с какими классами он связан). В некоторых случаях в карточки заноситься также подклассы, суперклассы и автор этого класса.
Общая схема разработки диаграммы при этом не изменяется. Обычно имеется общее описания системы, например, в виде диаграммы прецедентов. Необходимо составить полный список всех возможных сущностей системы вместе с их назначением. Выделяя общие свойства все сущности и их ответственности группируются в относительно небольшое число классов. Для классов создаются CRC-карточки или таблицы, в которые заносятся основные свойства классов. Полученная таблица анализируется. Классы в таблице должны покрывать все сущности и ответственности, при этом они должны быть сбалансированы, т.е. иметь примерно одинаковый объем ответственности. В случая несбалансированности нагрузки классов нужно провести перераспределения обязанностей или переформирование классов.
Дополнительные возможности по балансировке нагрузки между сущностями предоставляет механизм наследования в объектно-ориентированном программировании. Если несколько сущностей имеют общие свойства или ответственность, и, в тоже время имеют и различные свойства, не позволяющие их удобно сгруппировать в один класс, то можно выделить суперкласс, включающий все общие свойства, а различия в свойствах сущностей реализовать в классах-наследниках. В этом случае в CRC-таблице имеет смысл завести колонки подклассов и суперклассов.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.