1.82M

Category:

programming

Анализ требований и определение спецификаций при объектном подходе

1.

Лекция 4
АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ
СПЕЦИФИКАЦИЙ ПРИ ОБЪЕКТНОМ
ПОДХОДЕ

Модель — упрощенное представление реальности.
С точки зрения программирования модель — это
чертеж системы. Моделирование необходимо для
решения следующих зада:
- визуализации системы;
- определения ее структуры и поведения;
- получения шаблона, позволяющего затем
сконструировать систему;
- документирования принимаемых решений, используя
полученные модели.
Для решения этих задач при описании поведения
проектируемого программного обеспечения в
настоящее время используется UML (Unified Modeling
Language) — унифицированный язык моделирования.

3.

UML ОБЪЕДИНЯЕТ НЕСКОЛЬКО МОДЕЛЕЙ:
Модель использования содержит описание функций
программного обеспечения с точки зрения пользователя.
Логическая модель описывает ключевые понятия
моделируемого программного обеспечения (классы,
интерфейсы и т. п.), т. е. средства, обеспечивающие его
функциональность.
Модель реализации определяет реальную организацию
программных модулей в среде разработки.
Модель процессов отображает организацию вычислений и
позволяет оценить производительность, масштабируемость
и надежность программного обеспечения.
Модель развертывания показывает, каким образом
программные компоненты размещаются на конкретном
оборудовании.

4.

UML ПРЕДЛАГАЕТ ДОПОЛНЯЮЩИЕ ДРУГ ДРУГА ДИАГРАММЫ:
- диаграммы вариантов использования
(прецедентов);
- диаграммы классов;
- диаграммы пакетов;
- диаграммы последовательностей действий;
- диаграммы кооперации;
- диаграммы деятельностей;
- диаграммы состояний объектов;
- диаграммы компонентов;
- диаграммы размещения.

5.

CASE-СРЕДСТВО RATIONAL ROSE ФОРМИРУЕТ ДОКУМЕНТЫ:
диаграммы
классов;
диаграммы состояний;
диаграммы сценариев;
диаграммы модулей;
диаграммы процессов;
спецификации классов, объектов, атрибутов и
операций
заготовки текстов программ;
модель разрабатываемой программной
системы.

6.

ОПРЕДЕЛЕНИЕ ПРЕЦЕДЕНТОВ (ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ)
Прецеденты (варианты использования — Use
Cases) — это подробные процедурные
описания вариантов использования системы
всеми заинтересованными лицами, а также
внешними системами.
Прецеденты являются основой функциональных
требований к системе, позволяют описывать
границы проектируемой системы, ее
интерфейс, а затем выступают как основа для
тестирования системы заказчиком с помощью
приемочных тестов.
акторы (actors) — действующие лица, актёры

7.

ПРИМЕР 1
Анализ функциональных требований и
пользователей системы тестирования (модуль
обучающей системы).
Система тестирования прежде всего требуется
следующим заинтересованным лицам:
- обучаемому (студенту);
- составителю тестов (преподавателю);
- преподавателю, принимающему экзамен;
- сотруднику деканата, осуществляющему
контроль за успеваемостью;
- администратору сети и баз данных учебного
учреждения.

8.

ПРИМЕР 1
На начальном этапе создания системы можно ограничиться только
двумя важными ролями действующих лиц (акторами):
- студент (тестируемый);
- администратор (он же преподаватель, он же
составитель тестов).
Соответственно основные прецеденты (варианты использования):
Прецедент для студента:
П1 — пройти тестирование.
Прецеденты для администратора:
П2 — создать/изменить тест;
ПЗ — просмотреть результаты тестирования;
П4 — добавить/изменить пользователей и др.

9.

ПРИМЕР 1
Краткое описание варианта использования
Название варианта
Прохождение теста
Цель
Получение оценки
Действующие лица Студент
(акторы)
Краткое описание Регистрация студента, запуск
теста, выбор ответа из
нескольких предложенных или
ввод ответа, завершение теста,
получение оценки
Тип варианта
Основной

10.

ПРИМЕР 1
Подробное описание варианта использования
Действия исполнителя
Отклик системы
1. Студент вводит свои данные
(ФИО, Группа), т. е.
регистрируется в системе
2. Система создает на диске файл с
результатом тестирования и предлагает
выбрать тест
3. Студент выбирает тест
4. Система запускает тест
5. Студент последовательно
отвечает на вопросы
6. Система регистрирует правильные и
неправильные ответы
7. Студент завершает
тестирование
8. Система подсчитывает процент
правильных ответов
9. Студент ожидает результат
10. Система демонстрирует результат и
предлагает сохранить его
11. Студент решает, сохранять
результат или нет
12. Если выбрано сохранение, система
записывает результат в файл
13. Студент завершает работу
14. Система завершает работу

