Lektsia_4_lb_5

1. Проектирование функциональной структуры программного продукта: объектно-ориентированный подход

2. Лабораторная работа №5

1 Абстракции подсистемы
Проанализировать описание функционирования программной системы,
разработанного при выполнении лабораторной работы №4, выявить набор абстракций
предметной области проектируемой ПС. Разделить выделенные в проекте абстракции
на три типа: абстракции сущности, абстракции поведения, абстракции интерфейсы.
Результат представить в виде таблицы 1.
Абстракция интерфейса отображает операции обращения к реализации сущности,
абстракция поведения это операции модификации сущности.

3. Лабораторная работа №5

2 Классификация абстракций
Провести классификацию обнаруженных абстракций по классическому
подходу. Заполнить таблицу 2

4. Лабораторная работа №5

3 Абстракции подсистемы и их поведение
Проанализировать поведение выделенных абстракций. Выделить возможное
поведение каждой абстракции в пределах рассматриваемой функции
(потребности, табл. 1). Заполнить таблицу 3.

5. Диаграммы UML:

• Прецедентов
• Активности (деятельности)
• Последовательности
• Кооперации
• Компонентов
• Классов
• Состояний
• Развёртывания

6. Диаграмма классов (1)

Отражают статическую структуру приложения.
Диаграмма классов – набор статических, декларативных
элементов модели (используются при кодогенерации).
Отображают классы, интерфейсы и отношения между
ними.
Классы - это строительные блоки любой объектно-ориентированной системы. Они
представляют собой описание совокупности объектов с общими атрибутами,
операциями, отношениями и семантикой. При проектировании объектноориентированных систем диаграммы классов обязательны.

7. Диаграмма классов (2)

8. Диаграмма классов (3)

Один из видов отношений между объектами это ассоциация. Это просто связь между
объектами, по которой можно между ними
перемещаться. Ассоциация может иметь имя,
показывающее природу отношений между
объектами, при этом в имени может указываться
направление чтения связи при помощи
треугольного маркера. Однонаправленная
ассоциация может изображаться стрелкой.

9. Диаграмма классов (4)

Объекты находятся в определенных отношениях друг с другом. Один из типов таких
отношений - это зависимость. Зависимость возникает тогда, когда реализация класса
одного объекта зависит от спецификации операций класса другого объекта. И если
изменится спецификация операций этого класса, необходимо вносить изменения и в
зависимый класс.

10. Диаграмма классов (5)

Отношение между классами, например,
связь типа "часть-целое". Такой вид
ассоциации называется ассоциацией с
агрегированием. В этом случае один класс
имеет более высокий статус (целое) и
состоит из низших по статусу классов
(частей). При этом выделяют простое и
композитное агрегирование и говорят о
собственно агрегации и композиции.
Простая агрегация предполагает, что части,
отделенные от целого, могут продолжать
свое существование независимо от него. Под
композитным же агрегированием
понимается ситуация, когда целое владеет
своими частями и их время жизни
соответствует времени жизни целого, т. е.
независимо от целого части существовать не
могут.

11. Лабораторная работа №5

4 Диаграмма классов

12.

Модель классов UML для ПС продажи авиабилетов
(Visual Studio 2013 Ultimate)
<<entity>>
<<entity>>
<<entity>>
<<entity>>
<<entity>>
<<entity>>
<<entity>>
<<control>>
<<boundary>>
<<boundary>>
<<control>>
12

13. Диаграммы UML:

• Прецедентов
• Активности (деятельности)
• Последовательности
• Кооперации
• Компонентов
• Классов
• Состояний
• Развёртывания

14. Диаграмма состояний (1)

Отражают динамические аспекты системы.
Применяются для того, чтобы объяснить, каким образом работают
сложные объекты, как объекты переходят из одного состояния в
другое.
Описывает процесс изменения состояний только одного
(реактивного) объекта.
Диаграмма состояний показывает, как объект переходит из одного состояния в
другое. Диаграммы состояний служат для моделирования динамических аспектов
системы (как и диаграммы последовательностей, кооперации, прецедентов и
диаграммы деятельности).

15. Диаграмма состояний (2)

16. Лабораторная работа №5

5 Диаграмма состояния
Диаграмма состояния на основе выбранного класса (Пример: Заказ и Отчет).

17.

Модель состояний UML, построенная для объекта «Авиабилет»
(MS Visio 2010)
17

18. Диаграммы UML:

• Прецедентов
• Активности (деятельности)
• Последовательности
• Кооперации
• Компонентов
• Классов
• Состояний
• Развёртывания

19. Диаграмма активности (1)

Диаграмма, отражающая детали алгоритмической
реализации операций.
Используется для визуализации алгоритмов, по
которым работают операции классов.
(Обозначения – как на блок-схеме, плюс знак
распараллеливания).

20. Диаграмма активности (2)

21. Диаграмма активности (3)

22. Диаграмма деятельности прецедента «Продажа продукта»

