'

Объектно-Ориентированный Анализ и Дизайн

Понравилась презентация – покажи это...





Слайд 0

Объектно-Ориентированный Анализ и Дизайн Copyright © Мухортов В. В., Няньчук-Татарский Н. А., 2001-2005 Copyright © ООО «Интекс», 2003-2005


Слайд 1

Контакты Мигинский Денис Сергеевич ooad@bionet.nsc.ru http://ccfit.nsu.ru/~shadow/OOAD


Слайд 2

Цели курса Навык работы в формальном процессе разработки Изучение моделирования программных систем с использованием UML и CASE-средств Научить применению стандартных шаблонов проектирования (design patterns) Пройти полный путь от постановки задачи, через анализ и проектирование, до реализации программной системы


Слайд 3

Анализ требований и системный анализ UML – унифицированный язык моделирования Проектная модель, модель реализации и размещения Архитектурные шаблоны Принципы и метрики проектирования Шаблоны проектирования Процесс разработки и роли участников Объектно-Ориентированный Анализ и Дизайн Программа курса:


Слайд 4

«Идеальный архитектор должен быть писателем, математиком, знать историю, быть знатоком философии, понимать музыку, обладать знаниями в области медицины, юриспруденции и астрономии» Витрувий, 25 г до н.э. “Работа архитектора это серии суб-оптимальных решений, сделанных под давлением в обстановке неуверенности и нехватки информации”. Rational Unified Process Ожидаемый результат Архитектор / System Architect


Слайд 5

Задача: автоматизация физ. эксперимента Пропускная способность Отказоустойчивость Корректность Соответствие требованиям эксперимента Высокая скорость обработки данных Большой объем хранимых данных ~ 10-100 Мб/сек ~ 100-1000 Тб


Слайд 6

Задача: автоматизация предприятия Высокая композиционная сложность Наличие большого количества ролей и разветвляющихся процессов Необходимость интеграции с существующими системами Постоянно изменяющиеся требования связанные с развитием организации и оптимизацией процессов Интеграция решений задач Финансовых АСУ Планирования Управления персоналом


Слайд 7

«Самолет представляет собой совокупность вещей, каждая из которых по отдельности стремится упасть на землю, но вместе, во взаимодействии, они преодолевают эту тенденцию» Таким образом, современным ИС присущи как функциональная так и композиционная сложность. Основными способами преодоления сложности являются декомпозиция и моделирование Структурное проектирование и алгоритмическая декомпозиция Проектирование на основе потоков данных Объектно-ориентированное проектирование и объектная декомпозиция …


Слайд 8

Парадигмы программирования (наиболее распространенные) Процедурное программирования Структурное программирование Объектно-ориентированное программирование Аспектно-ориентированное программирование? …


Слайд 9

Объектно-ориентированный подход: основные положения Программная система состоит из объектов, которые обмениваются сообщениями Каждый объект обладает: Поведением Состоянием Индивидуальностью Схожие объекты объединяются в классы


Слайд 10

Объектно-ориентированный подход: основные положения Абстрагирование Инкапсуляция Иерархия Модульность Полиморфизм


Слайд 11

Объектно-ориентированный подход (доп. положения) Типизация Параллелизм Сохраняемость


Слайд 12

Отношения между классами Зависимость Dependency Ассоциация Association Агрегация Aggregation Композиция Composition Генерализация Generalization Реализация Realization


Слайд 13

Dependency Отношение зависимости Обладает ролью и множественностью Server зависит от Query, так как использует этот класс в качестве параметра метода Server также зависит от ResultSet, поскольку возвращает значение этого типа


Слайд 14

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


Слайд 15

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


Слайд 16

Aggregation Агрегация – отношение часть-целое


Слайд 17

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


Слайд 18

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


Слайд 19

Realization Реализация – отношение выполнения соглашения Треугольник и квадрат реализуют алгоритм вращения, специфицированный абстрактной сущностью «Фигура»


Слайд 20

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


Слайд 21

Методологии разработки ПО OMT - Object Modeling Technique (Rumbaugh) RDD - Responsibility Driven Design (Beck, Cunningham, Wirfs-Brock) Objectory (Rational Software) RUP (Booch, Rumbaugh, Jacobson) XP (Beck, Cunningham, Martin, Fowler, Cockburn)


Слайд 22

Составные части процесса разработки ПО Может быть эффективен при наличии общих концепций и единой методологии лежащей в основе всех составляющих процесса.


Слайд 23

Анализ требований и предметной области Уточнение и формализация предметной области Определение рамок задачи Формализация требований, анализ их непротиворечивости, полноты и выполнимости Оценка трудозатрат и рисков


Слайд 24

Системный анализ Определение общей логики работы системы Выбор технических средств Планирование работ (Исследования, прототипирование, …)


Слайд 25

Проектирование и реализация Создание программной системы (кода) удовлетворяющей требованиям Адаптация к дальнейшему развитию (гибкость, расширяемость, адаптивность и т.д.)


Слайд 26

Сопровождение и развитие Повышение качества системы Расширение функциональности Создание технологической базы для других продуктов


Слайд 27

Способы описания программных систем CRC-карты (Class-Responsibilities-Collaborators) UML (Unified Modeling Language)


Слайд 28

CRC-карты


Слайд 29

Unified Modeling Language Язык моделирования Определяет нотацию и ее семантику Не является языком программирования, но имеет встроенный язык программирования для задания поведения и ограничений Обладает возможностью к расширению стандартной семантики


Слайд 30

Case-средства для UML IBM Rational Rose IBM Rational Architect/Modeler Jude Visual Architect (Sparx Systems) MetaMill ArgoUML (Tigris) Poseidon (Metaware)


×

HTML:





Ссылка: