Объектноориентированное проектирование Анализ и проектирование
 Скачать 383.57 Kb.
|
|
Объектно-ориентированное проектирование ● Анализ и проектирование ● Основы ООП ● Проектирование на UML Итерация разработки ПО Непосредственное программирование или написание кода начинается далеко не сразу: Дизайн Постановка задачи Анализ Модель Метод Проектирование Реализация Отладка и тестирование Внедрение Сопровождение Модификация Постановка задачи Анализ Модель Метод Проектирование Реализация Отладка и тестирование Внедрение Сопровождение Модификация Анализ требований Анализ требований включает три типа деятельности: ● Сбор требований: общение с клиентами и пользователями, чтобы определить, каковы их требования. ● Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем. ● Документирование требований: Требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов. Обзор принципов объектного подхода Предметная область делится на составляющие элементы: ● Алгоритмическая декомпозиция (основные элементы программы – строительные блоки – алгоритмы). ● Объектная декомпозиция (основные элементы программы – виды абстракций (классы) и представители этих классов (объекты)). Объектный подход: ● OOA (object oriented analysis) – объектно-ориентированный анализ. ● OOD (object oriented design) – объектно-ориентированное проектирование. ● OOP (object oriented programming) – объектно-ориентированное программирование. Обзор принципов объектного подхода Объектно-ориентированный анализ — это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области. Объектно-ориентированное проектирование — это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы. Объектно-ориентированное программирование — это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования. Принципы объектного подхода Абстрагирование применяется при решении многих задач. Любая построенная нами модель позволяет абстрагироваться от реального объекта, подменяя его изучение исследованием формальной модели. Абстрагирование в ООП позволяет выделить основные элементы предметной области, обладающие одинаковой структурой и поведением. Такое разбиение на классы позволяет существенно облегчить анализ и проектирование системы. Инкапсуляция – важнейший элемент объектного подхода. Суть его заключается в скрытии деталей внутренней реализации. Инкапсуляция оказывает положительное влияние на защиту данных и существенно повышает шансы безболезненной замены одной из частей системы ее новой версией при условии сохранения интерфейса. Иерархия помогает разбить задачу на уровни и постепенно ее решать, постепенно увеличивая детализацию рассмотрения. Иерархия упорядочивает абстракции. К счастью, разные иерархии можно обнаружить практически в любой системе. Агрегация и Наследование – примеры таких иерархий. Они подчеркивают тот факт, что новые абстракции могут быть созданы на основе уже имеющихся. Полиморфизм позволяет иметь естественные имена и выполнять действия, релевантные ситуации, разбираясь на этапе работы программы, какой из методов необходимо вызвать. Полиморфизм неразрывно связан с наследованием и поздним связыванием. Повторное использование Повторное использование – применение уже существующих наработок в разрабатываемом ПО. Девиз: не надо изобретать велосипед, если он уже изобретен. Достоинства повторного использования: ● Повышение надежности. ● Уменьшение проектных рисков. ● Эффективное использование специалистов. ● Соблюдение стандартов (пример: пользовательский интерфейс). ● Ускорение разработки. Повторное использование Повторное использование достигается за счет следующих приемов (видов использования): ● Компонентная разработка. Часть компонентов уже разработаны ранее, имеют четко описанный интерфейс. Они используются в качестве «кирпичиков» в новой системе. ● Использование паттернов (шаблонов) проектирования. Применяются известные подходы к решению некоторых встречавшихся ранее проблем. ● Использование стандартных прикладных и системных (API) библиотек. Визуальное моделирование Проекты не укладываются в сроки, бюджет, не удовлетворяют требованиям. Как решать эту проблему? На помощь приходит моделирование. Под моделью обычно понимают упрощенное представление объектов и явлений реального мира. Ответим на вопрос, зачем строят модели? Модели строят для того, чтобы лучше понять исследуемую систему. Визуальное моделирование Задачи моделирования: ● Визуализация системы в ее некотором состоянии. ● Определение структуры и поведения системы. ● Получение шаблона для создания системы. ● Документирование принятых решений. Принципы моделирования: ● Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение. ● Каждая модель может быть воплощена с разной степенью абстракции. ● Лучшие модели – те, что ближе к реальности. ● Наилучший подход при разработке сложной системы – использовать несколько почти независимых моделей. Визуальное моделирование Идея визуального моделирования состоит в графическом отображении обсуждаемых и принимаемых проектных решений. При этом достигаются следующие цели: ● Визуализация упрощает понимание проекта в целом. ● Визуализация помогает согласовать терминологию и убедиться, что все одинаково понимают термины. ● Визуализация делает обсуждение конструктивным и понятным. Для визуального моделирования нужна специальная нотация или язык. UML (unified modeling language) – это язык для визуализации, специфицирования, конструирования, документирования элементов программных систем. UML – язык общего назначения, предназначенный для объектного моделирования. Модели UML ● Модель функционирования (показывает, как описывается функциональность системы с точки зрения пользователя). ● Объектная модель (показывает,как выглядит проект системы с точки зрения объектного подхода). ● Динамическая модель(показывает, как взаимодействуют друг с другом компоненты системы в динамике, с течением времени). Демонстрирует, какие процессы происходят в системе. Диаграммы UML UML 2.0 содержит 13 типов диаграмм. В том числе: ● Структурные диаграммы (6). ● Диаграммы поведения (3). ● Диаграммы взаимодействия (4). Диаграммы UML Структурные диаграммы: ● Диаграмма классов – показывает классы, их атрибуты и связи между классами. ● Диаграмма компонентов – показывает компоненты и связи между ними. ● Структурная диаграмма – показывает внутреннюю структуру классов и связи с внешним миром. ● Диаграмма развертывания - показывает, как ПО размещается на аппаратуре (серверах, рабочих станциях...). ● Диаграмма объектов – показывает структуру системы в конкретный момент времени, объекты, их атрибуты... ● Диаграмма пакетов – показывает, как система раскладывается на крупные составные части и связи между этими частями Диаграммы UML Диаграммы поведения: ● Диаграмма действия – показывает потоки информации в системе. ● Диаграмма состояния – представляет собой конечный автомат, показывающий функционирование системы. ● Диаграмма вариантов использования – показывает работу системы с точки зрения пользователей. Диаграммы UML Диаграммы взаимодействия ● Диаграмма кооперации – показывает структурную организацию участвующих во взаимодействии объектов. ● Диаграмма взаимодействия (новация UML 2.0). ● Диаграмма последовательности – показывает временную упорядоченность событий. ● Временная диаграмма – диаграмма связана с временными рамками проекта. Понятия UML Для описания структуры: Актер, Атрибут, Класс, Компонент, Интерфейс, Объект, Пакет. Для описания поведения: Действие, Событие, Сообщение, Метод, Операция, Состояние, Вариант использования. Для описания связей: Агрегация, Ассоциация, Композиция, Зависимость, Наследование. Некоторые другие понятия: Стереотип, Множественность, Роль Актеры и варианты использования в UML Программная система не функционирует сама по себе. Программная система функционирует под воздействием актеров (Actor) – пользователей, машин и других программ. Актер в UML – человек, машина или программа, воздействует на систему, является внешним по отношению к ней. Модель того, как воздействие приводит к результату, называется Вариантом использования (Use case). Актеры и варианты использования в UML Актеры и варианты использования общаются посредством посылки сообщений. Сообщения могут идти в обе стороны. Стрелка показывает инициатора общения (актер на рисунке) и может быть опущена. Актеры и варианты использования в UML ● При таком моделировании обращают внимание на поведение системы, а не на ее реализацию. ● Хорошая модель описывает основное поведение системы, не являясь слишком подробным. ● Подобная модель позволяет проверить, удовлетворит ли система требования заказчика. ● Система средних размеров может быть описана большим количеством вариантов использования. ● Варианты использования могут описываться разными сценариями. Диаграммы действий Диаграмма действия это блок-схема, которая отображает динамику в поведении системы. Эта диаграмма может использоваться не только для описания сценариев Варианта использования. Подобрать рейс Бронировать билеты Выдать сообщение о недостаточной цене Выдать сообщение об отсутствии пути Рейс не подобран Рейс подобран Путь не существует Путь существует Структура системы и ее описание средствами UML TSomeClass +Method1() : bool -Method2(inout a : int) : void #Method3() : int +Value1 : float #Value2 : long -Value3 : int TSomeClass TSomeClass Класс Абстрактный класс Поля Методы Структура системы и ее описание средствами UML +Put(in Elem : ElemType) : bool TStack ElemType Шаблоны классов Объекты +Method1() : bool -Method2(inout a : int) : void #Method3() : int +Value1 : float #Value2 : long -Value3 : int TSomeClass : TSomeClass SomeObject : TSomeClass Класс Безымянный объект Именованный объект Интерфейсы Интерфейс определяет границу между спецификацией того, что делает абстракция, и реализацией того, как она это делает. Интерфейс – это набор операций, используемых для специфицирования услуг, предоставляемых классом или компонентом. #isAirportExist(int NumberAirport)() : bool +getPointAllAirport()() : * +getFlights(int NumberAirport)() : +armoringTicket(TRouteFlight* pRouteFlight)() : int +addAirport (int NumberAirport, string nameAirport)() : int +addFlight (string name, int NumberFlight, int price, int startAirport, int finishAirport)() : int +removeFlight (int NumberAirport, int NumberFlight)() : int +removeAirport (int NumberAirport)() : int #AllAirpor_data #pIGetNewAirport : * «implementation class» TDataAccess #isAirportExist(int NumberAirport)() : bool +getPointAllAirport()() : * +getFlights(int NumberAirport)() : +armoringTicket(TRouteFlight* pRouteFlight)() : int +addAirport (int NumberAirport, string nameAirport)() : int +addFlight (string name, int NumberFlight, int price, int startAirport, int finishAirport)() : int +removeFlight (int NumberAirport, int NumberFlight)() : int +removeAirport (int NumberAirport)() : int #AllAirpor_data #pIGetNewAirport : * «implementation class» TDataAccess «interface»IDataAccess IDataAccess Пакеты Пакет – структурная единица для группировки элементов модели, в частности, классов. Пакет – это способ организации элементов модели в более крупные блоки, которыми впоследствии позволяется манипулировать как единым целым. Хорошо спроектированный пакет группирует семантически близкие элементы, которые имеют тенденцию изменяться совместно. Классы документов Подсистемы На этапе проектирования системы классы и пакеты могут объединяться в подсистемы. Подсистема – структурная единица. Каждая подсистема имеют свою область ответственности и реализует некоторую функциональность. Подсистема реализует Интерфейс, который описывает ее поведение. Компоненты Компонент – физическая заменяемая часть системы, совместимая с одним набором интерфейсов и обеспечивающая реализацию какого-либо другого. Компонент может разрабатываться и тестироваться независимо от системы. Отношения между элементами модели UML поддерживает следующие виды отношений между элементами модели: ● Зависимость. ● Ассоциация. ● Обобщение (наследование). ● Реализация (для Интерфейса). Отношения показывают наличие связей между элементами модели и семантику этих связей. Зависимость Зависимость – связь между сущностями (классами, объектами). Зависимость показывает, что изменения в одной сущности могут повлиять на другую сущность. Зависимость – не структурная связь. Возникает через локальную, глобальную переменные или параметр метода. TFirst TSecond Ассоциация Ассоциация – связь между сущностями (классами, объектами). Ассоциация показывает наличие структурной связи между экземплярами (объектами). Структурная связь реализуется через поле класса. В обозначениях UML направление может быть не указано (двусторонняя связь) TFirst TSecond Кратность Кратность – способ конкретизации характера отношения. Показывает тип отношения 1:1, 1:M, N:1, N:M. Частные случаи ассоциаций: агрегация и композиция Агрегация предполагает, что 0 или более объектов одного типа включены в 1 или более объектов другого типа. Композиция – вариант агрегации, в котором каждый объект второго типа может быть включен ровно в 1 объект первого типа. Композиция Агрегация Обобщение (наследование) TFirst и TSecond выведены из TSomeClass Диаграммы последовательности ? Вопросы ? |