Похожие презентации:
Информационные технологии
1. Информационные технологии
Методология ООАППоявление UML
Диаграмма Use Case
2. Сложные системы
Дейкстра:"Способ управления сложными
системами был известен еще в
древности - divide et impera
(разделяй и властвуй)"
3. Объектно Ориентированный Подход
Предшествует модульноепрограммирование, ключевым
элементом которого является
алгоритм
Выделение секции Interface
модулях
Событийно-управляемый поток
выполнения программы
4. Объектно Ориентированный Подход
Под классом понимают некоторуюабстракцию совокупности
объектов, которые имеют общий
набор свойств и обладают
одинаковым поведением
5. Объектно Ориентированный Подход
НаследованиеИнкапсуляция
Полиморфизм
6. ООП Наследование
В качестве наиболееобщего понятия или
категории берется
понятие, имеющее
наибольший объем
и, соответственно,
наименьшее
содержание
7. ООП Инкапсуляция
сокрытие отдельныхдеталей
внутреннего
устройства классов
от внешних по
отношению к нему
объектов или
пользователей
8. ООП Полиморфизм
свойство некоторых_Фигура_
объектов принимать
Цвет
Нарисовать()
различные внешние
формы в
зависимости от
Прямоугольни
обстоятельств
к
Треугольник
Нарисовать()
Нарисовать()
Овал
Нарисовать
()
9. ООП Полиморфизм
Бьёрн Страуструпопределил полиморфизм
как «один интерфейс —
много реализаций»
Или способность обьекта
использовать методы
производного класса
10. Преимущества ООП
Распараллеливание работУпрощение внесения изменений
Гибкая архитектура и переносимость
Повторное использование
программных компонентов
Естественность описания
Появление средств быстрой
разработки (RAD)
11. Недостатки ООП
Обращение к методу занимает в1,75-2,5 раза больше времени, чем к
обычной подпрограмме
Медленность защищенных свойств
Динамическое создание и удаление
объектов
12. ООП
Процесс написания программного кодаможет быть отделен от процесса
проектирования структуры
Появление специальной методологии,
получившей название методологии
«объектно-ориентированный анализ
и проектирование» (ООАП)
13. ООA/П
Наиболее важным моментом ООАПявляется распределение
обязанностей между программными
компонентами
Анализ – выявление требований, но не
их путей решения
Проектирование – концептуальное
решение, обеспечивающее
выполнение требований
14. ООA/П
ООА/П – это выявление правильныхдействий и обеспечение их
правильности
15. ЖЦ программы
1.ООАП
2.
3.
RAD
4.
5.
6.
Анализ предметной области и
формулировки требований к программе
Проектирование структуры программы
Реализация программы в кодах
(собственно программирования)
Внедрение программы
Сопровождение программы
Отказ от использования программы
16. UML
Какой язык для ООАП?17. Основные этапы развития UML
В период между 1989-1994 гг. общеечисло наиболее известных языков
моделирования возросло с 10 до
более чем 50
18. Основные этапы развития UML
Метод Гради Буча (Grady Booch),получивший условное название Booch или
Booch'91, Booch Lite (позже - Booch'93).
Метод Джеймса Румбаха (James
Rumbaugh), получивший название Object
Modeling Technique - ОМТ (позже - ОМТ-2).
Метод Айвара Джекобсона (Ivar Jacobson),
получивший название Object-Oriented
Software Engineering - OOSE.
19. Требования к языку UML
Требования к языкуПозволять моделировать не только программное
обеспечение, но и более широкие классы систем и
бизнес-приложений, с использованием объектноориентированных понятий.
Явным образом обеспечивать взаимосвязь между
базовыми понятиями для моделей концептуального
и физического уровней.
Обеспечивать масштабируемость моделей, что
является важной особенностью сложных
многоцелевых систем.
Быть понятен аналитикам и программистам, а также
должен поддерживаться специальными
инструментальными средствами, реализованными
на различных компьютерных платформах
20. Основные этапы развития UML
21. Основные этапы развития UML
22. Основные этапы развития UML
23. Основные этапы развития UML
24. UML
Унифицированный язык моделирования(UML) – это семейство графических
нотаций, в основе которого лежит
единая метамодель.
Он помогает в описании и проектировании
программных систем, в особенности
систем, построенных с использованием
объектно-ориентированных (ОО)
технологий.
М.Фаулер
25. Назначение языка UML
легко воспринимаемый и выразительный язык визуальногомоделирования, специально предназначенный для разработки
и документирования моделей сложных систем .
Снабдить исходные понятия языка UML возможностью
расширения
независимость от конкретных языков программирования и
инструментальных средств
включать в себя семантический базис для понимания общих
особенностей ООАП.
Поощрять развитие рынка объектных инструментальных
средств.
Способствовать распространению объектных технологий и
соответствующих понятий ООАП.
Интегрировать в себя новейшие и наилучшие достижения
практики ООАП.
26. UML
Три режима использования языкаразработчиками:
Эскиз
Проектирование
Программирования
27. UML
Граница между моделями и эскизамидовольно размыта, но различия
остаются в том, что эскизы сознательно
выполняются неполными, подчеркивая
важную информацию, в то время как
модели нацелены на полноту
28. UML
Язык UML в своем нынешнем состоянииопределяет нотацию и метамодель.
Нотация представляет собой
совокупность графических элементов,
которые применяются в моделях.
Большинство графических языков
моделирования являются отнюдь
не строгими; их нотация в большей
степени апеллирует к интуиции,
чем к формальному определению
29. UML
Насколько велико влияние метамодели натого, кто применяет соответствующую
нотацию при моделировании?
Создателя эскизов обычно это не
слишком волнует;
проектировщика это должно беспокоить
значительно больше.
И это жизнено важно для тех, кто
использует UML в качестве языка
программирования
30. UML это:
UML это:Язык
Язык визуализации
Язык специфицирования
Язык конструировнания
Язык документирования
31. Где используется UML ?
Информационные системы масштабапредприятия;
Банковские и финансовые услуги;
Телекоммуникации;
Транспорт;
Оборонная промышленность, авиация и
космонавтика;
розничная торговля;
медицинская электроника;
наука;
распределенные Web-системы.
32. Концептуальная модель UML
Основные строительные блоки языка,правила их сочетания
и некоторые общие для всего языка
механизмы
33. Концептуальная модель UML
Строительныеблоки
Сущности
1.
2.
3.
4.
Правила
сочетания
Определяют:
Отношения
Структурные
Поведенческие 1.
Группирующие 2.
Аннотационные 3.
4.
Зависимость
Ассоциация
Обобщение
Реализация
•имена;
•область действия;
•видимость;
•целостность;
•выполнение.
Структурные
•Класс
•Интерфейс
•Кооперация
•Прецедент
•Активный класс
•Компонент
•Узел
Диаграммы
1.
2.
3.
4.
5.
6.
Поведенческие 7.
8.
•Взаимодействие
•Автомат
Механизмы
классов;
прецедентов;
последовательностей;
кооперации;
состояний;
действий;
компонентов;
развертывания
•спецификации;
•дополнения;
•принятые деления;
•механизмы расширения
34. Концептуальная модель UML
35. Диаграммы UML
1.2.
3.
Диаграмма вариантов использования
(use case diagram)
Диаграмма классов (class diagram)
Диаграммы поведения
(behavior diagrams)
1.
2.
3.
Диаграмма состояний (statechart diagram)
Диаграмма деятельности (activity diagram)
Диаграммы взаимодействия
(interaction diagrams)
1.
2.
4.
5.
Динамические
Диаграмма последовательности
(sequence diagram)
Диаграмма кооперации (collaboration diagram)
Диаграммы реализации
1.
Статические
Диаграмма компонентов
Диаграмма развертывания
Статические
36. Правила построения диаграмм UML
Каждая диаграмма должна служитьзаконченным представлением
Все сущности на диаграмме модели
должны быть одного концептуального
уровня
Вся информация о сущностях должна
быть явно представлена на
диаграммах
Диаграммы не должны содержать
противоречивой информации
37. Правила построения диаграмм UML
Диаграммы не следует перегружатьтекстовой информацией
Количество типов диаграмм для
конкретной модели приложения не
является строго фиксированным
38. Цели диаграмм прецедентов
Определить общие границы и контекстмоделируемой предметной области на начальных
этапах проектирования системы.
Сформулировать общие требования к
функциональному поведению проектируемой
системы.
Разработать исходную концептуальную модель
системы для ее последующей детализации в форме
логических и физических моделей.
Подготовить исходную документацию для
взаимодействия разработчиков системы с ее
заказчиками и пользователями.
39. Диаграммы прецедентов
АктерActor
(from Use Case View)
Прецедент (вариант
использования, use case)
UseCase
40. Актер
Актер – любая сущность,взаимодействующая с
системой извне
Actor
(from Use Case View)
41. Актер
ОсобенностиАктер – это роль
Может не быть реального человека
Один человек может играть несколько
ролей
Легче пересчитать актеров...
События могут выступать актерами..
42. Вариант использования
Вариант использования –сервисы или некоторый
набор действий, которые
система предоставляет
актеру
UseCase
43. Вариант использования
Прецедент – это набор сценариев,которые представляют собой
последовательность действий,
выполняемых конкретной системой
для достижения ощутимого
результата для конкретного
исполнителя.
44. Вариант использования
Сценарий – это специальнаяпоследовательность действий или
взаимодействий между
исполнителями и системой
45. Вариант использования
Сервис представляет собойзаконченную последовательность
действий.
После того как система закончит
обработку запроса пользователя, она
должна возвратиться в исходное
состояние
46. Вариант использования
Варианты использования могутприменяться как для спецификации
внешних требований к проектируемой
системе,
так и для спецификации
функционального поведения уже
существующей системы
47. Вариант использования
Имя прецедентапростое «Разместить заказ»
составное «Датчики:: откалибровать
положение»
48. Вариант использования
Сценарий или примечание –пояснительный текст, который
раскрывает смысл или семантику
составляющих диаграмму
компонентов.
49. Вариант использования
ОсобенностиUse Case – требование к системе
Нет необходимости рисовать
10 человеко-лет – 12 – 100 вариантов
использования
50.
Типы отношенийОтношение зависимости (dependency
relationship)
Отношение ассоциации (association
relationship)
Отношение обобщения (generalization
relationship)
51. Отношения прецедентов
ассоциации1..10
*
(association relationship)
расширения
«extend»
(extend relationship)
обобщения
(generalization relationship)
включения
«include»
(include relationship)
52. Отношения ассоциации
общие свойства вариантовиспользования могут быть
представлены тремя различными
способами, а именно с помощью
отношений расширения, обобщения
и включения
Прецедент А
Прецедент Б
53. Отношения ассоциации
определяет семантические (смысловые)особенности взаимодействия актеров
54. Отношения ассоциации
Кратность (multiplity)количество конкретных экземпляров
данного компонента, которые могут
выступать в качестве элементов данной
ассоциации
1 (включая 0)
1..8
2..*
* = 0..*
55. Отношения расширения
свойства варианта использования Вмогут быть дополнены свойствами
расширенного варианта
использования А
«extend»
В
«extend»
А
56. Отношения расширения
Отношение включает в себя некотороеусловие и ссылки на точки
расширения в базовом варианте
использования
условие отношения расширения
проверяется лишь один раз - при
первой ссылке на точку расширения
«extend»
57. Отношения расширения
«extend»вариант использования может быть
расширением нескольких других ВИ
А
В
С
D
содержать несколько расширений
58. Отношения расширения
«extend»59. Отношения обобщения
служит для указания, что некоторыйпрецедент А может быть обобщен до
прецедент В.
А – потомок В
В – предок А
60. Отношения обобщения
дочерние прецеденты обладают всемисвойствами предков
может быть несколько дочерних
может быть несколько родителей
(множественное наследование)
61. Отношения обобщения
отношение обобщения может возникатьмежду актерами
62. Отношения включения
поведение одного прецедентавключается в качестве составного
компонента в последовательность
поведения другого прецедента
«include»
63. Отношения включения
Оформить заказзаполнить «корзину»
внести данные покупателя
выписать счет
64. Пример прецедентов
Один вариант использования можетбыть включен в несколько других
вариантов, а также включать в себя
другие варианты
65. Пример прецедентов
Оформить заказ1
«включ.»
Обеспечить
информацией
условия
оплаты
Запросить
товар со склада
Оформить
заказ на покупку
товара
Продавец
Предоставить
каталог
1
Покупатель
Оформить
заказ