1. Процесс разработки “Design and programming are human activities. Forget it and all is lost.” B.Stroustrup, 1991

2. Фазы процесса Начало Уточнение Разработка Развитие

3. Методы OMT (Object Modeling Technique, Rumbaugh) RDD (Responsibility Driven Design) Objectory RUP (Booch, Rumbaugh, Jacobson) Способ моделирования Артефакты фаз процесса

4. CRC - карточки Class Student Ответственность Учиться Сдать экзамены Коллаборанты Teacher

5. UML Unified Modeling Language CASE - средства: Rational Rose Together ArgoUML

6. UML Язык моделирования Не является языком программирования Определяет нотацию Имеет метамодель, выраженную на нем самом

7. История 1988 – 1995 работы Mellor, Booch, Rambough, Jacobson, Koad, Jordan, Shlaer… 1995 – UML 0.8 (Grady Booch, Jim Rambough) 1997 – UML 1.0 (Grady Booch, Jim Rambough, Ivar Jacobson) Rational Software

8. Нотация Сущности Структурные Поведенческие Группирующие аннотационные Отношения Зависимость Ассоциация Обобщение Реализация

9. Нотация Диаграммы Вариантов использования Состояний Деятельностей Классов Объектов Последовательностей и кооперации Компонентов Размещения

10. Варианты использования Actor – внешнее по отношению к системе действующее лицо, некто или нечто взаимодействующее с системой, роль. Use case – некая последовательность действий системы, представляющая ценность для Actor-а, вариант использования системы (Ivar Jacobson). Use-case описывает, что делает система, но не указывает как.

11. Пример: Экзамен Teacher принимает экзамен у Student.

12. Включаемые use-cases Stereotype: > Различные use-cases могут иметь общие части abstract use-case не активируется actor-ами

13. Генерализация actor-ов Различные actors могут играть одну и те-же общую роль в некотором use-case

14. Расширение use-cases Stereotype: > Некоторые use-cases могут вызываться в контексте других только при некоторых условиях

15. Tips Use-case должен описывать ЧТО делает система, но НЕ КАК => Глубокие иерархии use-cases чаще всего бесполезны и ведут к функциональной декомпозиции => Большое количество мелких use- case не прибавят понимания того, что делает система

16. Диаграммы состояний Описывают состояния объекта и переходы между состояниями State – некое состояние объекта Event – событие, вызывающее переход Transition – переход в новое состояние Condition – условие перехода (true|false) Action – мгновенное непрерываемое действие, сопровождающее переход Activity – деятельность, связанная с состоянием

17. Пример: сдача экзамена

18. Пример: вложенные состояния Применение: группировка состояний и упрощение диаграммы Имеют не более одного начального и конечного состояний

19. Пример: состояния с историей Н – недавнее историческое состояние Н* - глубокое историческое состояние

20. Диаграммы деятельностей Описывают последовательности действий используются для описания операций и вариантов использования Activity - деятельность Transition – переходы между деятельностями Guard condition – условие перехода Decision – блок принятия решения Concurrent threads – параллельные деятельности Synchronization bar – линейка синхронизации параллельных деятельностей

21. Пример: банкомат

22. Классы Class – набор объектов с общей структурой и поведением Interface – базовый класс, задающий только поведение, имеет стереотип > Abstract class – базовый класс, не имеющий экземпляров Parameterized class – параметризованный класс, шаблон Instantiated class – депараметризованный шаблон

23. Примеры классов

24. Атрибуты классов Attribute – атрибут (поле) Class attribute – атрибут класса (static) Derived attribute – производный атрибут Export control – доступ (public, protected, private) Containment – способ включения (value, reference) Syntax: :

25. Атрибуты классов name, birth_date – аттрибуты age – производный аттрибут (вычисляется через birth_date)

26. Атрибуты классов name, birth_date и age - аттрибуты класса

27. Методы(операции) Method (operation) – метод Class method – метод класса (static) Export control – public, protected, private Syntax: name( ) : Parameter: parameter_name : type

