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

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

39

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, такие как программы),так и их составляющие.