11.

ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
а — актор;
б — вариант использования;
в — связь.

12.

ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ТЕСТОВОЙ СИСТЕМЫ

13.

ОТНОШЕНИЯ ПРЕЦЕДЕНТОВ
Между актером и прецедентом может существовать
ассоциативное отношение. Такой тип связи часто
называют коммуникативной ассоциацией
(communicate association), потому что она отражает
связь между актером и прецедентом.
Ассоциативная связь может быть либо двухсторонней,
либо односторонней.
Существует два типа отношений между прецедентами:
включает и дополняет.
В языке UML существует понятие
стереотипа (stereotype), с помощью которого
создаются новые элементы модели путем расширения
функциональности базовых элементов.

14.

ОТНОШЕНИЯ ПРЕЦЕДЕНТОВ

15.

ПОТОК СОБЫТИЙ
Поток событий (flow of events) для прецедента
— это последовательность событий, необходимых для
обеспечения требуемого поведения.
Поток событий должен определять:
□ когда и как прецедент начинается и
заканчивается;
□ как он взаимодействует с актером;
□ какие данные ему нужны;
□ нормальную последовательность событий для
прецедента;
□ описание потоков в альтернативных и
исключительных ситуациях.

16.

ПОТОК СОБЫТИЙ
В каждом проекте должен использоваться
стандартный шаблон для создания документа,
описывающего поток событий, например:
X. Поток событий для прецедента <имя>.
Х.1. Предусловия.
Х.2. Главный поток.
Х.3. Под-потоки (если применимы).
Х.4. Альтернативные потоки.
Здесь X — число от единицы до количества
прецедентов.

17.

ПРИМЕР 2
Документ с описанием потока событий для прецедента
выбор курсов для преподавания.
1. Поток событий для прецедента «выбор курсов для
преподавания»
1.1. Предусловия
Под-поток создание учебных курсов прецедента управление
информацией о курсах должен быть выполнен перед его началом.
1.2. Главный поток
Прецедент начинает выполняться, когда преподаватель
подключается к системе регистрации и вводит свой пароль.
Система проверяет правильность пароля (Е-1) и просит
преподавателя выбрать текущий или будущий семестр (Е-2).
Преподаватель вводит нужный семестр. Система предлагает
выбрать требуемую операцию: добавить (Add), удалить (Delete),
просмотреть (Review), напечатать (Print) или выйти (Quit).

18.

ПРИМЕР 2
Если выбрана операция добавить, S-1: выполняется
поток добавить учебный курс.
Если выбрана операция удалить, S-2: выполняется поток
удалить учебный курс.
Если выбрана операция просмотреть, S-3: выполняется
поток просмотреть расписание.
Если выбрана операция напечатать, S-4: выполняется
поток напечатать расписание.
Если выбрана операция выйти: прецедент завершается.

19.

ПРИМЕР 2
1.3. Под-потоки
S-1: добавить учебный курс
Система отображает диалоговое окно, содержащее поле для
ввода названия и номера предмета. Преподаватель вводит
название и номер предмета (Е-3). Система отображает список
учебных курсов для указанного предмета (Е-4).
Преподаватель выбирает учебный курс. Система закрепляет
за преподавателем выбранный учебный курс (Е-5). Затем
прецедент начинается сначала.
S-2: удалить учебный курс
Система отображает диалоговое окно, содержащее поле для
ввода названия и номера учебного курса. Преподаватель
выбирает название и номер учебного курса (Е-6). Система
удаляет взаимосвязь курса с преподавателем (Е-7). Затем
прецедент начинается сначала.

20.

ПРИМЕР 2
S-3: просмотреть расписание
Система получает (Е-8) и отображает следующую
информацию для всех учебных курсов, за которыми
закреплен данный преподаватель: название предмета,
номер предмета, номер учебного курса, день недели,
время и место проведения занятий. Когда преподаватель
отмечает, что просматривает список, прецедент
начинается сначала.
S-4: напечатать расписание
Система распечатывает расписание преподавателя (Е-9).
Прецедент начинается сначала.

21.

ПРИМЕР 2
1.4. Альтернативные потоки
Е-1: введен неверный идентификационный номер
преподавателя. Пользователь должен повторить ввод
идентификационного номера или завершить прецедент.
Е-2: введен неверный семестр. Пользователь должен
повторить ввод семестра или завершить прецедент.
Е-3: введено неверное название или номер предмета.
Пользователь должен повторить ввод названия и номера
предмета или завершить прецедент.
Е-4: список учебных курсов не может быть отображен.
Пользователю сообщается, что данная команда в
настоящий момент недоступна. Прецедент начинается
сначала.

22.