28. Диаграмма классов - определяет типы объектов системы и статические связи между ними

29. Dependency Отношение зависимости Обладает ролью и множественностью Может иметь стереотип

30. Association Ассоциация - отношение взаимодействия Обладает 2-мя ролями Роль обладает множественностью (1, n, *, 0..n, 1..n, 1..*) Пример: работник может занимать несколько должностей, на одной должности находится не более одного работника

31. Association Ассоциация может иметь выделенное направление Должность связана базовым тарифом оплаты Тариф оплаты никак не связан с конкретной должностью

32. Aggregation Агрегация – отношение часть-целое Часть принадлежит только одному целому Сотрудник относится к одному и только одному отделу

33. Composition Композиция – частный случай агрегации Жизненный цикл частей и целого совпадают Отделы не существуют без компании

34. Generalization Генерализация (наследование, обобщение) – отношение частное-общее Отдел кадров – частный случай отдела

35. Realization Реализация – отношение детализации Треугольник и квадрат – реализации абстрактной фигуры

36. Диаграммы пакетов Package – пакет. Общий механизм организации элементов модели в группы Имеет имя Определяет пространство имен Может быть импортирован другим пакетом

37. Package

38. Package diagram

40. package: service

41. package: service::local

42. package: service::server

43. package: service::agent

44. стереотипы пакетов system – вся система subsystem – подсистема facade – представление другого пакета Например, пакет внешних интерфейсов подсистемы framework – набор шаблонов stub – заместитель другого пакета Созданный, например, для тестирования

45. Диаграммы взаимодействия Последовательностей - Sequence diagrams Коллабораций - Collaboration diagrams Отражают динамические аспекты поведения объектов Семантически эквивалентны Содержат: Объекты Связи Сообщения Потоки данных

46. sequence diagram

47. collaboration diagram

48. Диаграммы компонент Показывают связи между компонентами системы стереотипы компонент: executable - исполняемый компонент library - библиотека table - таблица базы данных file - файл данных document - документ

49. component Компонент – физическая упаковка логической сущности Может реализовывать несколько классов и интерфейсов Использует другие компоненты

50. component diagram

51. servers

52. Диаграмма размещения Показывает физическое расположение исполняемых компонент по процессорам системы и структуру сети Элементы: Node – узел, процессор Process – процесс, поток

53. deployment diagram

54. Rational Unified Process

55. RUP: Business modeling Задачи: Идентификация бизнес-процессов (use-cases) Идентификация бизнес-акторов и сущностей(entity) Улучшение (refine) бизнес-процессов Модели: business use-case model business object model

56. business use-case model Модель, описывающая бизнес процессы в терминах business-actors и business use-cases Business actor – некто или нечто вовне бизнеса, взаимодействующее с ним UML: класс со стереотипом > Business use-case – бизнес-процесс, представляющий ценность для business actor UML: use-case со стереотипом >

57. business use-case model

58. business object model Модель, описывающая реализацию business use-cases в терминах взаимодействующих business workers и entities Business use-case realization – коллаборация, описывающая при помощи activity, sequence, class и interaction диаграмм, как данный business use-case реализован в business-object model. UML: use-case со стереотипом “business use-case realization”

59. business objects Business-worker – исполнитель бизнес- процесса UML: class со стереотипом > Business-entity – пассивная сущность, используемая в бизнесе UML: class со стереотипом >

60. business object model use-case realization содержит набор диаграмм, описывающих КАК реализован исходный use-case

61. activity diagram для use-case realization “контракт”

62. class diagram для use-case realization “контракт”

63. Collaboration diagram для use-case “контракт”

64. RUP: Анализ требований Задачи: сбор и анализ требований к системе классификация use-cases оценки затрат и рисков Модели: Use-case model

65. Vision  Vision – представляет собой общее описание проекта и является базисом для уточнения требований к системе  Содержит: Цели проекта Stakeholders & Users (описание инициаторов проекта и конечных пользователей ) Перспективы и возможности продукта Особенности Ограничения

