Технология программирования. Качество программных систем PDF

1 Технология программирования. Качество программных систем. Основные требования к программам, входящим в программную систему: 1. Правильность (функционирует в соответствии с техническим заданием). 2. Точность (результаты имеют допустимые отклонения от аналогичн...

1 Технология программирования. Качество программных систем. Основные требования к программам, входящим в программную систему: 1. Правильность (функционирует в соответствии с техническим заданием). 2. Точность (результаты имеют допустимые отклонения от аналогичных результатов расчётов по идеальным математическим моделям). 3. Совместимость (программа работает должным образом не только автономно, но и как составная часть всей программной системы). 4. Надёжность (программа при всех условиях обеспечивает полную повторяемость результата). 5. Универсальность (правильно работает при любых допустимых вариантах исходных данных, предусматриваются средства защиты от неправильных данных). 6. Защищённость (сохраняет работоспособность при возникновении сбоев, защита от несанкционированного доступа). 7. Полезность (решаемая задача представляет практическую ценность). 8. Эффективность (объём требуемых ресурсов не превышает допустимых пределов). 9. Проверяемость (качество программы могут быть продемонстрированы на практике). 10. Адаптируемость (допускает быструю модификацию для приспособления к новым условиям). Аспекты качества оценки программных систем. Качество программы определяется с разных точек зрения: 1. Среда пользователей: качества программы должны проявляться для тех, кто с ними работает, то есть программный продукт должен быть ориентирован на нужды пользователя. Поэтому при проектировании программных систем надо вовлекать пользователей в процесс создания программы. Соответственно выделяют: а) служащие, подготавливающие документацию на компьютере; б) инженеры, выполняющие научно-технические расчёты; в) работники вспомогательного персонала, отвечающие за ввод информации, контролирующие правильность и точность данных. 2. Вычислительная среда, с которой взаимодействует программа. Проще создать хорошую программу, располагая эффективными вспомогательными средствами. Таким образом, рекомендуется максимально использовать сервисные средства автоматизации проектирования.  2 3. Среда заказчиков. Официальному заключению договора предшествует проработка вопросов, где необходимо прояснить: а) реальную потребность в такой системе; б) оценить возможности программной системы, её разработки и примерный объём затрат; в) оценить ожидаемый эффект от её внедрения. После завершения предварительных исследований составляется список требований, предъявляемых к системе: 1. Совокупность условий, при которых эксплуатируется система (аппаратные и программные ресурсы; внешние условия функционирования – состав людей и работ, имеющих к ней отношение). 2. Описание выполняемых системой функций. 3. Ограничения, которые надо учитывать при проектировании (сроки завершения отдельных этапов, имеющиеся ресурсы, мероприятия по сохранности информации). ВЫВОД: Необходимо всесторонне анализировать эффекты, связанные с внедрением в систему. Стадии разработки программного обеспечения. ГОСТ 19102-77 Согласно этому ГОСТу существуют следующие стадии: 1. Техническое задание (т.з.). 2. Эскизный проект (э.п.). 3. Технический проект (т.п.). 4. Рабочий проект (р.п.). 5. Внедрение. Рассмотрим каждый из них: 1. Техническое задание. Выполнение следующих работ:  постановка задачи;  сбор исходных материалов;  выбор и обоснование критериев эффективности и качества разрабатываемой программы;  обоснование необходимости проведения научно-исследовательских работ;  обоснование целесообразности применения ранее разработанных программ, принципиальные возможности решения поставленной задачи;  предварительный выбор методов решения задач;  определение требований к техническим средствам;  определение требований и целей разработки программ, стадий, этапов, сроков разработки программы и документаций на неё;  проведение технико-экономического обоснования разработки программ;  согласование и утверждение т.з.  3 2. Эскизный проект. Виды работ:  внешнее проектирование программного изделия;  уточнение методов решения задач;  предварительное проектирование внутренних структур данных;  разработка общего алгоритма решения задач, укрупненной структурной схемы программного изделия, пояснительная записка. Внешнее проектирование программного изделия есть процесс описания ожидаемого поведения системы с точки зрения пользователя. При разработке э.п. определяются:  способы взаимодействия пользователя с программой,  функции пользователей,  тип языка взаимодействия,  структура и содержание информационных кадров и шаблонов диалога,  структура входных и выходных данных. 3. Технический проект. Виды работ:  проектирование архитектуры программного изделия (изделие делят на составные части, определяют функции каждой компоненты, способы взаимодействия между ними, разрабатывают схемы управления потоками данных, схемы распределения оперативной и внешней памяти);  проектирование структур данных (определяются способы представления, хранения и преобразования входных, выходных и внутренних данных);  проектирование модульной структуры изделия: разбиение компонентов на подпрограммы, определение их функций и способов взаимодействия;  проектирование модулей: описание всех модулей программного изделия, т.е. назначение имён модулей, описание их функций, входных и выходных данных, их форматов, диапазонов допустимых значений, функциональной взаимосвязи между входом и выходом, описание событий внешних по отношению к модулю, форма обращения к модулю, список модулей вызываемых данных и модулей, которые вызывает данный модуль, описание алгоритма модуля;  разработка пояснительной записки. 4. Рабочий проект. Виды работ:  кодирование, тестирование и отладка программ;  разработка программных документов согласно требованиям ЕСПД;  проведение приёма сдаточных испытаний;  корректировка программ и документации по результатам испытаний. 5. Внедрение:  Подготовка передачи программ и документации для сопровождения. Разработка спецификаций. Спецификация – это достаточно полное и точное описание задачи, которую надо решить, она занимает промежуточное положение между требованиями и готовой программой. В процессе проектирования может значительно меняться. Выделяет две части:  4 1. Функциональная спецификация: описывает объекты, участвующие в задаче, деление задачи на подзадачи, входные и выходные данные, связи между ними, процессы и действия, реакции на исключительные ситуации. 2. Эксплуатационная спецификация: определяет скорость работы программы или используемые ею ресурсы, характеристики аппаратуры, на которой программа должна выполняться, специальные требования к надёжности и безопасности, и т.д. Спецификации пишутся с использованием специальных языков:  графических;  текстовых. Графический язык – спецификация в виде графов (точки и стрелки) и диаграмм. Текстовый язык – это псевдокод. Разработка спецификаций методом структурного анализа. Данный метод представляет собой последовательную детализацию проектируемой системы сверху – вниз. Имеет 2-е особенности: 1. разложение анализируемого объекта на каждом новом уровне полностью эквивалентно предшествующему. 2. на каждом уровне рассматривается не только система, но и окружающая её среда, которая последовательно детализируется вместе с системой. УПРАВЛЕНИЕ обьект ВХОД ВЫХОД анализа МЕХАНИЗМ – это окружающая среда объекта. Объектом анализа может быть: – предмет или операция. Если объект анализа – это предмет, то окружающая среда – операция; и наоборот. Пример: Предмет – данные; Операция – преобразования над ними. ВХОД – это операция, создающая данный предмет. ВЫХОД – это операция, использующая данный предмет. УПРАВЛЕНИЕ – это условие существования предмета. МЕХАНИЗМ – это средства воплощения.  5 Метод структурного анализа даёт рекомендации по проведению процесса анализа и оформления его результатов, но не указывает способ деления объекта на части, т. к. последнее связано с особенностями предметной области и требует знания сущности проблемы. Разработка спецификаций оперативно-графическим методом (HIPO). Спецификация методом HIPO есть альбом связанных между собой схем, каждая из которых описывает какую-либо часть задачи или системы, подлежащие разработке. Процесс деления задачи на части имеет особенности: 1. Каждая часть объекта и разложение этой части на следующем уровне не обязательно эквивалентны; некоторые детали могут не подвергаться дальнейшему разложению. 2. Разложение каждой части объекта не зависит от разложения других частей. Систему разлагают на части по функциональному признаку. Рекомендуется следующая последовательность методов: 1. На начальных этапах проектирования при определении архитектуры программного обеспечения конкретной системы используется метод системного анализа. 2. На следующих этапах проектирования, когда структура и состав программного обеспечения определены, используется метод HIPO Документирование программного обеспечения. Осуществляется в соответствии с требованиями ЕСПД. Виды программных документов: 1. Спецификация (состав программы и документация на неё); 2. Ведомость держателей подлинников (перечень предприятий, на которых хранятся подлинники программных документов); 3. Техническое задание (требование к программе, стадии и сроки разработки, виды испытаний); 4. Пояснительная записка (общее описание алгоритма и функционирования программы); 5. Программа и методика испытаний (содержит требования, подлежащие проверке при испытании программы, порядок и методы их контроля); 6. Описание программы (сведения логической структуре и функционировании программы); 7. Текст программы (с использованием комментариев); 8. Эксплуатационные документы: 8.1 Ведомость эксплуатационных документов; 8.2 Формуляр – это основные характеристики программы, комплектность и сведения о программе эксплуатации; 8.3 Описание применения (назначение, область применения, методы и классы решаемых задач);  6 8.4 Руководство программиста (сведения, необходимые для эксплуатации программы); 8.5 Руководство системного программиста (сведения для проверки обеспечения функционирования и настройки программы на условие конкретного применения); 8.6 Описание языка (синтаксис и семантика языка взаимодействия пользователя и программы); 8.7 Руководство оператором (сведения, необходимые для обеспечения процедуры общения оператора с ЭВМ в процессе выполнения программ); 8.8 Руководство по техническому обслуживанию (описание применения тестовых и диагностических программ при обслуживание технических средств); Состав программного документа: 1. Лист утверждения (заказчик и исполнитель, их подписи). 2. Титульный лист. 3. Аннотация. 4. Содержание. 5. Текст документа 6. Приложение. 7. Перечень сопроводительных документов. Содержание основных документов. Техническое задание: 1. Введение. 2. Основание для разработки. 3. Назначение разработки. 4. Требования к программному изделию: 4.1 функциональным характеристикам; 4.2 условиям эксплуатации; 4.3 составу и параметрам технических средств; 4.4 маркировке, транспортированию, упаковке и хранению. 5. Требование к программной документации. 6. Технико-экономические показатели. 7. Стадии и этапы разработки. 8. Порядок контроля и приёмки. Пояснительная записка: 1. Введение. 2. Назначения и область применения. 3. Технологические характеристики: 3.1 Постановка задачи, описание математических методов, допущения и ограничения;  7 3.2 Описание алгоритма программ с обоснованием выбора схемы алгоритма; 3.3 Описание и обоснование выбора метода организации входных и выходных данных, состав технических и программных средств; 4. Описание технико-экономических показателей. Программа и методика испытаний: 1. Объект испытаний. 2. Цель испытаний. 3. Состав предъявляемой документации. 4. Технические требования: 4.1 к программной документации; 4.2 к техническим характеристикам; 4.3 к информационной и программной совместимости. 5. Порядок проведения испытаний. 6. Методы испытаний. Описание программы: 1. Общие сведения. 2. Функциональные назначения. 3. Входные данные. 4. Описание логической структуры: 4.1 Используемые методы; 4.2 Структура программы с описанием функций составных частей и связи между ними. 4.3 Структура и организация данных. 4.4 Алгоритмы программы. 4.5 Связь с другими программами. 5. Вызов и загрузка. 6. Используемые технические средства. Описание применения: 1. Назначение программы. 2. Условия применения. 3. Описания задачи. 4. Входные и выходные данные. Описание языка: 1. Общие сведения. 2. Синтаксис и семантика элементов. 3. Операторы. 4. Средства обмена данными. 5. Средства отладки программы. Руководство оператора:  8 1. Назначение программы. 2. условие выполнения программы. 3. Выполнение программы. 4. Сообщения оператору. Руководство программиста: 1. Назначение и условия применения программы. 2. Характеристики программы. 3. Обращение к программе. 4. Входные и выходные данные. 5. Сообщения. Проектирование систем. Система (программная система) – совокупность связанных друг с другом программ и наборов данных. Число программ в системе зависит от сложности и порядка поступления исходных данных. Если данные относятся к нескольким типам или элементы данных поступают в различные моменты времени, то требуется ряд связанных друг с другом программ. Определение основных компонентов системы. Простейшая система включает один входной поток данных, один выходной поток, одну программу, содержащую подпрограмму. Если элементы данных поступают из нескольких источником, то тогда для каждого источника предусматривается свой входной поток. Если результаты предполагается использовать несколькими способами, то надо иметь соответствующее число отдельных выходных потоков. Данные, характеризующие текущую ситуацию, могут подвергаться корректировке (обновление записи, содержащей информацию, например, о деятельности предприятия). Данные, получаемые в ходе длительного эксперимента, пополняются новыми записями. Таким образом, система должна включать в себя хотя бы три программы, выполняющие основные функции:  запоминание данных;  корректировка данных;  использование хранящихся данных. Если система состоит из нескольких программ, то в ней циркулирует несколько различных потоков данных. Для каждой программы предусматривается два потоков данных:  входной;  выходной. Если программа предназначена для корректировки, то она имеет два входных потока: 1. данные, подлежащие корректировке; 2. новую информацию.  9 Если выходной поток направляется не на монитор, то должен быть предусмотрен дополнительный выходной поток, отражающий процесс выполнения программы (успешное или аварийное завершение, любые отклонения от нормы). Пример: Упрощённая структура системы сопровождения данных: Изменение данных Использо Исходные Хранение Главный Корректи Главный вание данные данных список ровка список данных оперативный оперативный отчет отчет отчет - длительное хранение, - процесс преобразования данных, - поток данных. Такую структуру имеют многие автоматизированные системы управления и ведения документации. Данная схема отображает порядок прохождения данных через систему. Это связано с тем, что хотя о прикладных системах принято судить как о наборах программ, сами данные имеют более важное значение, чем программное обеспечение. Если программа повреждена, то можно перезаписать, тогда как восстановление данных сложнее. Поэтому надо постоянно копировать данные, иногда хранить записи обо всех проведённых корректировках. С учетом дополнений структура системы сопровождения данных имеет вид: Копиро- вание данных Сорти- Упорядо- Коррек- Исполь- Исходные ровка ченные Хранение тировка зование данные данных данные данных Главный данных Главный данных отчет файл файл Корректи- рующий файл Корректи- файл регистрации Сбор Сорти- Изменение рующий корректировок измене- ровка данных файл ний изменений оперативный отчет  10 Определение потоков данных. Определение потоков данных производится согласно правилам: 1. Каждому источнику данных соответствует один входной поток; 2. Если имеется совокупность наборов данных, получаемых из нескольких источников, то эти наборы распределяются по группам обрабатываемых совместно потоков данных; 3. Если не все потоки данных обрабатываются одновременно, то процесс обработки делится на этапы, в каждом из которых участвует группа совместно обрабатываемых потоков. Ещё должны существовать внутренние потоки данных, связывающие последовательные этапы. 4. Для каждого этапа обработки в системе выделяется основной выходной поток, содержащий результаты обработки и дополнительный поток для выдачи оперативных отчётов, сообщений об ошибках и т.п. Определение процессов. Основные правила: 1. Если потоки данных обрабатываются раздельно, то для каждого из них требуется отдельный процесс. 2. Если некоторые функции системы должны выполняться в разное время или чаще других функций, то они реализуются в виде отдельных процессов. 3. Если некоторые, из промежуточных потоков данных сохраняются для их последующего использования, то должны быть предусмотрены: а) процесс для их запоминания; б) процесс для сопровождения, если требуется корректировка; в) процесс для поиска и обработки данных. Примечание: Когда вся совокупность определена, стоит выяснить, нет ли заранее написанных программ, которые могли бы выполнить часть необходимых функций. Методы разработки данных. Чтобы продемонстрировать связи, существующие между отдельными компонентами системы, используют графические схемы. 1. Графические диаграммы (граф-диаграммы) Граф имеет вершины и рёбра. Рёбра изображаются в виде стрелок, указывающие направление передачи управления. В вершинах могут быть записаны значения переменных. Графы бывают плоские и трёхмерные. Граф-диаграммы отображают прохождение потоков данных между процессами. Поэтому их ещё называют графами потоков данных (пример предыдущей темы – граф-диаграмма). Такой тип схемы можно использовать как на системном уровне для описания внешних входов и выходов, так и при проектировании самих программ для описания перемещения данных между отдельными модулями. Физические носители данных здесь не указываются.  11 2. Диаграммы Варнье-Орра. Здесь в иерархической структуре системы выделяются её основные элементарные составные части, которые отражают носители информации (схематичный рисунок). Сначала система делится на ряд отдельных процессов. Это 1-й уровень. На следующем уровне указываются потоки данных для каждого процесса. 3-й уровень: перечисляются наборы данных. 4-й уровень6 перечисляются соответствующие носители информации. Направление потоков данных отмечаются стрелками. Исходные данные Оперативный отчёт Главный список Главный список Изменённые данные Оперативный отчёт Главный список Отчёт Система сопровождения данных: Создание файла вход выход Корректировка данных вход выход Использование файла вход выход Примечания к диаграмме: Наборы данных, используемые одновременно в нескольких процессах связаны между собой и имеют одинаковые имена. Этот метод применяется при разработке программ.  12 3. Функциональные схемы. Состоят из одного или нескольких прямоугольных блоков, содержащих название программ. Блоки соединяются входящими в них стрелками с источниками и исходящими из них стрелками с приёмниками данных. Источники и приёмники данных – это физические носители информации (условные изображения). При построение функциональных схем внешние носители помещаются по бокам листа. Процессы и наборы данных должны чередоваться вдоль линии передачи. Процессы могут сообщаться друг с другом только с помощью наборов данных. Всякая пересылка данных из одного набора в другой осуществляется соответствующими процессами. Пример: Старый Коррекция главный файла файл Программа корректировки Отчёт о Новый корректировке главный файл - не поток данных, а указывает на то, что оба файла являются логически одним и тем же. Проектирование программ. Проектирование программ подобно проектированию всей системы. В отличии от системы каждая программа имеет единственное функциональное назначение и не может быть разбито на части, используемые в различные моменты времени. Сходство программы с системой заключается в наличии внешних и внутренних потоков данных, областей хранения данных, возможность разделения её на независимые модули, которые можно обрабатывать и настраивать отдельно. Модуляризация программы – это разделение её на части по некоторым правилам. Этими частями могут быть: внутренние или внешние процедуры, программные секции. Преимущества модульности: 1. Упрощение разработки и реализации программ. 2. Облегчение чтения программ. 3. Упрощение настройки и модификации программ. 4. облегчение работы с данными, имеющие сложную структуру. 5. Возможность избежать чрезмерной детализации алгоритма. 6. Обеспечение более выгодного размещения программ в памяти ЭВМ.  13 Группы методов проектирования программ: 1. Методы нисходящего проектирования. 2. Методы расширения ядра. 3. Методы восходящего проектирования. 4. Методы объектно-ориентированного проектирования. 1. Метод нисходящего проектирования. 1-й шаг: формулируется предложение, описывающее функцию всей программы. 2-й шаг: определяются подфункции программы. Эта процедура является рекурсивной, т.е. каждая из подфункций может расчленяться до тех пор, пока её составные части не будут окончательно уточнены. Здесь широко применяется стратегия пошагового уточнения. Пошаговое уточнение. На каждом следующем этапе декомпозиции определяются программы очередного более низкого уровня. Для этого используются процедурные языки программирования. Пример: 1-й шаг: Процедура! обработка_пакетов; 2-й шаг: Процедура! обработка_пакетов; сортировать записи по управляющим полям; отделить правильные записи от неправильных и обработать; ВСЁ – Процедура! С помощью расширения шагов процедуры выполняется дальнейшее уточнение программы. На некоторых шагах уточнения появляется необходимость в использовании управляющих структур. Пример: Процедура! обработка пакетов; сортировать записи по управляющим полям; взять первую запись; Цикл – пока не конец входного файла; Повторять взять правую управляющую группу; обработать группу записей; ВСЁ – цикл; обработать неправильные управляющие группы; ВСЁ – Процедура!  14 Операцию сортировки надо написать и оформить в виде независимого модуля. Разбиение на модули осуществляется эвристическим способом. На каждом этапе проектирования по возможности не уточняются операции с данными. Эти вопросы откладываются на более поздние сроки. На этапе, когда принимается решение о прекращение дальнейшего уточнения, оставшиеся неопределёнными подфункции становятся вызываемыми функциями или процедурами, а проектируемый модуль – управляющим модулем. 1. Заставляет сформулировать программу. 2. Разбить программу на проблемы. Преимущества метода пошагового уточнения: Преимущество состоит в том, что основное внимание при его использовании обращается на проектирование корректной программы, а не только на детальное понимание задачи. Т.к. 1-й этап проектирования – корректен, а каждый последующий этап является уточнением предыдущего лишь с небольшими изменениями, то легко может быть выполнена проверка корректности процесса разработки на всех этапах. Недостаток метода: Недостаток состоит в том, что на поздних стадиях проектирования может обнаружиться необходимость в структурных изменениях, требующих пересмотра более ранних конструкций. Модульная структура программ. Модульная структура программ разрабатывается на стадии технического проекта, когда определяется состав программных модулей и устанавливаются связи между ними по управлению и данным. Виды модульных структур: 1. Монолитно-модульная структура. Включает в себя большой программный модуль, реализующий основную часть возложенных на программу функций. Из этой части имеется незначительное число обращений к другим программным модулям небольшого размера. Недостаток: Сложность для понимания, проверки и сопровождения. Подобной структуры следует избегать. Все программные модули рекомендуется ограничивать сотней операторами исходного языка программирования. 2. Последовательно-модульная структура. Такая структура включает в себя несколько последовательно передающих друг другу управления управление программных модулей.  15 Преимущество: простота и наглядность. Недостаток: реализуется только для простых программ. 3. Модульно-иерархическая структура. Включает в себя программные модули, располагаемые на нескольких уровнях иерархии. Модули верхних уровней управляют работой модулей нижних уровней. Структура проста и позволяет решать сложные задачи. 4. Модульно-хаотическая структура. Модули в структуре связаны между собой таким образом, что они не образуют в явном виде ни одну из перечисленных выше структур. Эти программы сложны для проверки и сопровождения. Следует избегать получения таких программ. Такая структура может оказаться допустимой только в системах реального времени с жёсткими объёмно- временными ограничениями. Технологический цикл конструирования программной системы (ПС): три процесса. Технологический цикл конструирования программной системы (ПС) вклю- -чает 3 процесса: 1.Анализ. 2.Синтез. 3.Сопровождение. 1.Анализ. Отвечают на вопрос: что должна делать будущая система. Необходимо учитывать полноту и точность в определении требований к программной системе; 2.Синтез. Отвечают на вопрос каким образом система будет реализовывать предъявляемые к ней требования. Три этапа синтеза: a) Проектирование; b) Кодирование; c) Тестирование. Информационные потоки процесса синтеза программной системы.  16 Модель анализа:  Информационная;  Функциональная;  Поведенческая. Этап проектирования Процедурная Разработка Разработка разработка архитектуры данных Этап кодирования Процедурные модули Этап тестирования Проверенная и объединённая ПС Информационная модель описывает информацию, которую должна обрабатывать ПС. Функциональная модель определяет перечень функций обработки. Поведенческая модель фиксирует режимы работы ПС. Разработка данных – результат преобразования информационной модели анализа в структуры данных. Разработка архитектуры выделяет основные структурные компоненты и фиксирует связи между ними. Процедурная разработка описывает последовательность действий структурных компонентов(их содержание).  17 На проектирование, кодирование и тестирование приходится более 75% стоимости конструирования ПС. Решение, принимаемое в ходе проектирования, делают его стержневым этапом процесса синтеза. Особенности этапа проектирования. Выделяют две ступени: 1. Предварительное. 2. Детальное. 1. Предварительное проектирование обеспечивает : 1) Идентификацию подсистем; 2) Определение основных принципов управления подсистема-ми, взаимодействие подсистем. Предварительное проектирование включает три типа деятельности:  I.Структурирование системы (система разбивается на несколько подсистем – независимых программных компонентов. Определяется взаимодействие подсистем);  II.Моделирование управления.(Определяется модель связей управления между подсистемами);  III.Декомпозиция подсистем на модули.(Определение типов модулей и межмодульных соединений) Информационные связи процесса проектирования. Требования Предварительное Архитектура Детальное Структура проектирование программ и проектирование данных и данных алгоритм программ Характеристики , формы Интерфейсное человеко-машинного проектирование взаимодействия на выход I.Структурирование систем. Известны 4 модели системного структурирования: I. Модель хранилища данных. Редактор Генератор Проектный проекта кода транслятор Хранилище данных проекта Редактор Анализатор программы проекта  18 В данной модели подсистемы разделяют данные находящиеся в общей памяти. Как правило данные образуют базы данных.Предусматривается система управления этой базой. II.Модель клиент – сервер. Клиент 1 Клиент 2 Клиент 3 Клиент N Сеть (Протокол взаимодействий TCP/IP) Сервер Видео- Сервер Сервер каталога -сервер картинок гипер- текстов Данная модель используется для распределения систем,где данные распределены по серверам. III. Трёхуровневая модель. (Развитие модели клиент – сервер) Графический интерфейс пользователя Бизнес - логика Реляционная СУБД Уровень графического интерфейса запускается на машине клиента. Бизнес – логику образуют модули осуществляющие функциональные обязанности подсистемы. Этот уровень запускается на сервере приложения. Реляционная СУБД хранит данные необходимые уровню бизнес – логики. Этот уровень запускается на втором уровне - сервере базы данных(БД). Преимущества трёхуровневой модели:  Упрощается такая модификация уровня, которая не влияет на другие уровни;  19  Отделение прикладных функций от функций управления БД, упрощает оптимизацию всей системы. IV. Модель абстрактной машины. Это многослойная система, при этом каждый текущий слой реализуется с использованием средств обеспечиваемых слоем фундамента. Управление версиями Управление объектом СУБД ОС II.Моделирование управления. Известно два типа моделей управления: I. Модель централизованного управления. II. Модель событийного управления. I. В этой модели одна подсистема выделяется как системный контроллер. Ёе обязанности – руководить работой других систем. Две разновидности:  Модель вызов – возврат. Главная программа Подпрограмма Подпрограмма 1 2 Подпрограмма Подпрограмма Подпрограмма 1.1 1.2 2.1 Подпрограмма 1.1.1  20  Модель менеджера. Она используется в системах параллельной обработки. Процессы- Процессы- -датчики -исполнители Системный контроллер Вычислительные Пользовательский Процессы- процессы интерфейс -обработчики отказов II. Здесь системой управляют внешние события. Две разновидности:  Широковещательная модель. Каждая подсистема уведомляет обработчика о своём интересе к конкретным событиям. Когда событие происходит, обработчик пересылает его подсистеме, которая может обработать это событие. Функции управления в обработчик не встраиваются. Подсистема Подсистема Подсистема 1 2 N Обработчик событий и сообщений  Модель управляемая прерываниями. Здесь все прерывания разбиты на группы – Типы прерываний, которые образуют вектор прерываний. Для каждого типа прерывания есть свой обработчик.Каждый обработ- чик реагирует на свой тип прерывания и запускает свой процесс.  21 Прерывания Вектор В Вектор прерывания Обработчик 1 Процесс 1 III.Декомпозиция подсистем на модули. Модульность. Известны два типа моделей модульной декомпозиции: 1) Модель потока данных(в основе лежит разбиение по функциям); 2) Модель объектов.(Эта модель основана на слабо сцеплённых единицах имеющих собственные наборы данных состояния и наборы операций). Выбор типа декомпозиции зависит от сложности разбиваемой подсисте- мы. Модуль – фрагмент программного текста являющийся строительным блоком для физической структуры системы. Модуль состоит из интер- фейсной части и части реализации. Модульность – свойство системы, ко- торая может подвергаться декомпозиции на ряд внутренне связанных и слабо зависящих друг от друга модулей. X – Проблема C(X) – Сложность решения проблемы X T(X) – Затраты на решение X Пусть p1,p2 – Проблемы C(p1) > C(p2) => T(p1) > T(p2) C(p1+p2) > C(p1) + C(p2) -из практики решения проблем человека T(p1+p2) > T(p1) + T(p2) Таким образом сложную проблему легче решить разделив её на управляемые части. Это аргумент в пользу модульности. В данном случае не учитываются затраты на межмодульный интерфейс.  22 Стоимость Стоимость Общая стоимость интерфейса Стоимость одного модуля Количество Область min стоимости модулей Нет корректного критерия для гарантированного предсказания точки оптимума. Оптимальный модуль должен удовлетворять двум критериям: 1) Снаружи он проще чем внутри; 2) Его проще использовать чем построить. Информационная закрытость. Принцип информационной закрытости. Содержание модулей должно быть скрыто друг от друга. 1) Информационная закрытость означает все модули независимы, об- мениваются только информацией необходимой для работы; 2) Доступ к операциям и структурам данных модуля ограничен. Достоинства инф.закрытости: 1)Обеспечивается возможность разработки модулей различными независимыми коллективами. 2)Обеспечивается лёгкая модификация системы. Характеристики модуля. 1. Связность модуля(внутренняя характеристика модуля) – это мера независимости его частей. Чем выше связность модуля, тем выше результат проектирования. Для обозначения связности модуля используют понятие силы связности модуля. Связность-это внутренняя характеристика модуля.  23 Связность Сила связности Функциональная связность. 1.функциональная 10 Этот модуль не может быть разбит на два 2.последовательная 9 других, имеющих связность того же типа. 3.коммуникативная 7 Критерий для формирования функциональной 4.процедурная 5 5.временная 3 связности: возможность формулировки 6.логическая 1 назначения модуля в виде одного предложения в 7.по совпадению 0 повелительном наклонение, без запятых и слов: если, затем, тогда. Пример: Проверить строку символов. Выделить однотипные поля данных. Оптимизировать группу команд. 2. Последовательная или информационная связность. Этот модуль может быть разбит на последовательные части, выполняющие независимые функции, но совместно реализующие единственную функцию. Пример: Если модуль используется для оценки, потом для обработки данных, то он имеет последовательную связность. Он реализуется как последовательность операций (циклов). При этом данные на выходе какой-либо функции целиком являются входными для следующей функции. Сопровождать модули с информационной связностью также легко, как и с функциональной, но возможности повторного использования модуля ниже, чем в 1-м случае, т.к. совместное применение действия модуля с информационной связностью полезно не всегда. 3. Коммуникативная связность. Части модуля связаны по данным (работают с одной же структурой данных). Пример: Модуль отчёт о средней зарплате Используется таблица зарплаты служащих Сгенерировать отчёт по зарплате Вычислить параметр средней зарплаты Вернуть отчёт по зарплате, средней зарплате КОНЕЦ Модуля. Все элементы модуля работают со структурой “таблица зарплат служащих”. С точки зрения клиента проблема применения коммуникативно-связного модуля состоит в избыточности результата. Общее у модулей с коммуникативной и информационной связностью: 1. Модули содержат элементы, связанные по данным. 2. Их удобно использовать, т.к. не многие элементы связаны со внешней средой. Различия:  24 Информационно связанный модуль работает подобно сборочной линии, т.е. важен порядок действий. В коммуникативно-связном модуле порядок безразличен. 4. Процедурная связность. Части модуля связаны порядком выполняемых ими действий, реализующих некоторый сценарий поведения. Зависимости по данным между элементами нет. Пример: Модуль вычисления средних значений Используется таблица А, затем таблица В Вычислить среднее по таблице А Вычислить среднее по таблице В Вернуть среднее по А и по В Конец модуля. Этот модуль обрабатывает две полностью несвязанных таблицы. Действия программиста с целью минимизации кода используют один цикл в интересах двух обработчиков. Пример: Модуль вычисления средних значений Используем таблицу А, таблицу В Сумма таблицы А:=0 Сумма таблицы В:=0 Для i:=0, то 300 Сумма А: = сумма А + сумма А(i) Сумма В: = сумма В + сумма В(i) Среднее таблицы А: = сумма А/300 Среднее таблицы В: = сумма В/300 Вернуть среднее таблиц А и В Конец модуля. На уровне реализации код этого модуля стал зависимым. Продукт сдали заказчику. Спустя время возникла задача сопровождения – модифицировать модуль под уменьшение таблицы В. 5. Временная связность. Части модуля не связаны, но необходимы в один и тот же период работы системы. Недостаток: Сильная взаимная связь с другими модулями. Поэтому сильна чувствительность к внесению изменений. Пример: Модуль инициализировать систему Перемотать магнитную ленту 1  25 Счетчик магнитной ленты 1:=0 Перемотать магнитную ленту 2 Счетчик магнитной ленты 2:=0 Таблица текущих записей :=_ _ Таблица количества записей :=0…0 Переключатель 1: = выкл Переключатель 2: = вкл Конец модуля. Элементы этого модуля почти несвязны друг с другом, но все они более тесно взаимодействуют с другими модулями, что приводит к сложным внешним связям. Если программист соблазняется возможностью совместного использования кода, то модуль становится трудно использовать повторно. Процедурно – связные модули и временные связные похожи, т.к. трудно объявить организацию такого модуля без перечисления внутренних деталей. Различия: Порядок выполнения действий более важен в процедурно – связных модулях. Кроме того, процедурно – связные модули имеют тенденцию к совместному использованию циклов и ветвлений, а модули временной связности чаще содержат линейный код. 6. Логическая связность. Части модуля объединены по принципу функционального подобия. Например, модуль состоит из разных программ обработки ошибок. При каком использовании этого модуля клиент выбирает только одну из подпрограмм? Недостаток: 1) сложность сопровождения 2) большая вероятность внесения ошибок при изменении сопряжения ради одной из функций. Пример: Модуль пересылка сообщения Переслать по электронной почте Переслать по факсу Послать в телеконференцию Переслать по FTP-протоколу Конец модуля. Здесь действия попадают в одну категорию, хотя имеют не только сходства, но и различия. К сожалению, эти соблазны программиста использовать общий код действия, приводят: 1) к уродливому внешнему виду модуля с разными параметрами, обеспечивающими несколько видов доступа 2) к запутанной внутренней структуре со множеством переходов. Таким образом, модуль становится сложным как для понимания, так и для сопровождения.  26 7. По совпадению. В модуле отсутствуют явно выраженные внутренние связи. Элементы данного модуля не имеют никаких отношений друг с другом. Пример: Модуль Разные функции (параметры) Поздравить с Новым годом (кого-то) Проверить исправность аппаратуры(…) Заполнить анкету героя (…) Измерить температуру (…) Вывести собаку на прогулку (…) Запастись продуктами (…) Приобрести «Jaguar» (…) Конец модуля. Элементы действий не связаны ни потоком данных, ни потоком управления. Данный модуль имеет все недостатки логически связанных модулей, и даже усиливает их. Связность по совпадению встречается редко. Причины возникновения: 1) бездумный перевод существующего монолитного кода в модули 2) необоснованные изменения модулей, плохой (обычно временной) связностью, приводящие к добавлению флажков, переключателей. Сцепление модулей. Это мера взаимозависимости модулей по данным; это внешняя характеристика, которую желательно уменьшить. Количественно сцепление измеряется степенью сцепления. Типы сцепления: 1. Сцепление по данным (внеш.хар-ка) СЦ=1 (сила сцепления) Модуль А вызывает модуль В. А элементы данных Все входные и выходные параметры вызываемого модуля – простые элементы данных. В 2. Сцепление по образцу СЦ=3 А В А структура данных В качестве параметров используются флаг структуры данных. В флаг В 3. Сцепление по управлению. СЦ=4 флаг выход  27 Модуль А явно управляет функционированием модуля В (с помощью флагов или переключателей), посылая ему управляющие данные. 4. Сцепление по внешним ссылкам. СЦ=5 Модули А и В ссылаются на один и тот же глобальный элемент данных. 5. Сцепление по общей области. СЦ=7 Модули разделяют одну и ту же глобальную структуру данных. С Структура данных Е N 6. Сцепление по содержанию. СЦ=9 Один модуль прямо ссылается на содержание другого модуля (не через его точку входа). Например, коды их команд перемежаются друг с другом (Sin и Cos сдвинуты на 90). Сложность программной системы. По Холстеду сложность программной системы оценивается мерой длины модуля. N=n1*log 2 (n1) + n2*log 2 (n2) N – Длина модуля n1 – Число различных операторов n2 – Число различных операндов Вторая характеристика – объём модуля. V – Количество символов для записи операторов и операндов текста модуля. V=N*log 2 (n1+n2) Том Мак Кейб в качестве характеристики сложности программы предложил использовать топологию внутренних связей. Для этого была разработана метрика цикломатической сложности. V(G)=E-N+2 E – Количество дуг N – Количество вершин в управляющем графе программной системы  28 Таким образом при комплексной оценке сложности программной системы необходимо рассматривать: 1) Меру сложности модулей; 2) Меру сложности внешних связей; 3) Меру сложности внутренних связей. На основе полных коэффициентов функциональных модулей вычисляется метрика общей сложности структуры. m Высота depth n Рис.17 ширина n 2 S=  length(i) *(Fan_in(i)+Fan_out(i)) (*) i 1 length(i) – Оценка размера i-ого модуля Fan_in(i) – Коэффициент объединения по входу(Количество управляющих i-ым модулем модулей) Fan_out(i) – Коэффициент разветвления по выходу(Количество модулей,ко- торыми прямо управляет i-ый модуль) Характеристики йерархической структуры программной системы.(рисунок 17) Высота Depth Fan_in(n)=2 Fan_out(m)=3  29 Рассмотрим основные характеристики йерархической структуры,представ- ленной на рисунке. Первыми характеристиками являются количество вершин (модулей) и коли- чество рёбер (связей между модулями).К ним добавляются две глобальные харак- теристики – высота и ширина:  Высота – количество уровней управления;  Ширина – максимальное из количеств модулей,размещённых на уров- нях управления. В нашем примере высота = 3,ширина = 3. Локальными характеристиками модулей структуры являются коэффициент объединения по входу и коэффициент разветвления по выходу (Fan_in(i) и Fan_out(i) ). В примере для модуля n: Fan_in(n)=2 ;для модуля m: Fan_out(m)=3. Возникает вопрос:как оценить качество структуры? Из практики проекти- рования известно,что лучшее решение обеспечивается йерархической структурой в виде дерева. Степень отличия реальной проектной структуры от дерева характеризуется невязкой структуры(Nev). Значение невязки лежит в диапазоне от 0 до 1.Если Nev = 0,то проектная структура является деревом,если Nev = 1,то проектная структура – полный граф. Ясно,что невязка даёт грубую оценку структуры.Для увеличения точности оценки следует применить характеристики связности и сцепления. Хорошая структура должна иметь низкое сцепление и высокую связность. Л.Констентайн и Э.Йордан (1979) предложили оценивать структуру с помо- щью коэффициентов Fan_in(i) и Fan_out(i) модулей. Большое значение Fan_in(i) – свидетельство высокого сцепления,так как является мерой зависимости модуля.Большое значение Fan_out(i) говорит о высо- кой сложности вызывающего модуля.Причиной является то,что для координации подчинённых модулей требуется сложная логика управления. Основной недостаток коэффициентов Fan_in(i) и Fan_out(i) состоит в игно- рировании веса связи.Здесь рассматриваются только управляющие потоки (вызо- вы модулей).В то же время информационные потоки,нагружающие рёбра структу- ры,могут существенно изменяться,поэтому нужна мера,которая учитывает не только количество рёбер,но и количество информации,проходящей через них. С.Генри и Д.Кафура (1981) ввели информационные коэффициенты ifan_in(i) и ifan_out(j).Они учитывают количество элементов и структур данных,из которых i-й модуль берёт информацию и которые обновляются j-м модулем соответствен- но. Информационные коэффициенты суммируются со структурными коэффи- циентами sfan_in(i) и sfan_out(j),которые учитывают только вызовы модулей. В результате формируются полные значения коэффициентов: Fan_in(i)= sfan_in(i)+ifan_in(i), Fan_out(j)=sfan_out(j)+ifan_out(j).  30 На основе полных коэффициентов модулей вычисляется метрика общей сложности структуры: Формула (*). Программная документация. Она должна быть организована так, чтобы легко была доступна информация по отдельным модулям. Список модулей, описание программы и иерархической схемы используется как справочник. Модули должны быть пронумерованы (обычно в соответствии с их иерархической упорядоченностью). Главный модуль Схема модульной структуры программы должна быть дополнена описанием внешних характеристик 1 2 3 модулей. Оно называется внешней спецификацией и содержит все 2.1 2.2 сведения, необходимые для обращения к модулю. 2.2.1 2.2.2 2.2.3 На основе внешней спецификации модулей осуществляется разработка логической структуры этих модулей. Логическая структура модуля прорабатывается на стадии технического проекта программы. Внешняя спецификация модуля должна включать: 1. Имя модуля, используемое при обращении к нему. 2. Описание функции, здесь приводится назначение модуля, но оно не должно содержать сведений о логической структуре и о контекстах, в которых используется модуль. 3. Список параметров: число и порядок задания параметров. 4. Входные параметры: подробное описание и их атрибуты (структура, размер, единица измерения, допустимый диапазон назначений, типы и т.д.). 5. Выходные параметры (аналогично п.4). 6. Внешние эффекты. Например: печать сообщений, чтение запроса с монитора, вывод сообщений об ошибке. Внешние эффекты модуля включают все внешние эффекты подчинённых ему модулей. Средства проектирования прикладных программ. 1. Графическое построение схем алгоритмов программ. ГОСТ 19.002 – 80 года 19.003 - 80 Применяется ограниченно это средство проектирования, вследствие недостатков: 1) высокая трудоёмкость вычерчивания схем;  31 2) отсутствие графических средств для отображения структур данных; 3) не отражает особенностей конструкций конкретных языков программирования; 4) потеря наглядности при большом количестве блочных символов. 2. Разработка схем алгоритмов программ с использованием конкретного языка программирования. Недостатки: 1) современные языки программирования не обладают наглядными средствами для описания алгоритмов; 2) требуют использования многих второстепенных языковых конструкций, которые затрудняют понимание общих принципов построения алгоритма. 3. Использование специальных языков проектирования программ, псевдокодов. Псевдокод – это частично формализованная запись для наглядного текстового представления схем алгоритмов и программ, разрабатываемая в соответствии с общими принципами структурного программирования. Псевдокод используется в следующих целях: 1. для фиксации с нужным уровнем детализации алгоритма в процессе его разработки; 2. для формулировки заданий на кодирование программы на языке программирования; 3. для описания логики программы. Достоинство псевдокода: Состоит в том, что он освобождает программиста от необходимости следить за точным соблюдением формальных языковых правил, позволяет ему максимально концентрировать внимание на содержании решаемых логических проблем. Основные элементы языка псевдокода: 1. Алфавит: строчные, прописные буквы латиницы и кириллицы, специальные символы, цифры 2. Идентификаторы: имена. 3. Ключевые слова: используются для обозначения операторов и конструкций языка. При написании их желательно подчеркивать. 4. Константы: символьные и другие. 5. Комментарии: могут располагаться в любом месте текста, отделяются от него знаками «-». Реализация программ. Основные методы программирования: 1. Программирование на языках высокого уровня (ЯВУ). 2. Программирование с защитой от ошибок. 3. структурное программирование. 4. Программирование в стандартизированном стиле. 5. Нисходящее программирование.  32 1. Программирование на языках высокого уровня: По сравнению с языками низкого уровня. 1. Чем выше уровень языка программирования, тем меньше ошибок в программе, легче понимать программу. 2. Выше степень автоматического обнаружения ошибок компилятором с этих языков. 3. Большая наглядность программы, что позволяет упростить документирование. 4. Программа на ЯВУ обладает высокой переносимостью. 5. Эти программы менее эффективны. ВЫВОД: Основные резервы эффективности программ лежат в области разумного выбора методов и алгоритмов. 2. Программирование с защитой от ошибок. Подключение в программу дополнительных операторов контроля данных уменьшает вероятность появления ошибочных ситуаций при работе программы: Виды проверок:  допустимость значений числовых аргументов;  проверка допустимости типов данных в выражении;  проверка допустимости значений индексов массивов;  допустимости значений управляющих переменных;  проверка операций ввода-выв?