- •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.Методы тестирования объектно-ориентированных систем
8.1.2.Необходимое и достаточное количество свойств
Каждый класс должен содержать необходимое и достаточное количество свойств ( атрибутов и методов поведения ). Нужно избегать слишком слабого или слишком детального определения классов. Наиболее типичный класс должен включать не более 10 атрибутов и не более 10 методов поведения. При превышении этого количества стоит подумать о создании нового класса. Недостаточное количество свойств приведет к необходимости добавления их во всех производных класса, что замедлит повторное использование класса. Избыточность свойств приведет к тяжеловесности программы при выполнении и чтении.
8.1.3.Конструкторы
Каждый класс должен иметь конструктор, который в свою очередь должен инициализировать все атрибуты, даже если для конкретной задачи известно, что после конструктора всегда вызывается другой метод, устанавливающие новые значения атрибутов. Это устранит ошибки неправильной инициализации полей на весь жизненный цикл класса.
Конструктор всегда должен инициализировать только собственные атрибуты и не должен инициализировать наследуемые атрибуты. Для инициализации наследуемых атрибутов должен быть вызван конструктор базового класса. Даже если необходимо переопределить начальные значения одного или нескольких атрибутов базового класса, то сначала вызывается его конструктор, а затем значения атрибутов изменяются. Такой подход обеспечит легкую модификацию свойств базового класса, без необходимости просматривать реализацию методов всех производных классов.
8.1.4.Независимость от системных библиотек и реализации
Базовые классы не должны использовать операции ввода или вывода. Это связано с тем, что базовые классы часто будут использоваться, а это в свою очередь приводит к выводу о том, что данные для них часто будут формироваться с помощью других программ, а не вводиться пользователем. Если в методе “вставить” для хэш-таблицы будет использоваться ввод с клавиатуры для получения значения ключа, то такую таблицу невозможно будет использовать в компиляторе. Аналогичная ситуация сложится, если этот же метод после вставки выдаст на экран сообщение вида “вставка успешно завершена”.
8.2.Наследование
Наследование разделяется на две важные части:
наследование атрибутов,
наследование методов поведения.
8.2.1.Наследование атрибутов
Наследование атрибутов позволяет производному классу использовать атрибуты базового класса, без дополнительного их переопределения. Это дает возможность легкой модификации структур данных путем внесения минимальных изменений. Например, пусть классы геометрических фигур выглядят следующим образом:
Рис. 8.1. пример наследования атрибутов.
и пусть необходимо для каждой фигуры добавить атрибут “цвет заполнения внутренней области”. Наследование позволяет очень легко модифицировать группу структур данных за одну операцию. Но это можно сделать двумя способами: во-первых, можно ввести новый атрибут “цвет” в класс “геометрическая фигура” и по наследованию этот атрибут получат все новые фигуры, во-вторых, можно ввести новый класс “цветная фигура”, как наследника от “геометрической фигуры”. Посмотрим на различия этих двух вариантов:
новый класс увеличивает количество классов и следовательно сложность проекта,
точка изгиба в многоугольнике не должна иметь цвет.
Таким образом можно сказать, что добавляя новый атрибут в некоторый класс необходимо учесть следующие обстоятельства: можно добавить атрибут без добавления класс, но необходимо взвесить, что более накладно создать новый класс или иметь не нужные атрибуты в других классах.
