-
Министерство образования и науки, молодежи и спорта Украины
ДВНЗ «Донецкий национальный технический университет»
Кафедра систем искусственного интеллекта
МЕТОДИЧЕСКИЕ УКАЗАНИЯ
К УЧЕБНОЙ ПРАКТИКЕ ДЛЯ СТУДЕНТОВ 2-ГО КУРСА СПЕЦИАЛЬНОСТИ «СИСТЕМЫ ИСКУССТВЕННОГО ИНТЕЛЛЕКТА»
Донецк 2013
СОДЕРЖАНИЕ
Введение
Цели и задачи практики
Примеры создания диаграмм
Требования к оформлению отчета по практике
Порядок защиты отчета по практике
Темы выполнения заданий
ВВЕДЕНИЕ
Моделирование предметной области является одним из наиболее важных этапов работ при проектировании программных систем масштаба предприятия. В настоящее время для целей моделирования предметной области на рынке программных продуктов представлен широкий спектр CASE-средств. Наиболее популярными в нашей стране CASE- средствами являются Rational Rose, BPwin, Silverrun, Process Analyst.
Моделирование предметной области в этих средствах имеет скорее много общего, чем различий. Основными задачами при моделировании предметной области являются следующие описания:
– бизнес-процессов предприятия;
– действующих лиц бизнес-процессов и их функций, подлежащих автоматизации в привязке к структуре автоматизируемого предприятия;
– бизнес-сущностей;
– сценариев выполнения бизнес-функций, подлежащих автоматизации;
– состояний бизнес-сущностей;
– бизнес-правил.
Описания бизнес-процессов используются для описания технологии выполнения производственной задачи, подлежащей автоматизации. На основе описанной технологии определяются виды деятельности, которые следует автоматизировать (бизнес-требования к будущей программной системе). При описании бизнес-процессов должны быть выявлены связи между различными подразделениями предприятия при решении конкретных производственных задач (горизонтальные связи).
При описании предметной области не следует забывать о моделировании бизнес-правил. Модели бизнес-правил предметной области будут являться основой для моделирования правил программной системы.
1. Цели и задачи практики
Цель практики.
Приобретение студентами теоретических, методологических и практических навыков использования современных компьютерных информационных технологий при моделировании систем.
Цель работы.
Разработка модели процесса (бизнес, производственного, проектирования, информационного, образовательного) с помощью языка моделирования UML и ознакомления с программными пакетами визуализации UML моделей.
Задачи практики:
изучить заданную предметную область;
создать диаграммы вариантов использования (не менее 3);
создать диаграммы взаимодействия;
создать диаграммы классов;
создать диаграммы состояний для каждого класса системы;
создать диаграммы активности, отображающие алгоритм работы проектируемой системы.
создать диаграммы компонентов системы;
создать диаграммы размещения;
изучить стандарт Украины ДСТУ 3008-95 «Документация. Отчеты в сфере науки и техники. Структура и правила оформления» и оформить пояснительную записку к курсовому проекту в соответствии с ним.
2 Примеры создания диаграмм
2.1 Диаграммы вариантов использования
Моделирование в Ration Rose проводится как спуск от концептуальной модели к логической, а затем к физической модели программной системы. Концептуальная модель выражается в виде диаграмм вариантов использования (Use – case diagram). Этот тип диаграмм служит для проведения итерационного цикла общей постановки задачи вместе с заказчиком.
Вариант использования представляет собой последовательность действий, выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел реализовать. Эти диаграммы служат основой для достижения взаимопонимания между программистами-профессионалами, разрабатывающими проект, и заказчиками проекта. Внутри каждого варианта использования (прецедента) могут быть определены:
– вложенная диаграмма использования,
– диаграмма взаимодействия объектов,
– диаграмма последовательности взаимодействия,
– диаграмма классов,
– диаграмма перехода состояния.
Действующее лицо (Actor) – это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Действующее лицо может быть внешней системой, которой необходима информация от данной системы. На рисунке приводится вариант использования, описывающий одну из функций системы управления проектами – обратную связь между менеджером проекта и исполнителем.
Нотации представления использования (диаграмма прецедентов) Каждое представление строится из диаграмм, которые используют свои нотации (обозначения). Для представления использования применяются следующие нотации:
Примеры обобщения показаны на рис. 1. Это сильный инструмент построения диаграмм. Так, один клиент, другой клиент обслуживающей фирмы обобщаются в клиента фирмы.
Пример. Менеджер модифицирует план, назначает ресурс и получает отчеты от исполнителей, сотрудников и субподрядчиков проекта. Информационную систему назовем "Управление проектами". На рис. 2 показаны функции менеджера относительно выполнения проекта.
2.2 Диаграммы взаимодействия
Диаграммы взаимодействия являются моделями, описывающими поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой в рамках одного варианта использования.
Пример. Управление проектами (рис. 5)
– Менеджер обдумывает поручение отчета исполнителю;
– дает указания на создание Отчета Исполнителю;
– если Отчет неудовлетворительный, Менеджер посылает
– запрос Исполнителю на обновление Отчета;
– Исполнитель создает новый Отчет;
– Менеджер делает повторный запрос Отчета.
Существует два вида диаграмм взаимодействия: диаграммы после- довательности (sequence diagrams) и кооперативные, или сотрудничества (collaboration diagrams).
Диаграммы последовательности определяют временную последовательность передаваемых сообщений, порядок, вид и тип сообщения, происходящих в рамках варианта использования. Диаграммы последовательности и кооперативные являются разными взглядами на одни и те же процессы, поэтому Rational Rose позволяет создать из диаграммы последовательности диаграмму Кооперации и наоборот, а также производит автоматическую синхронизацию этих диаграмм.
На диаграмме последовательности взаимодействие изображается в виде двумерной схемы: вертикальное (время) и горизонтальное (объекты, участвующие во взаимодействии). Существенна только последовательность сообщений, однако временная ось может служить реальной метрикой измерения активности объекта.
– Действующие лица из варианта использования.
– Объекты, требуемые системе для выполнения варианта использования.
– Линии жизни, представляющие фрагмент жизненного цикла объекта в процессе взаимодействия, где течение времени идет сверху вниз, идут сверху.
– Активный период линии жизни.
– Сообщение, передающееся от одного объекта к другому в порядке следования жизненного цикла, при желании может быть помечено именем и аргументом, управляющим событием, например, сообщение посылается, если Отчет не устарел.
– Самоделегирование (рекурсивное сообщение) – сообщение самому себе.
На кооперативной диаграмме экземпляры объектов показаны в виде пиктограмм. Линии между ними обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Каждый вид диаграмм имеет свои преимущества. На диаграмме последовательности легче наблюдать порядок, в котором происходят события. В случае кооперативных диаграмм можно использовать пространственное расположение объектов, чтобы показать их статическое взаимодействие.
Нотации диаграммы последовательности
Изображение диаграммы в виде двумерной схемы
Пример. Последовательность действий и кооперация между объектами при создании отчета "Управление проектами".
2.3 Диаграммы классов
Диаграммы классов являются центральным звеном методологии объектно-ориентированного анализа и проектирования. Диаграмма класса показывает классы и их отношения, тем самым представляя логический аспект проекта. На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности объектов (сущностей), обеспечивающих требуемое поведение системы, на стадии проектирования – чтобы передать структуру классов, формирующих архитектуру системы. Каждый класс должен иметь имя. Имя каждого класса должно быть уникально в содержащем его проекте. Диаграмма классов определяет этапы объектов системы и различные статистические связи, которые существует между ними. Имеется два основных вида статистических связей:
– ассоциации (например, менеджер может вести несколько проектов);
– подтипы (работник является разновидностью личности).
На диаграммах классов также изображаются атрибуты классов, операции и ограничения, которые накладываются на связи между объектами.
Ассоциации представляют собой связи между экземплярами классов (личность работает в компании, компания имеет ряд офисов). Любая ассоциация обладает двумя ролями. Например (рис. 3) – ассоциация между Исполнителем и Отчетом содержит две роли: одна от Исполнителя к Отчету; другая – от Отчета к Исполнителю. Роль также обладает множественностью. Пример – символ "0..*" над ассоциацией между Менеджером и Контрактом показывает, что с одним Менеджером связано много Контрактов. 0 – показывает, что Менеджер может не управлять контрактом; 1 – показывает, что любой Контракт может управляться только одним Менеджером. Для ассоциации может указываться направление навигации, если направление не указывается, то ассоциация двунаправленная или ее направление неизвестно.
Атрибуты во многом подобны ассоциациям. Разница между ними заключается в том, что атрибуты предполагают единственное направление навигации – от типа к атрибуту. На рисунке указаны атрибуты для классов Контракт и Отчет. В зависимости от степени детализации диаграммы обозначение атрибута может включать имя атрибута, тип и значение, присваемое по умолчанию. В синтаксисе UML атрибут обозначен:
<признак видимости> <имя>: <тип> = <значение по умолчанию>.
Признак видимости может принимать следующие значения:
– общий (public) – атрибут общий, доступен для всех классов клиентов;
– защищенный (protected) – атрибут защищенный, доступен только для подклассов и друзей класса;
– секретный (private) – атрибут собственный, доступен только для друзей класса;
– реализация (implementation) – атрибут внедренный, доступен внутри обрамляющего пакета.
Операции представляют процессы, реализуемые классом. Существует соответствие между операциями и методами над классом. На рис. 3 приведены операции над классом Контракт Закрыть (), над классом Отчет – Добавить().
Нотации логического представления (диаграммы классов)
Пример. Диаграмма классов "Управление проектами". Статическая модель. Все данные о проекте можно свести в реляционную модель. Объекты сведены в классы, классы описываются атрибутами. Каждый класс имеет свое поведение по отношению к выполнению проекта. После создания диаграммы классов в диаграмме прецедентов к субъектам, используемым диаграммой классов, будут добавлены параметры класса.
После создания диаграммы классов в диаграмме прецедентов к субъектам, используемым диаграммой классов, будут добавлены параметры класса.
2.4 Диаграммы состояния и активности
Диаграммы состояния (Statechart) являются средством описания поведения систем. Они определяют все известные состояния, в которых может находиться объект, а также процесс смены состояния объекта в результате влияния некоторых событий. Существуют два специальных состояния – начальное (start) и конечное (stop). Начальное состояние – состояние объекта, когда он только что создан, конечное – перед его уничтожением. Начальное состояние может быть только одно, а конечных – сколько вам нужно или вообще не быть. Процесс начинается с начальной точки, а затем переходит в состояние. В поведении объекта в системе можно выделить действия, отображаемые переходами, и деятельности, отображаемые состояниями. Действия связаны с переходами и рассматриваются как мгновенные и непрерываемые.
Деятельности связаны с состояниями и могут длиться достаточно долго. Деятельность может быть прервана в результате наступления некоторого события. Событие – это то, что вызывает переход из одного состояния в другое. Переход может содержать метку. Метка перехода состоит из трех частей, каждая из которых является необязательной
( < Событие>I <Условие >I/<Действие >).
Изображается на диаграмме вдоль линии перехода после имени события. Условный переход. История состояния. Диаграммы состояний хорошо использовать для описания поведения некоторого объекта в нескольких различных вариантах использования, их не надо создавать для каждого класса.
Нотации диаграммы состояния
Пример. Получение отчета. Управление проектами.
Диаграммы активности.
Этот тип диаграмм может использоваться для моделирования различных типов действий. Например, финансовая компания может использовать данный тип диаграмм для моделирования потоков финансовых документов, прохождения оплаты счетов или заказов. Компания, создающая программные продукты, отслеживать процесс разработки и создания программного обеспечения. Диаграммы активности (Activity diagram) – это специальная разновидность диаграмм состояния. Главное отличие между диаграммами активности и состояния в том, что в первом случае основное – действие, а во втором – статичное состояние.
Нотации диаграммы последовательности Из набора значков состояний можно составить представление о всем жизненном цикле объекта, у которого есть начало и конец действия работы объекта. Нотации используются те же самые, что и при построении диаграммы состояния, с дополнениями.
Добавляются:
Пример. Алгоритм получения отчета. Управление проектами.
2.5 Диаграмма компонентов
Важной задачей систематизации информации о предметной области является разбиение большой системы на небольшие подсистемы. Именно здесь особенно заметны структурные и объектно-ориентированные различия между подходами. Одна из идей заключается в группировке классов в компоненты более высокого уровня. В UML такой механизм группировки носит название пакетов (package). Диаграммой пакетов является диаграмма, содержащая пакеты классов и зависимости между ними. Строго говоря, пакеты являются элементами диаграммы классов, т. е. диаграмма пакетов – это всего лишь диаграмма классов. Отличаются эти диаграммы практическим назначением и использованием. Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь изменения в другом.
Что касается классов, то причины зависимостей могут быть разными:
· один класс посылает сообщение другому;
· один класс включает часть данных другого класса;
· один класс ссылается на другой, как на параметр операции.
Если класс меняет свой интерфейс, то сообщение, которое он посылает, может стать неправильным.
На рис. 8 показаны классы предметной области, возникающие при моделировании деятельности менеджера по управлению проектами. Они сгруппированы в пакеты: контракты, менеджеры, отчеты, исполнители.
Приложение Проект имеет связь с пакетами предметной области Менеджеры, Отчеты, Контракты. Приложение Специалисты имеет связь с Исполнителями, через которых можно узнать, какие отчеты они подготовили.
Пакеты являются жизненно необходимыми для больших проектов. Особенно когда диаграмма классов, охватывающая всю систему, трудночитаемая. Пакеты не дают ответа на вопрос, каким образом можно уменьшить количество зависимостей в разрабатываемой системе, онипомогают выделить эти зависимости. Пакеты полезны при тестировании системы. Каждый пакет может содержать один или несколько тестируемых классов, с помощью которых проверяется поведение пакета.
Нотации диаграммы состояния
Пример. Получение отчета "Управление проектами".
