1 / 94

Процесс разработки

Процесс разработки. “Design and programming are human activities. Forget it and all is lost.” B.Stroustrup, 1991. Фазы процесса. Начало Уточнение Разработка Развитие. Методы. OMT ( Object Modeling Technique, Rumbaugh ) RDD (Responsibility Driven Design) Objectory

tessa
Download Presentation

Процесс разработки

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 - карточки

  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: <<include>> • Различные use-cases могут иметьобщие части • abstract use-caseне активируется actor-ами

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

  14. Расширение use-cases Stereotype: <<extend>> Некоторые 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 – базовый класс, задающий только поведение, имеет стереотип <<interface>> • Abstract class – базовый класс, не имеющий экземпляров • Parameterized class – параметризованный класс, шаблон • Instantiated class – депараметризованный шаблон

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

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

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

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

  27. Методы(операции) • Method (operation) – метод • Class method – метод класса (static) • Export control – public, protected, private • Syntax: <stereotype> name(<parameters>) : <return type> • 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. 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

More Related