Проектирование Информационной системы для публикации и комментирования статей

1. UML 2016

06

2. https://vk.com/club129679290

Проектирование Информационной системы для публикации и
комментирования статей.

3. Календарный план

1.
Получение и уточнение задания
2.
Диаграмма вариантов использования
3.
Модель анализа
4.
Диаграммы кооперации
5.
Диаграммы классов проектирования
6.
Диаграммы последовательности
7.
Оформление ПЗ

4.

Спроектировать информационную систему на основе парадигмы
объектного моделирования UML, осуществляющую ввод и
комментирование информации различными пользователяи.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

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

18. Общие элементы

- экземпляры актеров и объекты, участвующие во взаимодействии;
- сообщения, передаваемые между экземплярами актеров и объектами.

19. Экземпляры сущностей

Имя объекта : Имя класса (например, Вася : Программист);
: Имя класса (например, : Программист) – анонимный объект;
Имя объекта (например, Вася) – предполагается, что имя класса известно;
Имя объекта : (например, Вася :) – объект-сирота. Считается, что имя
класса неизвестно.

20. Линия жизни

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

21. Примеры отображения экземпляров сущностей, линии жизни и символа уничтожения объекта

22. Сообщения

синхронное сообщение (synchronous message). Клиент посылает сообщение
серверу и ждет, пока тот примет и обработает сообщение. Как правило, один
объект передает синхронное сообщение второму, второй – третьему и т.д.,
образуя вложенный поток сообщений. В любом случае клиент, инициирующий
поток сообщений, должен дождаться его завершения, т.е. возврата
управления. Это самый распространенный тип сообщений;
асинхронное сообщение (asynchronous message). Клиент посылает
сообщение серверу и, не дожидаясь ответа, продолжает выполнять
следующие операции;
возвращающее сообщение (reply message), обозначающее возврат
значения или управления от сервера обратно клиенту. Стрелки этого вида
зачастую отсутствуют на диаграммах, поскольку неявно предполагается их
существование после окончания процесса выполнения операции.

23. Специфические виды сообщений

Объект может посылать сообщения самому себе (вызывать собственные
методы), инициируя так называемые рефлексивные сообщения.
Сообщения, получаемые от внешнего источника (found message)
Сообщения, передаваемые внешнему приемнику (lost message), должны,
соответственно, начинаться и заканчиваться закрашенным кружком.
Создание объектов отображается как возвращающее сообщение со
стереотипом «create»
Уничтожение синхронное сообщение со стереотипом «destroy». После
получения сообщения на уничтожение объекта его линия жизни
заканчивается символом X

24. Каждое сообщение должно иметь

- произвольная строка текста. Применяется на начальных стадиях
проектирования или концептуальных диаграммах;
- указание стереотипа для некоторых стандартных действий:
- «create» (создать) – возвращающее сообщение, требующее создания объекта;
- «destroy» (уничтожить) – синхронное сообщение с требованием уничтожить
соответствующий объект;
- «call» (вызвать) – синхронное сообщение, требующее выполнения операции
принимающего объекта;
- «send» (послать) – асинхронное сообщение, обозначающее посылку сигнала
серверу;
- «return» (возвратить) или «reply» (ответить)– возвращающее сообщение;

25.

Указание спецификации вызываемого метода объекта-получателя в
формате:
[переменная =] имя([список параметров]) [:возвращаемое значение].
Переменная - переменная или атрибут объекта-отправителя, которому
будет присвоен результат вызываемого метода.
Имя сообщения (обязательный параметр) – имя вызываемого метода
объекта-получателя.
Список аргументов – список аргументов, разделенных запятыми и
передаваемых для выполнения метода.
Возвращаемое значение – константа или имя переменной, являющиеся
результатом вызываемого метода.

26.  Фокус управления 

Фокус управления

27. Фрагменты 

Фрагменты

28. Типы фрагментов

- alt (alternatives) - вызовы альтернативных сообщений (выполнение
взаимоисключающих операций). Альтернативные сообщения (группы
сообщений) отделяются друг от друга горизонтальными штриховыми линиями.
Используется для моделирования условного оператора (if-then-else) и
операторов выбора (case или switch);
- opt (option) - вызов дополнительного сообщения (группы сообщений) при
некотором условии. Аналогичен фрагменту с типом «alt» для случая, когда
используется сокращенный условный оператор (if-then);
- par (parallel) - параллельная обработка сообщений. Параллельно
обрабатываемые сообщения (группы сообщений) отделяются друг от друга
горизонтальными штриховыми линиями;
- loop - циклическая обработка сообщений. Используется для моделирования
циклов;
- break - досрочное прерывание обработки сообщений при некотором условии.
Используется как составная часть других фрагментов (как правило, «loop»);

29.

