- •1.Предпосылки возникновения объектно-ориентированного подхода
- •2.Жизненный цикл программного обеспечения
- •2.1.Стандартные модели жизненного цикла
- •2.1.1.Этапы жизненного цикла
- •2.1.2.Модели жизненного цикла
- •2.2.Объектно-ориентированные модели жизненного цикла
- •2.3.Жизненный цикл uml ( Rational Objectory Process )
- •3.Концепции объектно-ориентированного подхода к разработке больших программных систем.
- •3.1.Инкапсуляция
- •3.2.Наследование
- •3.3.Полиморфизм
- •Вариант 1:
- •Вариант 2:
- •3.4.Объекты и экземпляры объектов
- •3.5.Варианты наследования
- •4.Достоинства и недостатки объектно-ориентированного подхода
- •4.1.Преимущества объектно-ориентированного подхода
- •4.2.Недостатки объектно-ориентированного подхода
- •5.Объектно-ориентированный анализ
- •Ооа состоит из пяти главных шагов:
- •5.1.Схема предметной области
- •5.2.Схема объектов
- •5.3.Схема структуры
- •5.4.Схема атрибутов
- •5.5.Схема методов
- •5.6.Контроль корректности
- •Для каждого объекта в схеме объектов:
- •Для структуры:
- •6.Объектно-ориентированное проектирование
- •6.1.Диаграмма классов
- •6.2.Категории классов
- •6.3.Шаблоны для диаграммы классов
- •6.4.Диаграмма объектов
- •6.5.Диаграмма переходов
- •7.Универсальный язык моделирования ( Unified Modeling Language uml )
- •7.1.Пакеты, как средство работы с большими проектами
- •7.2.Диаграммы классов и объектов
- •7.2.1.Классы
- •7.2.2.Интерфейсы
- •7.2.3.Отношения между классами Двухместная связь ( Binary Association )
- •Класс, описывающий связь
- •Композиция, Сборка.
- •Обобщение
- •Зависимость ( Dependency )
- •7.2.4.Пример диаграммы классов
- •7.3.Диаграммы использования
- •Диаграмма состоит из следующих элементов:
- •Выделены следующие виды связей:
- •7.4.Диаграммы последовательностей
- •7.5.Диаграммы сотрудничества
- •7.6.Диаграммы состояний
- •7.6.1.Состояния
- •7.6.2.События
- •7.6.3.Простые переходы между состояниями
- •7.6.4.Составные переходы между состояниями
- •7.6.5.Вложенные автоматы
- •7.7.Диаграммы действий
- •7.7.5.Отношения между действиями и объектами
- •7.7.6.Специальные символы
- •7.8.Диаграммы реализации
- •7.8.1.Диаграммы компонентов
- •7.8.2.Диаграммы развертывания
- •8.Стиль разработки объектно-ориентированных проектов
- •8.1.Общие правила оформления классов
- •8.1.1.Составление атрибутов
- •8.1.2.Необходимое и достаточное количество свойств
- •8.1.3.Конструкторы
- •8.1.4.Независимость от системных библиотек и реализации
- •8.2.Наследование
- •8.2.1.Наследование атрибутов
- •8.2.2.Наследование методов поведения
- •8.3.Необходимые и достаточные свойства классов
- •8.4.Наследование и использование
- •9.Инструментальные средства объектно-ориентированной разработки программных систем
- •9.1.Обзор объектно-ориентированных инструментальных средств
- •9.2.Объектно-ориентированное case средство Rational Rose
- •9.2.1.Принципы разработки программных систем в Rational Rose
- •9.2.2.Проектирование программных средств
- •9.2.3.Построение и сопровождение системы
- •9.2.4.Поддержка этапов разработки
- •9.2.5.Достоинства и недостатки Rational Rose
- •10.Тестирование объектно-ориентированных программных систем
- •10.1.Особенности тестирования объектно-ориентированных программных систем
- •10.2.Методы тестирования объектно-ориентированных систем
3.1.Инкапсуляция
Одним из источников ошибок в процедурных языках программирования является передача неправильных параметров в подпрограммы. При передаче параметров в подпрограмму компилятор может проконтролировать синтаксическую совместимость типов, но не семантику. Например, подпрограмма имеет параметр типа “целое число”, который обозначает температуру воды, но в качестве фактического значения в нее можно передать любое целое число, например, 10000, которое не может являться температурой воды. Отследить такого рода ошибки очень не просто, особенно если учесть, что семантическая ошибка может быть намного тоньше и может не контролироваться простым попаданием числа в заданный диапазон. Уменьшение вероятности таких ошибок состоит в синтаксическом связывании данных с действиями. Имеются в виду данные, которые передаются в качестве фактических параметров в подпрограммы. Так появилось понятие абстрактного типа данных, реализованное например в языке Ада.
Инкапсуляция возникла как логическое продолжение идеи абстрактных типов данных, в которой каждый тип имеет некоторую, иногда недоступную извне внутреннюю структуру и набор всегда доступных операций над переменными данного типами. Т.е. в отличие от обычных подходов к типам ( например, в Pascal ), когда тип полностью определяется только структурой хранения информации, абстрактный тип дополнительно определяется набором операций. Достоинство такого подхода состоит в исключении ошибок, состоящих в применении операций, недопустимых для типа данных, большей универсальности, когда можно менять внутреннюю структуру хранения данных без необходимости изменения других частей системы.
Рассмотрим эти особенности на следующем примере. Пусть разрабатывается библиотека подпрограмм для работы с матрицами. Пусть выбрано хранение в виде двумерного массива. При необходимости перехода к разреженному хранению придется изменять любое определение данных для обращения к библиотеке. Если же матрица определена как абстрактный тип данных с операциями: “получить значение элемента”, “изменить значение элемента” и т.п., то изменение метода хранения матрицы не скажется на других частях программы. В программе не описываются переменные типа “array [1..10 ] of integer” и нет прямых обращений к элементам массива вида “A[i]”.
Объект, обладающий свойством инкапсуляции характеризуется следующими параметрами:
уникальное имя,
набор атрибутов - данных, характеризующих состояние объекта,
набор действий (методов) для смены своих состояний, т.е. для описания своего поведения.
Рассмотрим характерное описание объекта:
объект:
точка
атрибуты:
позиция на плоскости
методы:
создать
удалить
переместить в новую позицию
отобразить
стереть
объект:
прибор
атрибуты:
показания
методы:
снять показания
Каждый объект, заданный именем, атрибутами и методами представляет собой замкнутую сущность, однозначно определенную для постороннего наблюдателя. Принципиальная особенность такого объекта состоит в том, что он может делать только то, что определено в качестве его методов и все, что определено в качестве методов объекта, объект выполняет самостоятельно. Мы не говорим "переместить (объект)", а говорим "объект переместись". Это обеспечивает все свойства абстрактного типа данных.
