Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Технологии и методы программирования. Учебное пособие-1
.pdf
правила подготовки, рассмотрения, согласования и утверждения
документации с указанием предельных сроков для каждой стадии;
требования к настройке издательской системы, используемой
в качестве встроенного средства подготовки документации;
требования к настройке инструментальных средств для обеспече-
ния подготовки документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя устанавливает:
правила
оформления экранных форм (шрифты, цветовая палитра),
состав и расположение окон и элементов управления;
правила использования пользователями клавиатуры, мыши и дру-
гих устройств;
правила оформления текстов помощи;
перечень стандартных сообщений, используемых в интерфейсе;
правила обработки реакции пользователя.
КЛАССИФИКАЦИЯ МЕТОДОЛОГИЙ ПРОЕКТИРОВАНИЯ ПС
Все известные методологии по способу декомпозиции систем можно
объединить в
две группы.
1. Структурно-функциональные методологии, в основу которых по-
ложен принцип функциональной декомпозиции: структура системы
описывается в терминах иерархии взаимосвязанных функций и передачи информации между отдельными функциональными элементами.
2. Объектно-ориентированные методологии, использующие объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними,
а поведение системы – в терминах
обмена сообщениями между объектами.
СТРУКТУРНО-ФУНКЦИОНАЛЬНЫЕ МЕТОДОЛОГИИ
Методологии ориентированы на построение совокупности моделей,
каждая из которых должна представлять (описывать) конкретный аспект системы:
функциональную структуру системы;
последовательность выполняемых действий;
передачу информации между функциональными процессами;
отношения между данными.
31
Применение структурного подхода схематично показано на рис. 7.
Разработка функциональной модели
Разработка информационной модели
Разработка поведенческих моделей
Разработка моделей компонентов и развертывания
Рис. 7. Схема применения структурно-функционального подхода
Функциональная модель описывает требования к составу и структуре выполняемых системой функций, характеризует морфологию системы (ее построение) – состав функциональных подсистем, их взаимосвязи. На этой модели указывается исходная информация, промежуточные и итоговые результаты работы системы.
На основе функциональной модели можно понять, что должна делать система и какие действия
позволят достичь требуемого результата,
а также концептуально определить наборы данных, используемых в системе.
Информационная модель описывает информационные аспекты,
отражая отношения между элементами системы в виде структур данных
(состав и взаимосвязи) – баз данных, классов и т. п.
Поведенческий аспект, отражающий динамику системы, позволяет
понять, как это работает, и выяснить, в
какой очередности выполняются
операции, образующие процесс, и временную шкалу процесса (длительность и расписание операций).
Компонентная модель описывает состав и структуру программных и аппаратных средств. Элементами компонентной модели являются реальные компоненты, обеспечивающие реализацию функций
системы и выполнение других (нефункциональных) требований к системе, и связи между ними.
На
основе разработанных моделей создаются процедуры реализации
функций, т. е. алгоритмы обработки данных и поведения элементов системы. На заключительной стадии устанавливается распределение
функций по подсистемам (компонентам), необходимое техническое
32
обеспечение и строится модель их распределения по узлам системы. Показанная на рис. 7 схема не означает, что построение моделей должно
строго соответствовать указанному порядку – одна за другой. Как правило, разработка каждой последующей модели начинается еще до полного завершения разработки предыдущей, а иногда – параллельно.
На стадии проектирования модели расширяются, уточняются
и дополняются диаграммами, отражающими технологию использования системы, ее архитектуру, экранные формы и т. п.
ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ МЕТОДОЛОГИЯ
Объектный подход к проектированию и разработке основан на использовании метафоры объекта. Объект – предмет или явление реального или виртуального мира, имеющее четко определенное поведение и
обладающее состоянием, поведением и индивидуальностью.
Структура и поведение сходных объектов определяют общий для
них класс. Объекты одного класса имеют одинаковое поведение и одинаковые
характеристики (атрибуты), но значения их атрибутов могут
быть разными.
Класс – это некоторая сущность (множество объектов), для которой определены атрибуты (свойства) и методы (действия, которые
объекты производят над окружающими объектами), т. е. класс представляет описание множества объектов, связанных общностью структуры и поведения.
Концептуальной основой объектно-ориентированного подхода является
объектная модель, которая строится с учетом следующих прин-
ципов.
Абстрагирование – это выделение наиболее важных, существенных характеристик некоторого объекта (которые отличают его от всех
других видов объектов и таким образом четко определяют его концептуальные границы с точки зрения дальнейшего рассмотрения и анализа)
и игнорирование менее важных или незначительных деталей
.
Иерархия – это ранжированная или упорядоченная система абстракций, расположение их по уровням. Иерархический характер программной системы отражается в виде иерархии классов, а ее функционирование рассматривается как взаимодействие объектов.
Наследование – построение новых классов на основе существующих
с возможностью добавления или переопределения свойств и методов.
33
Полиморфизм – это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре
объекта.
Инкапсуляция – это практика сокрытия деталей проектирования,
которые могут измениться в будущем, для ограничения каскадных изменений в программной системе и для упрощения ее разработки и сопровождения.
Объектный подход обладает следующими преимуществами.
1. Существенно повышает уровень унификации разработки и при-
годность компонентов для повторного использования, что ведет к созданию среды разработки и переходу к сборочному созданию программных продуктов [40].
2. Позволяет избежать создания сложных моделей, так как методо-
логия предполагает эволюционный путь развития модели на базе относительно небольших подсистем. Созданная
модель конкретизируется на
этапах анализа, проектирования и реализации.
3. Обеспечивает гибкость при модификации и расширении системы.
4. Отсутствует необходимость разработки классов с нуля, за счет
наследования.
ШАБЛОНЫ ПРОЕКТИРОВАНИЯ
Одним из основных преимуществ объектно-ориентированного подхода является возможность повторного использования кода. О повторном использовании кода говорят, когда рассматривают реализацию инкапсуляции и наследования. В этом случае классы разрабатывают так,
чтобы их можно было использовать не в одном, а в нескольких проектах
(инкапсуляция). Удачно определив базовое понятие и
реализовав в виде
класса, его можно успешно и многократно использовать, определяя его
наследников, реализуя их частные свойства.
Кроме того, при объектно-ориентированном подходе можно повторно использовать не только код, но и проектные решения. Типовые
проектные решения в объектно-ориентированном проектировании
(да и не только [41–48]) называются паттернами (шаблонами).
При создании
программных систем перед разработчиками часто
встает проблема выбора тех или иных проектных решений. В этих случаях на помощь приходят паттерны, поскольку подобные задачи уже решались ранее и существуют хорошо продуманные элегантные решения,
составленные экспертами. Паттерны как раз описывают решения таких
повторяющихся задач.
34
Паттерны проектирования упрощают повторное использование
удачных проектных и архитектурных решений. Представление прошедших проверку временем методик в виде паттернов проектирования облегчает доступ к ним со стороны разработчиков новых систем. С помощью паттернов можно улучшить качество документации и сопровождения существующих систем, позволяя явно описать взаимодействия
классов и объектов, а
также причины, по которым система была построена так, а не иначе. Проще говоря, паттерны проектирования дают разработчику возможность быстрее найти «правильный» путь.
Шаблон проектирования, или паттерн, в разработке программного
обеспечения – архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.
Обычно шаблон не
является законченным образцом, который может
быть прямо преобразован в код; это лишь пример решения задачи, который можно использовать в различных ситуациях.
Объектно-ориентированные шаблоны показывают отношения и взаимодействия между классами или объектами без определения того, какие именно конечные классы или объекты приложения будут использоваться.
Правильное использование
паттернов проектирования дает разра-
ботчику ряд неоспоримых преимуществ.
1. Модель системы, построенная в терминах паттернов проектирования, фактически является структурированным выделением тех элементов и связей, которые значимы при решении поставленной задачи.
2. Модель, построенная с использованием паттернов проектирования, более проста и наглядна в изучении, чем стандартная модель.
3. Несмотря на
простоту, она позволяет глубоко и всесторонне проработать архитектуру разрабатываемой системы с использованием специального языка.
4. Применение паттернов проектирования повышает устойчивость
системы к изменению требований и упрощает неизбежную последующую доработку системы.
5. Роль использования паттернов при интеграции информационных
систем организации трудно переоценить.
6. Совокупность паттернов проектирования, по сути, представляет
собой
единый словарь проектирования, который, будучи унифицирован-
ным средством, незаменим для общения разработчиков с друг другом.
35
7. Паттерн, реализованный в нужном месте, в нужное время, может
стать настоящим спасителем разработчика.
Однако любой шаблон проектирования может стать палкой о двух
концах: если он будет применен не к месту, то это может обернуться
катастрофой и создать много проблем в последующем.
В общем случае паттерн состоит из четырех основных элементов.
1. Имя. Сославшись на него, можно сразу описать проблему проектирования, ее решение и последствия. Присваивание паттернам имен
позволяет вести проектирование на более высоком уровне абстракции.
С помощью словаря паттернов можно вести обсуждение с коллегами,
упоминать паттерны в документации, в тонкостях представлять дизайн
системы.
2. Задача. Описание того, когда следует применять
паттерн. Необ-
ходимо сформулировать задачу и ее контекст. Может описываться конкретная проблема проектирования, например способ представления алгоритмов в виде объектов. Иногда отмечается, какие структуры классов
или объектов свидетельствуют о негибком дизайне. Может также включаться перечень условий, при выполнении которых имеет смысл применять данный паттерн.
3. Решение.
Описание элементов дизайна, отношений между ними,
функций каждого элемента. Конкретная реализация не имеется в виду,
поскольку паттерн – это шаблон, применимый в самых разных ситуациях. Просто дается абстрактное описание задачи проектирования и
того, как она может быть решена с помощью некоего весьма обобщенного сочетания элементов (в нашем случае классов и
объектов).
4. Результат – это следствия применения паттерна и разного рода
компромиссы. Хотя при описании проектных решений о последствиях
часто не упоминают, знать о них необходимо, чтобы можно было выбрать между различными вариантами и оценить преимущества и недостатки данного паттерна. Поскольку в объектно-ориентированном проектировании повторное использование нередко
является важным фактором, к результатам следует относить и влияние паттерна на степень
гибкости, расширяемости и переносимости системы.
Выделяют три основных вида шаблонов проектирования: структур-
ные; порождающие; поведенческие.
Структурные шаблоны определяют различные сложные структуры,
которые изменяют интерфейс уже существующих объектов или его реализацию, позволяя облегчить разработку и оптимизировать программу.
36
1. Адаптер/Обертка (Adapter/Wrapper) – преобразует интерфейс
класса в другой интерфейс, ожидаемый клиентом. Позволяет классам
с разными интерфейсами работать вместе.
2. Мост (Bridge) – разделяет абстракцию и реализацию так, чтобы
они могли изменяться независимо.
3. Компоновщик (Composite) – компонует объекты в древовидную
структуру, представляя их в виде иерархии. Позволяет клиенту одинаково обращаться как к отдельному объекту
, так и к целому поддереву.
4. Декоратор (Decorator) – динамически предоставляет объекту до-
полнительные возможности. Представляет собой гибкую альтернативу
наследованию для расширения функциональности.
5. Фасад (Facade) – обеспечивает единый интерфейс к группе интерфейсов подсистемы. Определяет высокоуровневый интерфейс, делая
подсистему проще для использования.
6. Приспособленец (Flyweight) – благодаря совместному использо-
ванию поддерживает эффективную работу с большим
количеством объ-
ектов.
7. Заместитель (Proxy) – предоставляет замену другого объекта для
контроля доступа к нему.
Порождающие шаблоны проектирования абстрагируют процесс
создания экземпляра класса. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов. Шаблон, порождающий классы, использует наследование, чтобы изменять
созданный класс, а шаблон, порождающий объекты, делегирует созда
ние другому объекту.
1. Абстрактная фабрика (AbstractFactory) – предоставляет интер-
фейс для создания групп связанных или зависимых объектов, не указывая их конкретного класса.
2. Строитель (Builder) – разделяет создание сложного объекта и инициализацию его состояния так, что одинаковый процесс построения может создать объекты с разным состоянием.
3. Фабричный метод (Factory Method) – определяет интерфейс
для
создания объекта, но позволяет подклассам решать, какой класс создавать. Позволяет делегировать создание объекта подклассам.
4. Прототип (Prototype) – определяет несколько видов объектов,
чтобы при создании использовать объект-прототип, и создает новые
объекты, копируя прототип.
-
37
5. Одиночка (Singleton) – гарантирует, что класс имеет только один
экземпляр, и предоставляет глобальную точку доступа к нему.
Поведенческие паттерны ‒ определяют алгоритмы и взаимодей-
ствие между классами и объектами, т. е. их поведение.
1. Цепочка обязанностей (ChainOfResponsibility) – избегает связыва-
ния отправителя запроса с его получателем, давая возможность обработать запрос более чем одному
объекту. Связывает объекты-получатели
и передает запрос по цепочке до тех пор, пока объект не обработает его.
2. Команда (Command) – инкапсулирует запрос в виде объекта, позволяя передавать его клиентам в качестве параметров, ставить в очередь, регистрировать, а также поддерживает отмену операций.
3. Интерпретатор (Interpreter) – получая формальный язык, определяет представление
его грамматики и интерпретатор, использующий это
представление для обработки выражений языка.
4. Итератор (Iterator) – предоставляет способ последовательного доступа к элементам множества, независимо от его внутреннего устройства.
5. Посредник (Mediator) – определяет объект, инкапсулирующий
способ взаимодействия объектов. Обеспечивает слабую связь, избавляя
объекты от необходимости прямо ссылаться друг на друга, и дает возможность независимо
изменять их взаимодействие.
6. Хранитель (Memento) – не нарушая инкапсуляцию, определяет и
сохраняет внутреннее состояние объекта и позволяет позже восстановить объект в этом состоянии.
7. Наблюдатель (Observer) – определяет зависимость «один ко многим» между объектами так, что когда один объект меняет свое состояние,
все зависимые объекты оповещаются и обновляются автоматически.
8. Состояние (State) –
позволяет объекту изменять свое поведение
в зависимости от внутреннего состояния.
9. Стратегия (Strategy) – определяет группу алгоритмов, инкапсули-
рует их и делает взаимозаменяемыми. Позволяет изменять алгоритм
независимо от клиентов, его использующих.
10. Шаблонный метод (Template method) – определяет алгоритм, не-
которые этапы которого делегируются подклассам. Позволяет подклассам переопределить эти этапы, не меняя структуру алгоритма.
11.
Посетитель (Visitor) – представляет собой операцию, которая будет выполнена над объектами группы классов. Дает возможность определить новую операцию без изменения кода классов, над которыми эта
операция проводится.
38
6. ТЕХНОЛОГИИ РЕАЛИЗАЦИИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
В условиях промышленного подхода к разработке и сопровождению
программного обеспечения особую значимость приобретает технологичность разрабатываемых программ. Под технологичностью понимают качество проекта программного продукта, от которого зависят
трудовые и материальные затраты на его реализацию и последующие
модификации. Хороший проект сравнительно быстро и легко кодируется, тестируется, отлаживается и модифицируется.
Для
обеспечения необходимых технологических свойств применяют специальные технологические приемы и следуют определенным
методикам, сформулированным всем предыдущим опытом создания
программного обеспечения. К таким приемам и методикам относят правила декомпозиции, методы проектирования, методы программирования и контроля качества, языки и системы программирования, разнообразие которых порождает множество подходов к решению даже
и той же задачи. Это позволяет использовать различные комбинации
специализированных моделей и ведет к появлению разных стилей программирования, определяемых как парадигмы.
Парадигма – это определенный набор концепций, или шаблонов
мышления, включая теории, методы исследования, постулаты и стандарты, в соответствии с которыми осуществляются последующие построения, обобщения и эксперименты в
Парадигма программирования – это парадигма, определяющая
некоторый цельный набор идей и рекомендаций, формирующих стиль
и технику написания программ [13].
Термин «парадигма программирования» впервые применил в 1978 г.
Роберт Флойд в своей лекции лауреата премии Тьюринга [49].
Парадигмы лежат в основе конструирования языков программирования. Каждый язык соответствует своей парадигме, которая определяет
предметной области.
одной
39
стандарты написания кода. Поскольку одна и та же задача может быть
решена с помощью разных языков программирования, выбор языка,
а следовательно, и парадигмы, должен быть осознанным на основе знаний базовых средств и приемов всех основных парадигм программирования.
С возможными классификациями парадигм и построением иерархий
можно ознакомиться в [50, 51], в частности
в [50] приведена таксономия
с 27 различными парадигмами.
Флойд [52] отмечает: «Если прогресс искусства программирования
в целом требует постоянного изобретения и усовершенствования парадигм, то совершенствование искусства отдельного программиста требует, чтобы он расширял свой репертуар парадигм».
Таким образом, изучение парадигм является важным компонентом
обучения специалистов в области информатики и программирования.
Все известные
к настоящему времени парадигмы программирования
можно объединить в две группы: императивную и декларативную.
Императивное программирование – это парадигма программирования, при которой описывается процесс вычисления в виде инструкций, изменяющих состояние программы, т. е. в виде последовательности команд, которые должен выполнить компьютер. Допустимые виды
команд (операторов), а также типы обрабатываемых данных
определя-
ются конкретным языком программирования.
Под такое разделение всех методов обработки информации в рамках
императивной парадигмы попадают почти все известные на сегодняшний день языки программирования, при этом невозможно говорить о явных преимуществах какой-либо одной парадигмы перед остальными,
тем более что многие языки поддерживают несколько парадигм программирования (
мультипарадигмальные языки). Каждая парадигма
наряду с большим количеством положительных особенностей имеет
и отрицательные аспекты.
Цель разработки мультипарадигмальных языков программирования
состоит, как правило, в том, чтобы позволить программистам использовать лучший инструмент для работы, признавая, что никакая парадигма
не решает все проблемы самым легким или самым эффективным способом. Практически все широко
используемые языки являются мультипарадигмальными, поскольку в своем развитии получили дополнительные возможности. Например, C# – это объектно-ориентированный
язык программирования, в котором новые языковые конструкции, такие
40
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]