23. Лабораторная работа №5

6 Диаграмма деятельности
Диаграмма деятельности
Пример: Оформить продажу товара
покупателю по заказу

24.

Модель деятельности UML, построенная для системы в целом
(Rational Rose)
Авторизация на сайте
авиакомпании
Ввод
данных
Выбор
операции
Да
Нет
Да
Сайт
работает?
Нет
Нет
Личный
визит
Оставлени
е данных
БД работает?
Да
Внести
повторно
Данные
коректны?
Возврат
Вынесение
счёта
Бронирова
ние
Оплата безналичным
расчётом на кассе
Нет
Да
Покупка
билета
Получение
квитанции
Нет
Да
Оплата
прошла?
Показ квитанции
на ресепшене
Занесение в
БД оплаты
Возврат билета в
авиакомпанию
Завершение
Повторить
платеж
Приехать в
другой день
Заполнение документов
на возврат
Получение денежных
средств
24

25. Лабораторная работа №5

7 Прецеденты и их объекты
Таблица 4. Список объектов для каждого потока событий

26. Диаграммы UML:

• Прецедентов
• Активности (деятельности)
• Последовательности
• Кооперации
• Компонентов
• Классов
• Состояний
• Развёртывания

27. Диаграмма последовательности (1)

Одна из двух диаграмм взаимодействия.
Диаграмма, отображающая последовательность, в
которой объекты в процессе взаимодействия
обмениваются
сообщениями.
Отображает
взаимодействие объектов в динамике.
Диаграммы последовательностей можно использовать
для уточнения диаграмм прецедентов, более
детального
описания
логики
сценариев
использования.
Объекты обозначаются прямоугольниками с подчеркнутыми именами,
сообщения (вызовы методов) - линиями со стрелками, возвращаемые
результаты - пунктирными линиями со стрелками. Прямоугольники на
вертикальных линиях под каждым из объектов показывают "время
жизни" (фокус) объектов.

28. Диаграмма последовательности (2)

29. Диаграмма последовательности (3)

30. Диаграмма последовательности прецедента «Продажа продукта»

31. Лабораторная работа №5

8 Диаграммы последовательности
Пример: Диаграмма последовательности (Оформить продажу товара
покупателю по заказу)

32. Лабораторная работа №5

8 Диаграммы последовательности

33. Диаграммы UML:

• Прецедентов
• Активности (деятельности)
• Последовательности
• Кооперации
• Компонентов
• Классов
• Состояний
• Развёртывания

34. Диаграмма кооперации (1)

Одна из двух диаграмм взаимодействия.
Диаграмма, акцентирующая внимание на ролях, которые
объекты играют в процессе взаимодействия
(распределяет функциональность между классами).
Диаграмма взаимодействия показывает поток сообщений
между объектами системы и основные ассоциации между
ними и по сути, является альтернативой диаграммы
последовательностей.
Объект, кооперация (пунктирный эллипс),
взаимоотношения (стрелки).

35. Диаграмма кооперации (2)

36. Диаграмма кооперации (3)

Диаграмма описывает работу персонала библиотеки по обслуживанию клиентов:
библиотекарь получает заказ от клиента, поручает сотруднику найти информацию
по нужной клиенту книге, а после получения данных поручает еще одному
сотруднику выдать книгу клиенту.

37.

Порядок решения задач по созданию функциональных
подсистем: организационный аспект
1. Заключение договора на выполнение работ по информатизации.
2. Изучение объекта информатизации (выделение функциональных
подсистем и автоматизированных функций в этих подсистемах).
3. Разработка технического задания на выполнения одной задачи
(крупная), на несколько задач или на функциональную подсистему,
систему (согласно договору).
4. Постановка задачи:
- выполняется словесная формулировка задачи;
- устанавливается входная (текущая) информация;
- представляются формы выходной информации;
- определяется
нормативно-справочная
(условно-постоянная)
информация;
- определяется частота решения задачи.
5. Формализованное описание задач: выбирается математический метод
и разрабатывается математическая модель решения задачи.
37
6. Разработка макро- и микро-алгоритмов решения задачи.

38.

Порядок решения задач по созданию функциональных
подсистем: организационный аспект
7. Выбор языка программирования и разработка программ решения
задачи.
8. Отладка программы и тестирование.
9. Создание
(модификация)
технической
платформы
для
автоматизированного решения задачи (КТС).
10.Интеграция аппаратной и программной частей и решение
контрольного примера.
11.Внедрение подсистемы ПС решения задачи в эксплуатацию.
12.Разработка инструкции пользователю (заказчику) по решению задачи с
использованием ПС.
13.Разработка функциональной спецификации ПС.
14.Сдача-приемка подсистемы ПС пользователю исполнителем согласно
договору (см.п.1).
15.Постоянная эксплуатация ПС – решение задач при помощи
разработанной подсистемы на постоянной основе.
16.Обслуживание и поддержка ПС согласно договору (см.п.1).
38