Описание объектов автоматизации
Объект автоматизации необходимо описывать с целью структурирования полученных данных об этом объекте и изложении их в письменном и/или модельном виде. Представленная таким образом информация об объекте является незаменимым помощником при выполнении последующих работ в процессе разработки ПО, таких как проектирование подсистем и модулей, проектирование базы данных, разработка пользовательского интерфейса, формулирования функций и требований к ПО. Кроме того, описание объекта автоматизации требует ГОСТ при разработке ТЗ.
Как правило, для объекта строится его модель (например, по методологии ARIS), делаются пояснения к модели и описываются нюансы, которые сложно или невозможно изобразить на модели.
Задания
1) Установить и настроить среду моделирования ARISToolset.
2) Разработать организационную диаграмму.
3) Разработать диаграмму добавленного качества (VAD).
4) Разработать для каждого процесса VAD диаграмму eEPC.
Контрольные вопросы
1) Что такое модель?
2) Методология ARIS.
3) Организация хранения данных о модели в ARISToolset.
4) Как взаимосвязаны разные диаграммы в рамках одной модели?
5) Какие вы знаете связи между элементами в организационной диаграмме?
6) Какие процессы отражены на диаграмме VAD?
7) Как реализован механизм декомпозиции в ARIS?
8) Из каких блоков строиться диаграмма eEPC?
9) Что такое событие в eEPC?
10) Каким образом может использоваться модель ARIS для описания объекта автоматизации?
Разработка модели вариантов использования и их спецификаций
Цель работы:
– научиться разрабатывать модели вариантов использования;
– научиться организовывать модель вариантов использования;
– научиться разрабатывать спецификации вариантов использования.
Введение
Цель данного этапа заключается в разработке требований к программному обеспечению. В России стандартом оформления требований является ГОСТ 34.602-89, который регламентирует содержание технического задания (ТЗ) на разработку автоматизированных информационных систем.
Существуют и другие широко применяемые в мире стандарты, например, IEEE (Institute of Electrical and Electronics Engineers) 830: Standard for Software Requirements Specification (1994).
Процесс разработки требований к ПО (или спецификаций требований) условно можно разделить на три этапа, которые позволяют описать требования на трёх уровнях (рисунок 4.1). Каждый уровень позволяет описать требования на столько детально, насколько этого требует уровень абстракции.
Выявление и формулирование требований первого уровня «Потребности» было осуществлено на предыдущем этапе – этапе системного анализа. На этом этапе нужно описать требования для второго и третьего уровней.
Рисунок 4.1 – Характеристика уровней описания требований
Разработка модели вариантов использования
Модель вариантов использования
Для определения (выявления) функций к разрабатываемой системе необходимо провести анализ требований. На данном этапе для такого анализа имеется уже достаточно много материала, который был собран на предыдущем этапе. Таким образом, исходными данными для анализа требований являются: потребности заинтересованных лиц, данные интервьюирования, описание объектов автоматизации, цели и задачи разработки системы.
Процесс формулирования функций к системе можно частично отнести к процессу проектирования, поскольку он определяет функциональность будущей системы, что в свою очередь уже на этапе анализа требований заставляет задумываться об архитектуре системы и об элементах пользовательского интерфейса. И этот подход верен, он позволяет безболезненно перейти от этапа к этапу и поддерживает итеративную модель разработки программных систем.
При определении функций можно использовать элементы системного анализа. Но существуют более адаптированные методы к процессам разработки ПО. В данном практикуме рекомендуется использовать метод вариантов использования для идентификации и представления функций системы.
Метод вариантов использования (прецедентов) является частью методологии объектно-ориентированного проектирования. Это метод анализа и проектирования сложных систем, представляющий собой способ описания поведения системы с точки зрения того, как различные пользователи взаимодействуют с ней для достижения своих целей. Такой ориентированный на пользователя подход предоставляет возможность исследовать различные варианты поведения системы при раннем привлечении пользователя.
Варианты использования можно успешно использовать на протяжении всего жизненного цикла программного обеспечения. Варианты использования можно применять при анализе, проектировании и в процессе тестирования. В этом случае, процесс разработки программного обеспечения называют – основанный на вариантах использования.
Вариант использования – это функциональный связный блок, выраженный в виде транзакции между актантом и системой (Рисунок 4.2). Вариант использования описывает последовательность действий, выполняемых системой с целью получения полезного результата пользователем системы. Актантом называют пользователя системы (человек, другая система).
Между вариантами использования и актантами существует связь, которая показывает, какие функции системы доступны каждому пользователю. Кроме того, в модели вариантов использования есть связи между самими варрантами использования. В соответствии со стандартом языка UML таких связей достаточно много. В данном практикуме будут рассмотрены наиболее часто употребляемые связи при построении модели. Это расширение (обобщение) и использование (рисунок 4.2).
Рисунок 4.2 – Обозначения в модели вариантов использования
Расширение используется в том случае, если у ряда вариантов использования есть общая часть, которую можно выделить в отдельный вариант использования. Этот тип связи аналогичен наследованию в классах. Пример такого типа связи приведен на рисунке 4.3.
Рисунок 4.3 – Пример связи обобщения
Использование применяется в случае, если несколько вариантов использования в основном или альтернативных потоках имеют одинаковое поведение. В отличие от обобщения, использование не подразумевает обязательное наличие общего поведения.
Построение модели вариантов использования
Модель вариантов использованиясистемы состоит из всех актантов системы и различных вариантов использования, посредством которых актанты взаимодействуют с системой, тем самым, описывая многообразие ее функционального поведения. Она также показывает связи между вариантами использования, что углубляет наше понимание системы.
Первый шаг моделирования вариантов использования состоит в создании списка актантов системы. Второй шаг описывает системное поведение, т.е. то, как пользователи взаимодействуют с системой, осуществляя некоторые последовательности действий, для достижения определенных целей. Если модель вариантов использования получается слишком громоздкой и нечитабельной, то это модель необходимо декомпозировать, т.е. разбить на подсистемы. Декомпозиция модели проводится и в том случае, если это очевидно и напрашивается само собой.
Пример модели вариантов использования приведён на рисунках 4.4–4.8.
Рисунок 4.4 – Подсистемы в модели вариантов использования
Рисунок 4.5 – Диаграмма вариантов использования «Ведение журнала преподавателя»
Рисунок 4.6 – Диаграмма вариантов использования «Контроль успеваемости»
Рисунок 4.7 – Диаграмма вариантов использования «Перевод, отчисление, ликвидация задолженностей»
Рисунок 4.8 – Диаграмма вариантов использования «Рейтинги студентов»
Следующий шаг состоит в уточнении деталей функционального поведения каждого варианта использования, в разработке спецификаций. Спецификации вариантов использования состоят из текстовых и/или графических описаний каждого варианта использования, написанных с позиции пользователя.
Спецификация вариантов использования
Как было отмечено выше, спецификация служит для описания последовательности действий пользователя и системы в рамках одного варианта использования. Цель разработки спецификаций заключается в разработке требований к программному обеспечению, которые позволят заказчику и разработчику системы однозначно и недвусмысленно понимать требования. Спецификации вариантов использования позволяют проектировщикам и программистам без дополнительных уточнений и домыслов разрабатывать систему.
Спецификации вариантов использования можно оформлять, придерживаясь разных стандартов, начиная международными, заканчивая корпоративными. Ниже предлагается образец для написания спецификаций.
[Название варианта использования]
[Краткое описание]
Роль и цель варианта использования (Для описания достаточно одного абзаца).
Основной поток
Вариант использования начинается, когда актант производит некое действие. Вариант использования всегда инициируется неким актантом. Вариант использования должен описывать, что делает актант и что система делает в ответ; он должен выглядеть как диалог между актантом и системой.
Вариант использования должен описывать, что происходит внутри системы, а не как или почему это происходит. Если происходит обмен информацией, то нужно указать, какая информация поступает, а какая – отправляется. Кроме того, не очень понятно, что имеется в виду, если сказать, что актант вводит информацию о клиенте; лучше сказать, что актант вводит имя и адрес клиента. Для того чтобы не делать вариант использования очень сложным и не запутаться в деталях, полезно использовать глоссарий, где можно определить, что понимается под информацией о клиенте.
Простые альтернативы можно описать в тексте варианта использования. Если для описания того, что происходит в альтернативном случае, достаточно нескольких предложений, следует сделать это непосредственно в разделе, посвященном основному потоку событий. Если альтернативные потоки более сложные, нужно использовать отдельный раздел (Альтернативные потоки).
Иногда рисунок информативнее тысячи слов, хотя ничто не заменит чистой и ясной прозы. Если это поможет добиться большей ясности, можно включать в вариант использования графические описания интерфейсов пользователя, потоков процессов или другие рисунки. Если для представления сложного процесса принятия решения необходимо использовать формальные средства спецификации, такие как диаграммы деятельности, несомненно, это следует делать! Аналогично, если поведение системы зависит от состояния, то диаграмма перехода состояний лучше прояснит его, чем это сделают страницы текста. Используйте представление, которое лучше всего подходит для вашей проблемы, но будьте осторожны с терминологией, обозначениями или рисунками, которые могут быть непонятны вашей аудитории. Помните, что ваша задача – прояснить, а не запутать.
Альтернативные потоки
Первый альтернативный поток. Более сложные альтернативы следует описывать в отдельном разделе. Следует воспринимать альтернативные потоки как варианты альтернативного поведения; каждый альтернативный поток представляет некое альтернативное поведение (вариантов много из-за исключительных ситуаций, возникающих в основном потоке). Они могут быть произвольной длины, которая требуется для описания связанных с альтернативным поведением событий. Когда альтернативный поток заканчивается, события основного потока продолжаются, если не оговорено противное.
Альтернативные потоки могут, в свою очередь, также состоять из подразделов.
Второй альтернативный поток. Достаточно часто в варианте использования встречается несколько альтернативных потоков. Для большей ясности следует описывать каждую альтернативу отдельно. Использование альтернативных потоков упрощает понимание варианта использования, а также предотвращает декомпозицию вариантов использования на иерархии вариантов использования. Следует помнить, что варианты использования – это только текстовые описания, и их главная задача в том, чтобы документировать поведение системы ясно, сжато и понятно.
Специальные требования
Здесь обычно приводятся имеющие отношение к данному варианту использования нефункциональные требования, которые непросто описать в тексте потока событий варианта использования. Примерами таких требований могут служить требования законодательства и инструкций, применяемые стандарты, атрибуты качества создаваемой системы, в том числе требования практичности, надежности, производительности или возможности сопровождения. В данном разделе следует также фиксировать другие требования, такие как описание операционных систем и сред, требования совместимости и ограничения проектирования.