- critical - эксклюзивно обрабатываемое сообщение (группа сообщений).
Используется как составная часть других фрагментов (как правило, «par»).
Подразумевает приостановку обработки любых сообщений в более общем
фрагменте на время обработки сообщений внутри подфрагмента «critical»;
- neg (negative) - сообщение или событие, сгенерированное в результате
невозможности обработки другого принятого сообщения. Например, если при
запросе пароля getPassword() истекло время на его ввод, то вместо возврата
пароля будет сгенерировано сообщение «время вышло» (англ. «timeout»);
- assert (assertion) - сообщение (группа сообщений), выполняемое после
предварительной проверки некоторого условия. Если условие отрицательно,
то сообщение не посылается. В программировании такой прием часто
используется для локализации ошибок;
- strict - строгая последовательная обработка сообщений. Последовательно
обрабатываемые сообщения (группы сообщений) отделяются друг от друга
горизонтальными штриховыми линиями и обрабатываются строго по очереди
сверху-вниз;
- seq (sequencing) - нестрогая последовательная обработка сообщений.
Сообщения (группы сообщений) отделяются друг от друга горизонтальными
штриховыми линиями и могут обрабатываться в произвольном порядке за
исключением сообщений, принимаемых одним объектом;

30.

- ignore - игнорирование сообщений. После слова «ignore» в фигурных
скобках перечисляются сообщения, возникновение которых во фрагменте
потенциально возможно наряду с явно отображенными и которые должны
быть проигнорированы;
- consider - игнорирование других сообщений. После слова «consider» в
фигурных скобках перечисляются сообщения, которые явно отображены
во фрагменте, а также возникновение которых во фрагменте
потенциально возможно наряду с явно отображенными. Остальные
потенциально возможные сообщения должны быть проигнорированы;
- ref (reference) - ссылка на часть взаимодействия, определенную в
другом месте (на другой диаграмме). Данный элемент подобен
предопределенным процессам на блок-схемах или скрытым составным
состояниям на диаграммах автоматов.

31. Правила и рекомендации

1. Для выбранного варианта использования необходимо перенести
с диаграммы классов анализа все участвующие в нем классы, а
с диаграммы вариантов использования – актеров.
2. На диаграмме коммуникации между классами следует отобразить
ассоциации, перенесенные с диаграммы классов анализа, а также
добавить ассоциации, связывающие актеров с граничными классами.
3. Для отображения основного и альтернативного потоков событий
(наборов сообщений) в рамках варианта использования следует
использовать фрагмент с типом «alt».
4. На стадии анализа имена сообщениям можно давать произвольно
(например, «Записать данные о клиенте») или в виде стереотипов. В
дальнейшем (в модели проектирования) имена сообщений должны
соответствовать методам классов.

32.

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

33.

34.

35. ветвление

36.

37.

38. ДИАГРАММЫ ПАКЕТОВ

39. Цели

добиться лучшей структурной организации модели (сильнее
формализовать модель);
более четко и продуманно распределить обязанности между отдельными
разработчиками или их командами;
упростить повторное использование отдельных пакетов в других проектах,
так как связи между пакетами, как правило, минимальны.

40. Способы отображения содержимого пакетов

41. Примеры отношений между пакетами

«import» (импорт) или «merge» (слияние).

42.

«import» позволяет при обращении сущности из одного пакета к сущности
другого пакета указывать только ее имя, а не полную спецификацию.
в объекте класса TableScreen необходимо создавать объекты класса
TextFieldDouble, после импортирования достаточно для этих целей
использовать имя класса «new TextFieldDouble(...)» вместо «new
ru.lib.field.TextFieldDouble(...)».
«merge» практически идентична отношению обобщения. В частности,
пакет ru.iskraPUT.panel помимо своих сущностей (подпакетов и классов)
будет содержать сущности пакета ru.lib.panel. Если в двух пакетах будут
сущности с одинаковым именем, то сущность в результирующем пакете
(ru.iskraPUT.panel) будет расширена за счет специфических свойств
сущности исходного пакета (ru.lib.panel). Отличие от отношения
обобщения заключается в отсутствии наследования сущностей с областью
видимости «private» (частных сущностей).

43. Подходы

- группировать классы по стереотипу. В одном пакете будут
находиться классы сущностей, в другом – граничные, в третьем –
управляющие;
- группировать по семантической однородности. Например, пакет
«Безопасность» будет содержать все классы, отвечающие за безопасность
системы;
- группировать по подсистемам (по функциональности). Например, при
разработке большой и сложной системы, состоящей из нескольких
взаимодействующих подсистем;
- комбинировать три подхода, описанных выше.

44.

45. Модель реализации

46.

- определение окончательного состава, структуры и кода классов;
- распределение классов по компонентам и подсистемам;
- определение топологии распределенной системы и распределение
подсистем по узлам сети;
- планирование итераций (версий) сборки системы;
- сборка версий системы.

47.

48. ДИАГРАММЫ КОМПОНЕНТОВ

49. цели

- спецификация общей структуры исходного кода системы;
- спецификация исполнимого варианта системы.

50. Компонент

