Основы проектирования программного обеспечения автоматизированных систем с применением нотаций UML и IDEF0

1. Лекция по теме «Основы проектирования программного обеспечения автоматизированных систем с применением нотаций UML и IDEF0»

Автор лекции:
канд. техн. наук, доцент
Полевщиков Иван Сергеевич

2. Язык UML

• UML (Unified Modeling Language – унифицированный язык
моделирования) используется для визуализации,
спецификации, конструирования и документирования
результатов программных проектов.
• Процесс разработки визуальных моделей в нотации языка
UML представляет собой построение ряда диаграмм.
• Диаграмма в языке UML — это графическое представление
множества элементов, наиболее часто изображается как
связный граф из вершин (предметов) и дуг (отношений).
• Диаграммы рисуются для визуализации программной
системы с разных точек зрения.
2/19

3. Диаграмма Use Case

• Диаграмма Use Case языка UML (синонимы –
диаграмма прецедентов, диаграммами вариантов
использования) определяет поведение программной
системы с точки зрения пользователя.
• Диаграмма Use Case рассматривается как главное
средство для первичного моделирования динамики
системы, используется для выяснения требований к
разрабатываемой системе, фиксации этих требований в
форме, которая позволит проводить дальнейшую
разработку.
3/19

4. Вариант использования (use case)

• Вариант использования (use case) – общая
спецификация совокупности выполняемых системой
действий с целью предоставления некоторого
наблюдаемого результата, который имеет значение для
одного или нескольких актеров.
• Вариант использования представляет собой
законченный фрагмент поведения системы с точки
зрения тех или иных заинтересованных лиц.
• Графическое изображение и примеры вариантов
использования:
4/19

5. Актер

• Актер (actor) – внешняя по отношению к проектируемой
системе сущность, которая взаимодействует с системой и
использует ее функциональные возможности для
достижения определенных целей или решения частных
задач.
• Каждый актер специфицирует некоторую роль, которую
играет пользователь или любая другая система,
взаимодействующая с субъектом.
• Графическое изображение и примеры актеров:
5/19

6. Отношения на диаграммах Use Case. Отношение ассоциации

• Отношение (relationship) в языке UML – произвольная
семантическая взаимосвязь между отдельными элементами
модели.
• Отношение ассоциации (association) служит для обозначения
взаимодействия актера с вариантом использования.
• Графическое изображение направленной ассоциации:
• Графическое изображение ненаправленной ассоциации:
6/19

7. Отношение зависимости

• Отношение зависимости (dependency) – форма взаимосвязи между
двумя элементами модели, предназначенная для спецификации того
обстоятельства, что изменение одного элемента модели приводит к
изменению некоторого другого элемента.
• Отношение включения (include) является частным случаем отношения
зависимости и специфицирует тот факт, что некоторый вариант
использования содержит поведение, определенное в другом варианте
использования.
• Отношение расширения (extend) является частным случаем отношения
зависимости и определяет взаимосвязь одного варианта использования с
некоторым другим вариантом использования, функциональность или
поведение которого задействуется первым не всегда, а только при
выполнении некоторых дополнительных условий.
7/19

8. Отношение обобщения

• Отношение обобщения (generalization) предназначено для
спецификации того факта, что один элемент модели является
специальным или частным случаем другого элемента модели.
• Пример изображения отношения обобщения между вариантами
использования:
• Пример изображения отношения обобщения между актерами:
8/19

9. Пример диаграммы вариантов использования Прямоугольником обозначен субъект (subject)

9/19

10.

10/17
Функциональные требования к АИС
(диаграмма Use Case UML)

11. Комментарий

• Комментарий (comment) – уточняющая информация,
относящаяся к контексту тех или иных вариантов использования
или актеров.
10/19

12. Диаграммы деятельности UML

• Диаграммы деятельности языка UML используются
для детализации особенностей алгоритмической и
логической реализации выполняемых системой операций.
• Графически диаграмма деятельности представляется в
форме графа деятельности, вершинами которого
являются состояния действия, а дугами – переходы от
одного состояния действия к другому.
•Каждое состояние действия на диаграмме деятельности
соответствует выполнению некоторой элементарной
операции, а переход в следующее состояние срабатывает
только при завершении этой операции в предыдущем
состоянии.
11/19

