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

Контакты Мигинский Денис Сергеевич

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Методологии разработки ПО 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)

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

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

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

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

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

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

CRC-карты Класс Student Ответственность Учиться Сдать экзамены Коллаборанты Teacher

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

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