Тема 2. Классический подход к разработке программных средств Оглавление по теме
реклама
Тема 2. Классический подход к разработке программных средств Оглавление по теме 2.1. Классические методы анализа 2.1.1. Структурный анализ 2.1.2. Методы анализа, ориентированные на структуры данных 2.2. Основы проектирования программных систем 2.2.1. Особенности синтеза программных систем 2.2.2. Этапы процесса проектирования 2.2.3. Структурирование системы 2.2.4. Моделирование управления 2.2.5. Декомпозиция подсистем на модули 2.2.6. Проектирование программ сложной структуры 2.1. Классические методы анализа Системный анализ проводится с целью: выяснения потребностей заказчика; оценки выполнимости системы; выполнения экономического и технического анализа; распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных); определения стоимости и ограничений планирования; создания системной спецификации. В системной спецификации описываются: функции; характеристики системы; ограничения разработки; входная и выходная информация. Анализ требований дает возможность: 1. 2. 3. 4. определить функции и характеристики программного продукта; обозначить интерфейс продукта с другими системными элементами; определить проектные ограничения программного продукта; построить модели процесса, данных, а также режимов функционирования продукта; 5. создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования. Результаты анализа сводятся в спецификацию требований к программному продукту. Анализ требований служит мостом между неформальным описанием требований заказчика и проектированием системы. Известно два подхода к разработке ПО: 1. Функционально-модульный или структурный. 2. Объектно - ориентированный подход. 1 Функционально-модульный подход основан на принципе функциональной декомпозиции. При этом структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Объектно-ориентированный подход использует объектную декомпозицию. Классические методы анализа требований ориентированы на процедурную реализацию программных систем. 2.1.1. Структурный анализ Структурный анализ требований к ПО. — один из формализованных методов анализа Все известные методы структурного подхода базируются на ряде общих принципов: принцип "разделяй и властвуй"; принцип иерархического упорядочения — принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне; принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных; принцип непротиворечивости — обоснованность и согласованность элементов системы; принцип структурирования данных — данные должны быть структурированы и иерархически организованы. В структурном подходе используются средства, описывающие функциональную структуру системы и отношения между данными. Им соответствуют следующие виды моделей (диаграмм): 1. DFD (Data Flow Diagrams) — диаграммы потоков данных; 2. SADT (Structured Analysis and Design Technique) — метод структурног o анализа и проектирования; 3. ERD (Entity-Relationship Diagrams) — диаграммы "сущность — связь". DFD и ERD — наиболее часто используемые в CASE-cредствах виды моделей. Основной элемент структурного анализа — диаграммы потоков данных (DFD-data flow diagrams). Конкретный вид диаграмм и интерпретация их конструкций зависят от стадии разработки ПО. Программное изделие рассматривается как преобразователь информационного потока данных. Диаграммы потоков данных — графическое средство для изображения информационного потока и преобразований, которым подвергаются данные при движении от входа к выходу системы. Диаграмма может использоваться для представления программного изделия на любом уровне абстракции. 2 Рис. 1. Элементы диаграммы потоков данных Рис. 2. Диаграмма потоков данных Контекстная модель используется для указания внешних связей программного изделия. Для детализации (уточнения системы) вводится диаграмма 1-го уровня. Каждый из преобразователей этой диаграммы — подфункция общей системы. Дальнейшее уточнение приводит к диаграмме 2-го уровня. Особенности DFD: Важно сохранить непрерывность информационного потока и его согласованность. Входы и выходы у каждого преобразователя на любом уровне должны оставаться прежними (принцип наследования). В диаграмме отсутствуют точные указания на последовательность обработки, которые откладываются до этапа проектирования. Диаграмма потоков данных — это абстракция, граф. Для связи графа с проблемной областью (превращения в граф-модель) надо задать интерпретацию ее компонентов — дуг и вершин. Описание потоков данных и процессов Базовые средства диаграммы не обеспечивают полного описания требований к программному изделию. Должны быть описаны стрелки (потоки данных) и преобразователи (процессы). Для этих целей используются словарь требований 3 (данных) – глоссарий и спецификации процессов. Глоссарий содержит описания потоков данных и хранилищ данных. Глоссарий является элементом любого CASEсредства автоматизации анализа. Структура словаря зависит от особенностей конкретного CASE-средства: 1. Имя (основное имя элемента данных, хранилища или внешнего объекта). 2. Прозвище (Alias) — другие имена того же объекта. 3. Где и как используется объект — список процессов, которые используют данный элемент, с указанием способа использования (ввод в процесс, вывод из процесса, как внешний объект или как память. 4. Описание содержания — запись для представления содержания. 5. Дополнительная информация — дополнительные сведения о типах данных, допустимых значениях, ограничениях и т. д. Спецификация процесса — это описание преобразователя. Спецификация поясняет: ввод данных в преобразователь; алгоритм обработки; характеристики производительности преобразователя; формируемые результаты. Количество спецификаций равно количеству преобразователей диаграммы. Рис. 3. Поток данных и процессов 2.1.2. Методы анализа, ориентированные на структуры данных Элементами проблемной области для любой системы являются потоки, процессы и структуры данных. При структурном анализе активно работают только с потоками данных и процессами. Методы, ориентированные на структуры данных, обеспечивают: 1. определение ключевых информационных объектов и операций; 4 2. определение иерархической структуры данных; 3. компоновку структур данных из типовых конструкций — последовательности, выбора, повторения; 4. последовательность шагов для превращения иерархической структуры данных в структуру программы. Наиболее известны два метода: метод Варнье—Орра и метод Джексона. В методе Варнье-Орра для представления структур применяют диаграммы Варнье. Для построения диаграмм Варнье используют 3 базовых элемента: последовательность, выбор, повторение (Рис. 4). Рис. 4. Базовые элементы Как показано на Рис. 5, с помощью этих элементов можно информационные структуры с любым количеством уровней иерархии. строить Рис. 5. Информционная структура Как видим, для представления структуры газеты здесь используются три уровня иерархии. Метод анализа Джексона. Как и метод Варнье—Орра, метод Джексона появился в период революции структурного программирования. Оба метода решали одинаковую задачу: распространить базовые структуры программирования (последовательность, выбор, повторение) на всю область конструирования сложных программных систем. Метод Джексона (1975) включает 6 шагов. Три шага выполняются на этапе анализа, а остальные — на этапе проектирования. 1. Объект—действие. Определяются объекты — источники или приемники информации и действия — события реального мира, воздействующие на объекты. 2. Объект—структура. Действия над объектами представляются диаграммами Джексона. 3. Начальное моделирование. Объекты и действия представляются как обрабатывающая модель. Определяются связи между моделью и реальным миром. 4. Доопределение функций. Выделяются и описываются сервисные функции. 5. Учет системного времени. Определяются и оцениваются характеристики планирования будущих процессов. 5 6. Реализация. Согласование с системной средой, разработка аппаратной платформы. Шаг объект—действие. Этот шаг начинается с определения проблемы на естественном языке. При выделении объектов и действий возможны ошибки. Но список объектов и действий может модифицироваться в ходе дальнейшего анализа. Шаг объект—структура. Структура объектов описывает последовательность действий над объектами (в условном времени). Для представления структуры объектов Джексон предложил 3 типа структурных диаграмм. Они показаны на Рис. 6. В первой диаграмме к объектам применяется такое действие, последовательность, во второй — выбор, в третьей — повторение. как Рис. 6. Три типа структурных диаграмм Рассмотрим объектную структуру для транспорта Рис. 7. Условимся, что начало и конец истории транспорта — у первой остановки. Действиями, влияющими на объект, являются Покинуть и Прибыть. 6 Рис. 7. Объектная структура для транспорта Диаграмма показывает, что транспорт начинает работу у остановки 1, тратит основное время на перемещение между остановками 1 и 2 и окончательно возвращается на остановку 1. Прибытие на остановку, следующее за отъездом с другой остановки, представляется как пара действий Прибыть(i) и Покинуть(i). Заметим, что диаграмму можно сопровождать комментариями, которые не могут прямо представляться средствами метода. Например, значение i в двух последовательных остановках должно быть разным. Рис. 8. Объектная структура для транспорта Структурную диаграмму для объекта Кнопка показывает Рис. 8, что к нему многократно применяется действие Нажать. Структурная диаграмма — время, ориентированное описание действий, выполняемых над объектом. Она создается для каждого объекта модели. Шаг начального моделирования. Начальное моделирование — это шаг к созданию описания системы как модели реального мира. Описание создается с помощью диаграммы системной спецификации. Элементами диаграммы системной спецификации являются физические процессы (имеют суффикс 0) и их модели (имеют суффикс 1). Как показано на Рис. 9, предусматриваются два вида соединений между физическими процессами и моделями. Рис. 9. Виды соединений между физическими процессами и моделями 7 Соединение потоком данных производится, когда физический процесс передает, а модель принимает информационный поток. Полагают, что поток передается через буфер неограниченной емкости типа FIFO (обозначается овалом). Соединение по вектору состояний происходит, когда модель наблюдает вектор состояния физического процесса. Вектор состояния обозначается ромбиком. Диаграмма системной спецификации для системы обслуживания перевозок приведена на Рис. 10. При нажатии кнопки формируется импульс, который может быть передан в модель как элемент данных, поэтому для кнопки выбрано соединение потоком данных. Датчики, регистрирующие прибытие и убытие транспорта, не формируют импульса, они воздействуют на электронный переключатель. Состояние переключателя может быть оценено. Поэтому для транспорта выбрано соединение по вектору состояний. Рис. 10. Диаграмма системной спецификации для системы обслуживания перевозок Для фиксации особенностей процессов - моделей Джексон предлагает специальное описание — структурный текст. Структурная диаграмма модели примет вид, изображенный на Рис. 11. Соответственно, структурный текст модели записывается в следующей форме: ТРАНСПОРТ - 1 опрос TSV; ЖДАТЬ цикл ПОКА ПРИБЫЛ (1) опрос TSV; конец ЖДАТЬ; покинуть (1); ТРАНЗИТ цикл ПОКА УБЫЛ (1) опрос TSV; конец ТРАНЗИТ; ТРАНСПОРТ цикл ОСТАНОВКА прибыть (1); ЖДАТЬ цикл ПОКА ПРИБЫЛ (1) опрос TSV; конец ЖДАТЬ; покинуть (1); ТРАНЗИТ цикл ПОКА УБЫЛ (1) опрос TSV; конец ТРАНЗИТ; конец ОСТАНОВКА; конец ТРАНСПОРТ; прибыть (1); конец ТРАНСПОРТ - 1; Табл. 1. Структурный текст 8 Рис. 11. Структурная диаграмма модели 2.2. Основы проектирования программных систем (ПС) 2.2.1. Особенности синтеза программных систем Анализ отвечает на вопрос: "Что должна делать будущая система?, а синтез: — “Каким образом система будет реализовывать предъявляемые к ней требования?” Этапы синтеза: проектирование ПС; кодирование ПС; тестирование ПС. 9 Рис. 12. Информационные потоки процесса синтеза ПС Разработка данных — это результат преобразования информационной модели анализа в структуры данных, которые потребуются для реализации программной системы (модель данных). Разработка архитектуры выделяет основные структурные компоненты и фиксирует связи между ними. Процедурная разработка описывает последовательность действий в структурных компонентах, т. е. определяет их содержание. На синтез приходится более 75% стоимости конструирования ПС. 2.2.2. Этапы процесса проектирования Проектирование — итерационный процесс, посредством которого требования к ПС транслируются в инженерные представления ПС. Две ступени проектирования: 1. предварительное; 2. детальное. Предварительное проектирование уровня. формирует абстракции архитектурного Детальное проектирование уточняет эти абстракции, добавляет подробности алгоритмического уровня. Интерфейсное проектирование — формирование графического интерфейса пользователя (GUI). 10 Рис. 13. Информационные связи процесса проектирования Предварительное проектирование обеспечивает идентификацию подсистем и определение основных принципов управления подсистемами (взаимодействия подсистем). Три типа деятельности предварительного проектирования: 1. Структурирование системы. 2. Моделирование управления. 3. Декомпозиция подсистем на модули. 2.2.3. Структурирование системы Модели системного структурирования: модель хранилища данных (рис. 14); модель клиент-сервер (рис. 15); трехуровневая модель (рис. 16); модель абстрактной машины (рис. 17). Рис. 14. Модель хранилища данных 11 Рис. 15. Модель клиент-сервер Рис. 16. Трехуровневая модель Рис. 17. Модель абстрактной машины 2.2.4. Моделирование управления Типы моделей управления: модель централизованного управления; модель событийного управления. 12 Рис. 18. Модель вызов-возврат Рис. 19. Модель менеджера Типы модели событийного управления: широковещательная модель (рис. 20); модель, управляемая прерываниями(рис. 21). Рис. 20. Широковещательная модель 13 Рис. 21. Модель обработки прерываний 2.2.5. Декомпозиция подсистем на модули Два типа моделей модульной декомпозиции: 1. модель потока данных (разбиение на модули по функциям); 2. модель объектов (основана на слабо сцепленных сущностях). Модуль — фрагмент программного физической структуры системы. текста — строительный блок для Модуль состоит из: интерфейсной части; части-реализации. Модульность — свойство системы, которая может подвергаться декомпозиции на ряд внутренне связанных и слабо зависящих друг от друга модулей. Рис. 22. Затраты на модульность Оптимальный модуль должен удовлетворять критериям: 1. снаружи он проще, чем внутри; 2. модуль проще использовать, чем построить. Принцип информационной закрытости Содержание модулей должно быть скрыто друг от друга: все модули независимы, обмениваются только информацией, необходимой для работы; доступ к операциям и структурам данных модуля ограничен. 14 Рис. 23. Информационная закрытость модуля Достоинства информационной закрытости: 1. обеспечивается возможность разработки модулей независимыми коллективами; 2. обеспечивается легкая модификация системы. Связность модуля (Cohesion) — это мера зависимости его частей. различными, Для измерения связности используют понятие силы связности (СС). Табл. 2. Характеристика связности модулей Типы связности Функциональная Информационная (последовательная) Коммуникативная Сопровождаемость Лучшая сопровождаемость Процедурная Временная Логическая Худшая сопровождаемость Роль модуля "Черный ящик" Не совсем "Черный ящик" "Серый ящик" "Белый" или "просвечивающий ящик" "Белый ящик" По совподению Сцепление (Coupling) — мера взаимозависимости модуля с данным. Сцепление — внешняя характеристика модуля, которую желательно уменьшать. Количественно сцепление измеряется степенью сцепления (СЦ). 2.2.6. Проектирование программ сложной структуры Сложность системы определяется как сумма мер сложности ее модулей. М. Холстед (1977) предложил меру длины N модуля: где n1 — число различных операторов; n2 — число различных операндов. Второй вариант метрики — объем V модуля (количество символов для записи всех операторов и операндов текста программы): Сложная система состоит из элементов и системы связей между элементами. Том МакКейб (1976) предложил метрику цикломатической сложности (определяется топологией внутренних связей). 15 где Е — количество дуг; а N — количество вершин в управляющем графе ПС. Таким образом, рассматривать: при комплексной оценке сложности ПС необходимо меру сложности модулей; меру сложности внешних связей (между модулями); меру сложности внутренних связей (внутри модулей). Традиционно с внешними связями сопоставляют “сцепление”, а с внутренними — “связность”. 16
