- •«Технологии разработки программного обеспечения»
- •Оглавление
- •Введение
- •Анализ проблемы. Постановка задачи
- •Введение
- •Описание примера
- •Составление списка заинтересованных лиц
- •Анкетирование и проведение интервью
- •Список потребностей заинтересованных лиц
- •Задания
- •Контрольные вопросы
- •Моделирование объекта автоматизации
- •Введение
- •Введение в методологиюAris
- •Описание инструментаAris. Начало работы
- •Построение организационной модели
- •Построение диаграммы цепочек добавленного качества
- •ПостроениеeEpCмодели
- •Описание объектов автоматизации
- •Задания
- •Контрольные вопросы
- •Разработка модели вариантов использования и их спецификаций
- •Введение
- •Разработка модели вариантов использования
- •Модель вариантов использования
- •Построение модели вариантов использования
- •Спецификация вариантов использования
- •Основной поток
- •Альтернативные потоки
- •Специальные требования
- •Пример спецификации варианта использования
- •Алгоритм расчёта рейтингов
- •Задания
- •Пример написания раздела
- •Назначение документа
- •Наименование системы
- •Сведения о заказчике и исполнителе
- •Основания для выполнения работ, сроки и финансирование
- •Основные понятия, определения и сокращения
- •Актуальность разработки системы
- •Назначение и цели создания (развития) системы
- •Требования к содержимому раздела
- •Пример написания раздела
- •Характеристики объекта автоматизации
- •Требования к содержимому раздела
- •Пример написания раздела
- •Организация и планирование научно-исследовательской и инновационной деятельности
- •Исполнители научно-исследовательских работ
- •Учет и отчетность по научно-исследовательским работам
- •Требования к системе
- •Требования к содержимому раздела
- •Пример написания раздела
- •Требования к системе в целом
- •Требования к структуре и функционированию системы
- •Требования к численности и квалификации персонала
- •Требования к функциям (задачам)
- •Описание вариантов использования
- •Состав и содержание работ по созданию системы
- •Требования к содержимому раздела
- •Пример написания раздела
- •Порядок контроля и приемки системы
- •Требования к содержимому раздела
- •Пример написания раздела
- •Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
- •Требования к содержимому раздела
- •Пример написания раздела
- •Создание служб необходимых для функционирования системы
- •Функциональные этапы внедрения системы
- •Требования к документированию
- •Требования к содержимому раздела
- •Пример написания раздела
- •Паспорт системы
- •Общее описание системы
- •Руководство администратора
- •Руководство пользователя
- •Регламент эксплуатации
- •Источники разработки
- •Правила оформления
- •Задание
- •Бизнес-логика
- •Объектно-реляционное отображение
- •Структура бд
- •Создание проекта вBorlandDeveloperStudio
- •Добавление нового модуля в проект
- •Создание классов с помощью диаграммыUml
- •Добавление полей
- •Добавление свойств
- •Добавление процедуры
- •Добавление функции
- •Создание отношений между классами
- •Ассоциация
- •Агрегация
- •Наследование
- •Пример создания классов
- •Создание классов и отношений между ними слоя объектно-реляционного отображения
- •Создание классов слоя бизнес-логики
- •Невизуальные компоненты интерфейса используемые в примере
- •TimageList
- •TActionManager
- •Визуальные компоненты используемые в примере
- •TBitBtn
- •TdbGrid
- •TcomboBox
- •TPageControl
- •Пример разработки интерфейса
- •Главная форма
- •Форма редактирования параметров студента
- •Форма редактирования книг
- •Форма отображения списка книг
- •Подключение классов
- •Сохранение проекта
- •Задание
- •Шаблоны проектирования
- •Шаблон InformationExpert(информационный эксперт)
- •Преимущества
- •Шаблон Creator(создатель)
- •Преимущества
- •Шаблон LowCoupling(слабое связывание)
- •Преимущества
- •Шаблон HighCohesion(высокое зацепление)
- •Преимущества
- •Шаблон Controller(контроллер)
- •Преимущества
- •Применение шаблонаInformationExpert
- •Применение шаблонаCreator
- •Использование шаблонаHighCohesion
- •Применение шаблонаController
- •Задание
- •Технология eco
- •Язык объектных ограничений ocl
- •Mdi-контейнеры
- •Создание простого mda-приложения
- •Основные этапы разработки приложения
- •Обзор возможностей Borland Developer Studio 2006 для разработки mda-приложения
- •Создание моделиUml
- •Создание бд и настройкаEcOкомпонент
- •Создание интерфейса
- •Связывание интерфейса с моделью
- •Создание логики наOcl
- •Задания
- •Контрольные вопросы
- •РазработкаMda-приложения с использованием машин состояний
- •Введение
- •Автоматы
- •Состояния
- •Подавтоматы
- •Диаграммы состояний
- •Создание mda-приложений с использованием машин состояний
- •Модификация модели uml
- •Создание машины состояний
- •Обновление базы данных
- •Модификация пользовательского интерфейса
- •Связывание интерфейса с моделью
- •Применение автоформ
- •Расширение пользовательского интерфейса
- •Задания
- •Контрольные вопросы
- •Расширенные возможности разработкиMda-приложений
- •СозданиеMda-приложения с расширенными возможностями
- •Модификация моделиUml
- •Программное добавление объекта
- •Программное удаление объекта
- •Программное редактирование объекта
- •Работа со справочником
- •Поиск объектов
- •Задания
- •Контрольные вопросы
- •Заключение
- •Библиографический список
Преимущества
Применение шаблона Creatorне повышает степени связанности, поскольку созданный (created) класс, как правило, оказывается видимым для класса-создателя посредством имеющихся ассоциаций.
Шаблон LowCoupling(слабое связывание)
Проблема. Как обеспечить зависимость, незначительное влияние изменений и повысить возможность повторного использования?
Решение. Распределить обязанности таким образом, чтобы степень связанности оставалась низкой.
Степень связанности (coupling) – это мера, определяющая насколько жестко один элемент связан с другими элементами, либо каким количеством данных о других элементах он обладает. Элемент с низкой степенью связанности (или слабым связыванием) зависит от не очень большого числа других элементов. Выражение "очень много" зависит от контекста, однако необходимо провести его оценку.
Класс с высокой степенью связанности (или жестко связанный) зависит от множества других классов. Однако наличие таких классов нежелательно, поскольку оно приводит к возникновению следующих проблем:
Изменения в связанных классах приводят к локальным изменениям в данном классе;
Затрудняется понимание каждого класса в отдельности;
Усложняется повторное использование, поскольку для этого требуется дополнительный анализ классов, с которыми связан данный класс.
В шаблоне Low Coupling описывается принцип, о котором нельзя забывать на протяжении всех стадий работы над проектом. Он является объектом постоянного внимания. Шаблон Low Coupling представляет собой средство, которое разработчик применяет при оценке всех принимаемых в процессе проектирования решений.
Шаблон LowCouplingподдерживает независимость классов, что, в свою очередь, повышает возможности повторного использования и обеспечивает более высокую эффективность приложения. Его нельзя рассматривать изолированно от других шаблонов, таких какExpertиHighCohesion. Скорее, он обеспечивает один из основных принципов проектирования, применяемых при распределении обязанностей.
Подкласс жестко связан со своим суперклассом. Поэтому, принимая решение о наследовании свойств объектов, следует учитывать, что отношение наследования повышает степень связанности классов.
Не существует абсолютной меры для определения слишком высокой степени связывания. Важно лишь понимать степень связанности объектов на текущий момент и не упустить тот момент, когда дальнейшее повышение степени связанности может привести к возникновению проблем. В целом, следует руководствоваться таким принципом: классы, которые являются достаточно общими по своей природе и с высокой вероятностью будут повторно использоваться в дальнейшем, должны иметь минимальную степень связанности с другими классами.
Крайним случаем при реализации шаблона LowCouplingявляется полное отсутствие связывания между классами. Такая ситуация тоже нежелательна, поскольку базовой идеей объектного подхода является система связанных объектов, которые "общаются" между собой посредством передачи сообщений. При слишком частом использовании принципа слабого связывания система будет состоять из нескольких изолированных сложных активных объектов, самостоятельно выполняющих все операции, и множества пассивных объектов, основная функция которых сводится к хранению данных. Поэтому при создании объектно-ориентированной системы должна присутствовать некоторая оптимальная степень связывания между объектами, позволяющая выполнять основные функции посредством взаимодействия этих объектов.