ПРИМЕР 2
Е-5: преподаватель не может быть прикреплен к выбранному
учебному курсу. Информация сохраняется, система
осуществит прикрепление позже. Выполнение прецедента
продолжается.
Е-6: введено неверное название или номер учебного курса.
Пользователь должен повторить ввод названия и номера
учебного курса или завершить прецедент.
Е-7: система не может удалить связь курса с преподавателем.
Информация сохраняется, система удалит связь позже.
Выполнение прецедента продолжается.
Е-8: система не может получить информацию о расписании.
Прецедент начинается сначала.
Е-9: расписание не может быть распечатано. Пользователю
сообщается, что данная опция в данный момент недоступна.
Прецедент начинается сначала.

23.

ПРИМЕР 2
Главная диаграмма прецедентов для системы регистрации
учебных курсов

24.

СЦЕНАРИЙ
Сценарий (scenario) — это элемент
прецедента. Он представляет собой
одиночный проход по потоку событий
для прецедентов. Сценарии помогают
выделить объекты, классы и
взаимодействия объектов, необходимые
для исполнения единичного действия,
определенного прецедентом.

25.

СЦЕНАРИЙ
Сценарии описывают порядок того, как
обязанности, возложенные на прецеденты,
распределяются среди объектов и классов в
системе.
Каждый прецедент — это сплетение
первичных (нормальный поток для
прецедента) и вторичных сценариев (логика
ЧТО-ЕСЛИ в прецеденте).

26.

Поток событий для прецедента
описывается словами, тогда как сценарии
отображаются с помощью диаграмм
взаимосвязи (interaction diagrams).
Существует два типа диаграмм
взаимосвязи — диаграммы
последовательности действий (sequence
diagrams) и диаграммы взаимодействий
(collaboration diagrams). Каждая диаграмма
является графическим представлением
сценария.

27.

ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ СИСТЕМЫ
Диаграмма последовательностей системы —
графическая модель, которая для определенного
сценария варианта использования показывает
динамику взаимодействия объектов во времени.
Для построения диаграммы последовательностей системы
необходимо:
- идентифицировать каждое действующее лицо (объект) и
изобразить для него линию жизни;
- из описания варианта использования определить
множество системных событий и их последовательность;
- изобразить системные события в виде линий со
стрелкой на конце между линиями жизни действующих
лиц и системы, а также указать имена событий и списки
передаваемых значений.

28.

ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ СИСТЕМЫ
Наименования объектов на диаграмме
последовательности действий

29.

ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ СИСТЕМЫ
Нотация языка UML для объектов и сообщений на
диаграмме последовательности действий

30.

ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ СИСТЕМЫ
Диаграмма последовательности действий с объектом предмет,
присвоенным классу предмет, для сценария создание учебного
предмета.

31.

ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ СИСТЕМЫ
Фокус управления

32.

ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ СИСТЕМЫ
Диаграмма последовательности для моделирования процесса
телефонного разговора с использованием обычной телефонной сети.

33.

ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ
Диаграмма взаимодействий (collaboration diagram) — это
альтернативный способ отображения сценариев. Такой тип
диаграммы показывает взаимодействие объектов,
организованное вокруг них, и их связи друг с другом.
Диаграмма взаимодействий содержит:
□ объекты, изображаемые в виде прямоугольников;
□ связи между объектами, изображаемые в виде линий;
□ сообщения в виде текста и стрелки, направленной от клиента к
поставщику.

34.

ДИАГРАММА ВЗАИМОДЕЙСТВИЯ

35.

ДИАГРАММЫ ДЕЯТЕЛЬНОСТЕЙ (ДЕЙСТВИЙ)
Нотация языка UML для элементов диаграммы действий

36.

Фрагмент диаграммы деятельности для алгоритма нахождения
корней квадратного уравнения

37.

ДИАГРАММЫ ДЕЯТЕЛЬНОСТЕЙ (ДЕЙСТВИЙ)
Линия синхронизации

38.

ДИАГРАММА ДЕЯТЕЛЬНОСТИ ПРОЦЕССА ПРИГОТОВЛЕНИЯ НАПИТКА
Линия синхронизации

39.

ДИАГРАММА ДЕЯТЕЛЬНОСТИ ПРОЦЕССА
Линия синхронизации

40.

ДИАГРАММЫ СОСТОЯНИЙ
Выход из строя
Ремонт
Диаграмма состояний по существу
является графом специального вида,
который представляет некоторый
автомат.
Основными понятиями,
описывающими автомат,
являются состояние и переход.
Список внутренних действий:
<метка-действия> /<выражение-действия>

41.

ДИАГРАММЫ СОСТОЯНИЙ
Диаграмма состояний для моделирования почтовой
программы-клиента

42.