13. Пример диаграммы деятельности UML

• Алгоритм оплаты товаров по кредитной карточке в супермаркете:
12/19

14. Состояние действия, состояние под-деятельности, переходы

• Основной вершиной в диаграмме деятельности является состояние действия.
Пример графического изображения состояния действия:
• Состояние действия считается атомарным (действие нельзя прервать) и
выполняется за один квант времени, его нельзя подвергнуть декомпозиции.
• Если нужно представить сложное действие, которое можно подвергнуть
дальнейшей декомпозиции (разбить на ряд более простых действий), то
используют состояние под-деятельности. Пример графического изображения
состояния под-деятельности:
• Переходы между вершинами – состояниями действий – изображаются в виде
стрелок. Переходы выполняются по окончании действий. Пример графического
изображения перехода:
13/19

15. Вершины «решение» и «объединение»

• Вершина «решение» позволяет отобразить разветвление вычислительного
процесса.
• Решение изображается как ромбик с одной входящей и несколькими
исходящими стрелками, причем исходящие из нее стрелки помечаются
сторожевыми условиями ветвления:
• Вершина «объединение» отмечает точку объединения альтернативных потоков
действий.
• Объединение изображается как ромбик с несколькими входящими и одной
исходящей стрелкой:
14/19

16. Вершины «разделение» и «слияние»

• Вершина «разделение» позволяет показать параллельные потоки действий,
отмечая точки их синхронизации при запуске (момент разделения).
• Изображается как жирная горизонтальная линия с одной входящей и
несколькими исходящими стрелками:
• Вершина «слияние» позволяет показать параллельные потоки действий,
отмечая точки их синхронизации при завершении (момент слияния).
• Изображается как жирная горизонтальная линия с несколькими входящими и
одной исходящей стрелкой:
15/19

17. Начальное и конечное состояния

• Начальное состояние изображается как черный кружок:
• Конечное состояние изображается как незакрашенный кружок, в
котором размещен черный кружок меньшего размера:
• Каждая диаграмма деятельности должна иметь единственное
начальное состояние.
• При этом конечных состояний может быть несколько.
• Каждая деятельность начинается в начальном и заканчивается в
конечном состоянии.
• Саму диаграмму деятельности принято располагать таким
образом, чтобы действия следовали сверху вниз. В этом случае
начальное состояние будет изображаться в верхней части
диаграммы, а конечное – в ее нижней части.
16/19

18. Дорожки

• Каждая дорожка имеет имя и фиксирует область деятельности
конкретного лица, подразделения какой-либо организации и т.п.,
обозначая зону его ответственности.
• Пересекать линию дорожки могут только переходы, которые в
этом случае обозначают выход или вход потока управления в
соответствующую дорожку.
17/19

19. Пример №1 диаграммы деятельности UML

• Алгоритм оплаты товаров по кредитной карточке в супермаркете:
18/19

20. Пример №2 диаграммы деятельности UML

• Диаграмма деятельности торговой компании, обслуживающей
клиентов по телефону:
19/19

21. Алгоритм оценивания результатов выполнения упражнения (диаграмма Activity UML)

22. Алгоритм работы советующей подсистемы (диаграмма Activity UML)

23.

Алгоритм заполнения информации о повышении
квалификации (диаграмма Activity UML)

24.

Алгоритмы формирования документов
(диаграммы Activity UML)
Алгоритм формирования кадровой справки:
Алгоритм формирования результатов анкетирования:

25. Графическая нотация IDEF0 Контекстная диаграмма AS-IS. Деятельность заводской столовой

25

26. Графическая нотация IDEF0 Диаграмма декомпозиции AS-IS. Деятельность заводской столовой

26

27. Недостатки существующей системы

─ большие очереди в обеденные часы;
─ часто возникают проблемы с недостатком нужных купюр у
сотрудников;
─ потеря времени сотрудников, отведенного на обед;
─ ручное заполнение документов;
─ долгое ожидание результатов отчётности;
─ нет возможности получения информации в оперативном режиме
27

28. Контекстная диаграмма TO-BE. Деятельность заводской столовой

28

29. Диаграмма декомпозиции TO-BE. Деятельность заводской столовой

29