Процесс разработки 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 Диаграммы пакетов Package – пакет. Общий механизм организации элементов модели в группы Имеет имя Определяет пространство имен Может быть импортирован другим пакетом

30 Package

31 Package diagram

32

33 package: service

34 package: service::local

35 package: service::server

36 package: service::agent

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

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

39 sequence diagram

40 collaboration diagram

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

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

43 component diagram

44 servers

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

46 deployment diagram

47 Rational Unified Process

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

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

50 business use-case model

51 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

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

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

54 activity diagram для use-case realization контракт

55 class diagram для use-case realization контракт

56 Collaboration diagram для use-case контракт

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

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

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

60 Пример: use-case model

61 Actors generalization

62 included use-cases

63 семантика >

64 extended use-cases

65 семантика >

66 use-case generalization

67 семантика generalization

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

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

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

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

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

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

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

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

76 Проверка контрактов

77 Class diagram

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

79 Сlass diagram

80 Collaboration diagram

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

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

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

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

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

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

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