ДИАГРАММЫ КЛАССОВ
UML предлагает использовать три уровня
диаграмм классов в зависимости от степени их
детализации:
- концептуальный уровень, на котором
диаграммы классов отображают связи между
основными понятиями предметной области;
- уровень спецификаций, на котором
диаграммы классов отображают связи объектов
этих классов;
- уровень реализации, на котором диаграммы
классов непосредственно показывают поля и
операции конкретных классов.

43.

ДИАГРАММЫ КЛАССОВ
Диаграмма классов может отражать
различные взаимосвязи между отдельными
сущностями предметной области, такими как
объекты и подсистемы, а также описывает их
внутреннюю структуру и типы отношений.
Диаграммы классов обычно содержат
следующие сущности:
- классы;
- интерфейсы;
- кооперации;
- отношения зависимости, обобщения и
ассоциации.

44.

ДИАГРАММЫ КЛАССОВ
Графическое изображение класса на диаграмме
классов

45.

ДИАГРАММЫ КЛАССОВ
Примеры графического изображения классов на
диаграмме

46.

ДИАГРАММЫ КЛАССОВ
Атрибуты класса
Во второй секции прямоугольника —
графического изображения класса —
записываются его атрибуты (attributes) или
свойства. Стандартная запись атрибута в языке
UML выглядит следующим образом:
<квантор видимости> <имя атрибута>
[кратность] <тип атрибута> <исходное
значение>{строка-свойство}

47.

ДИАГРАММЫ КЛАССОВ
Квантор видимости:
- общедоступный (public) — обозначается «+»;
- защищенный (protected) — обозначается «#»;
- закрытый (private) — обозначается «-».
Кратность атрибута показывает количество
конкретных атрибутов данного типа, входящих в состав
класса, и обозначается следующим образом:
[нижняя_граница1.. верхняя_граница1,
нижняя_граница2..верхняя_граница2,
нижняя_границак..верхняя_границак]
[0..1] , [0..*] , [1..*] , [1..5] , [ 1. .3,7.. 10] , [ 1..3,7..*]
Например:
Имя_студента [1..2] String = Иван.

48.

ОПЕРАЦИИ КЛАССА
Операцией класса (.методом класса) называется
именованный сервис, который предоставляется по
требованию любым объектом данного класса.
Описание операции имеет следующий вид:
<квантор видимости> <имя операции>
(список параметров) <выражение типа
возвращаемого значения>{строкасвойство}
Квантор видимости принимает такие же значения, как
и в случае атрибутов класса, и может быть опущен.
Вместо условных графических обозначений также
можно записывать соответствующее ключевое слово:
public, protected, private.

49.

ОПЕРАЦИИ КЛАССА
Имя операции представляет собой строку текста,
которая используется в качестве идентификатора
соответствующей операции, и поэтому должна быть
уникальной в пределах данного класса. Имя является
единственным обязательным элементом
синтаксического обозначения операции.
Список параметров является перечнем разделенных
запятой формальных параметров, каждый из которых
может быть представлен в следующем виде:
<вид параметра> <имя параметра>: <выражение
типа>=<значение параметра по умолчанию>.
Вид параметра — это одно из ключевых слов in, out
или inout со значением in по умолчанию.

50.

ОПЕРАЦИИ КЛАССА
Строка-свойство служит для определения значений
свойств данного элемента. Строка-свойство может
отсутствовать, если никакие свойства не
специфицированы.
Операция, которая не может изменять состояние
системы, обозначается строкой-свойством {запрос}
({query}).
Если в некотором классе операция не выполняется, то
такая операция может быть помечена как абстрактная
({abstract}).
Пример: +создать()

51.

СТЕРЕОТИПЫ КЛАССА
Классы со стереотипами

52.

ДОКУМЕНТАЦИЯ
Документация предназначена для описания
назначения класса, а не его структуры.
Например, класс студент может быть
описан следующим образом:
Информация, необходимая для
регистрации студента и оплаты
обучения. Студент — это человек,
обучающийся в университете.
Пример неправильного описания:
Имя, адрес и телефон студента.

53.

ПАКЕТЫ
Пакет (package) — это
набор классов и других
связанных пакетов.
Путем объединения
классов в пакеты можно
получить представление
модели на более высоком
уровне. Изучая
содержимое пакета,
наоборот, получают более
детальное представление.

54.

ДИАГРАММЫ КЛАССОВ
Главная диаграмма классов в логическом
представлении модели обычно отображает
пакеты системы. Каждый пакет также имеет
свою главную диаграмму классов, которая
обычно содержит общедоступные классы пакета.
Другие диаграммы создаются по необходимости.
Типичные примеры использования диаграмм
классов:
□ просмотр всех классов реализации в пакете;
□ просмотр структуры и поведения одного или
нескольких классов;
□ просмотр иерархии наследования классов.