физическая часть системы. Компоненты, представляющие собой файлы с
исходным кодом классов, библиотеки, исполняемые модули и т.п.,
которые должны обладать согласованным набором интерфейсов.
- «file» – любой файл, кроме таблицы:
«executable» – программа (исполняемый файл);
«library» – статическая или динамическая библиотека;
«source» – файл с исходным текстом программы;
«document» – остальные файлы (например, файл справки);
- «table» – таблица базы данных.

51. Компонент с секциями

• предоставляемые (provided)
• или необходимые для работы (required)
интерфейсы
• классы,
• методы (operations), н
• аименование файла-компонента (artifacts)

52. Интерфейс

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

53. Отношения

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

54.

55. ДИАГРАММЫ РАЗВЕРТЫВАНИЯ

56. Цели

- распределение компонентов системы по ее физическим узлам;
- отображение физических связей между узлами системы на этапе
исполнения;
- выявление узких мест системы и реконфигурация ее топологии для
достижения требуемой производительности.

57. Узел

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

58.  Узел с компонентами

Узел с компонентами

59. Соединения

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

60.

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

61.

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

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

Диаграммы последовательности действий отображают взаимодействие
объектов, упорядоченное по времени.
Основными компонентами диаграмм последовательности действий
являются:
- Объекты;
- Линия жизни;
- Сообщения.

63. Объекты

Объект – экземпляр класса.
Имя класса
объектА: КлассВ
: КлассС
Имя объекта
объектD
Объект-сирота

64. Графические элементы диаграммы последовательности

объектА:
КлассВ
объектС
Фокус
управления
Сообщение
:КлассD
Линия
жизни
Символ
уничтожения
объекта

65. Линия жизни и фокус управления

объектА:
КлассВ
объектС
Объект С инициирует
создание анонимного
объекта из класса D
:КлассD

66. Сообщение

Представляет собой законченный фрагмент
информации, который отправляется одним
объектом другому;
Прием сообщения инициирует выполнение
определенных действий;
3 разновидности сообщений:
а)
б)
в)

67. Сообщение

Сообщение, отправленное самому себе – рефлексивное
(саморегулирование).
ИмяОбъекта4 :
ИмяКласса4
4:

68. Пример диаграммы последовательности

с: Телефонный
аппарат
: Коммутатор
d: Телефонный
аппарат
а: Абонент
поднятьТрубку()
*[i:=1..n]
наборЦифры(i)
b: Абонент
тонСигнал()
наборНомера()
[номер полный]
вызовАбонента(b)
звонок()
создать()
начатьРазговор()
: Разговор
поднятьТрубку()
подтвердить(
)
начатьРазговор()
закончитьРазговор()
повеситьТрубку()
закончитьРазговор()
уничтожить()
повеситьТрубку()

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

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

Отражает динамику системы и представляет собой схемы потоков
управления в системе от действия к действию, а также параллельные
действия и альтернативные потоки .
В контексте языка UML деятельность представляет собой некоторую
совокупность отдельных вычислений, выполняемых автоматом.

71. Компоненты диаграммы деятельности

Основные элементы диаграмм деятельности:
- деятельность (действие)
- переход
- элемент выбора
- линия синхронизации (линейка синхронизации).

72. Действие (деятельность)

Действие - исполнение определенного поведения в потоке
управления системой
Имя может быть записано на
естественном языке
Налить
кофе
… или на языке
программирования
y:=y+1

73. Элемент выбора

Элементы выбора позволяют задавать альтернативные пути потока
управления.
Условие 2
Условие 1
Условие – логическое выражение, которое
может принимать значение true или false

74. Пример ветвления переходов

Преобразовать уравнение к
каноническому виду
Вычислить
дискриминант
[ дискриминант>=0 ]
[ дискриминант<0 ]
Вычислить корни
квадратного уравнения

75. Линии синхронизации

Линии перехода могут иметь несколько входящих линий и 1
исходящую, либо 1 вход и несколько выходов.

76. Дорожки (Swimlane)

Группа действий между дорожками выполняется
соответствующим подразделением

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

Подготовка
участка
Подведение
электрической линии
Прокладка
электропроводки
Установка
осветительных ламп
Возведение стен и
фундамента
Возведение
крыши
Отделочные
работы

78. Изученные вопросы

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

79. Диаграммы реализации

80. Виды диаграмм реализации

Диаграммы
реализации
Диаграммы
компонентов
Диаграммы
развертывания

81. Диаграмма компонентов

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

82. Компонент

Служит для обозначения элементов физического представления
модели и может реализовывать некий набор интерфейсов.
Каталог

83. Пример диаграммы компонентов

Main.cpp
Dialog.dll
Main.exe
Index.html
Context.hlp

84. Диаграмма размещения

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

85. Диаграмма размещения

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

86. Пример диаграммы компонентов

Удаленный
терминал
Сервер
банка
Сеть
Принтер
банкомата
Устройство
чтения
Устройство
получения наличных
Экран
банкомата

87.

http://www.telenir.net/uchebniki/samouchitel_uml/p8.php