66. Use-case model  Use-case model – модель, описывающая требования к системе в терминах вариантов использования (use-case). Создается на основе Vision и Business Analysis.  Элементы use-case model: Actor – внешнее по отношению к системе действующее лицо, роль. UML: Class со стереотипом > Use-case – вариант использования системы actor-ом UML: use-case

67. Пример: use-case model

68. Actors generalization

69. included use-cases

70. семантика >

71. extended use-cases

72. семантика >

73. use-case generalization

74. семантика generalization

75. use-case package содержит набор вариантов использования, актеров, диаграмм и других пакетов используется для структуризации use-case model UML: package со стереотипом >

76. use-case storyboard -Коллаборация, описывающая реализацию use-case с точки зрения пользовательского интерфейса UML: use-case со стереотипом >

77. SRS SRS (Software Requirements Specification) - полностью определяет требования к системе, зависит от Vision Содержит: Функциональные требования (что должна делать система, роли пользователей, фактически, описание use-cases) Нефункциональные требования (производительность, ограничения по используемым технологиям и т.д.)

78. RUP: Analysis & Design Задачи: Трансформировать требования собранные на предыдущем этапе в дизайн системы Проработать архитектуру системы Адаптировать дизайн к среде исполнения Модели: Analysis model Design model

79. Analysis model  Абстрактная модель системы, описывающая ее в терминах use-case realization. Язык реализации классов не фиксируется. Обычно не сопровождается.  Элементы analysis model: Use-case realization – реализация use-case, набор activity, state, collaboration и class диаграмм Boundary class – класс, разграничивающий actor-ов и систему Control – класс, управляющий другими классами Entity – класс, моделирующий информацию, используемую в системе

80. Boundary class -Класс, разграничивающий (под-)систему и окружение. UML: class со стереотипом > Примеры: классы пользовательского интерфейса, классы интерфейсов систем и устройств 3 представления boundary class в Rational Rose

81. Control -Класс, управляющий другими классами. Можно сказать, что control “исполняет” use-case UML: class со стереотипом > 3 представления control class в Rational Rose

82. Entity -Класс, класс, моделирующий информацию, используемую в системе UML: class со стереотипом > 3 представления entity class в Rational Rose

83. Проверка контрактов

84. Class diagram

85. Заключение контракта

86. Сlass diagram

87. Collaboration diagram

88. Ограничения на связи From\To (navigability) BoundaryEntityControl Boundaryyes avoid Entityno*yesno* Controlavoidyes * Используйте обратные связи со стереотипом “subscribe-to” Avoid – короткоживущая связь, нет необходимости моделировать (RUP)

89. Design model  М одель реализации системы. Создается на основе Analysis model. Фиксирует язык реализации классов. Сопровождается до конца разработки.  Элементы design model: Layer - слой (application, business, middle, system) Subsystem - подсистема Package - пакет Class – класс Use-case realization - коллаборация

90. Layer - пакет, включающий другие пакеты некоторого уровня абстракции. UML: package со стереотипом > Типичные уровни: Application – набор специфичных для приложения подсистем Business – подсистемы специфичные для данного типа бизнеса Middleware – подсистемы c платформно-независимыми сервисами System – интерфейсы к аппаратуре, API операционной системы и тд

91. Package -набор классов, отношений, use-case realization и других пакетов UML: package

92. SAD  SAD (Software Architecture Document) – содержит полное описание архитектуры системы  Содержит: Use-case view Logical View (архитектурно важные части Design model) Process View Deployment View Implementation View Performance issues Quality issues

93. RUP: Implementation Задачи: Структурирование системы Реализация компонент системы Артефакты: Implementation model

94. Implementation model – коллекция подсистем (subsystems) и содержащих их компонентов (components). Компоненты включают как поставляемые компоненты (deliverable components, такие как программы),так и их составляющие.