Спецификация качества программного средства.
Разработка спецификации качества сводится, по существу, к построению своеобразной модели качества требуемого ПС. В этой модели должен быть перечень всех тех достаточно элементарных свойств, которые необходимо обеспечить в требуемом ПС и которые в совокупности образуют приемлемое для пользователя качество ПС.
Для конкретизации качества ПС по каждому из критериев используется стандартизованный набор достаточно простых свойств ПС. Такие свойства мы будем называть примитивами качества ПС.
Зависимость критериев качества от примитивов качества ПС:
Функциональность: завершенность.
Надежность: завершенность, точность, автономность, устойчивость, защищенность.
Легкость применения: П-документированность, информативность (только применительно к документации по применению), коммуникабельность, устойчивость, защищенность.
Эффективность: временнáя эффективность, эффективность по ресурсам (по памяти), эффективность по устройствам.
Сопровождаемость. С данным критерием связано много различных примитивов качества. Однако их можно распределить по двум группам, выделив два подкритерия качества: изучаемость и модифицируемость. Изучаемость это характеристики ПС, которые позволяют минимизировать усилия по изучению и пониманию программ и документации ПС.- Модифицируемость - это характеристики ПС, которые позволяют автоматически настраивать на условия применения ПС или упрощают внесение в него вручную необходимых изменений и доработок.
Изучаемость: С-документированность, информативность (здесь применительно к документации по сопровождению), понятность, структурированность, удобочитаемость.
Модифицируемость: расширяемость, модифицируемость (в узком смысле, как примитив качества), структурированность, модульность.
Мобильность: независимость от устройств, автономность, структурированность, модульность.
Функциональная спецификация программного средства.
Она должна базироваться на понятиях, построенных как математические объекты, и утверждениях, однозначно понимаемых разработчиками ПС.
Функциональная спецификация состоит из трех частей:
· описания внешней информационной среды, к которой должны применяться программы разрабатываемой ПС: должны быть определены на концептуальном уровне все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами.;
· определение функций ПС, определенных на множестве состояний этой информационной среды (такие функции будем называть внешними функциями ПС): вводятся обозначения всех определяемых функций, специфицируются все входные данные и результаты выполнения каждой определяемой функции, включая указание их типов и заданий всех соотношений (или ограничений), которым должны удовлетворять эти данные и результаты.;
· описание нежелательных (исключительных) ситуаций, которые могут возникнуть при выполнении программ ПС, и реакций на эти ситуации, которые должны обеспечить соответствующие программы: должны быть перечислены все существенные случаи, когда ПС не сможет нормально выполнить ту или иную свою функцию (с точки зрения внешнего наблюдателя).
Методы контроля внешнего описания программного средства.
Разработка внешнего описания обязательно должна завершаться проведением тщательного и разнообразного контроля правильности внешнего описания. Целью этого процесса является найти как можно больше ошибок, сделанных на этом этапе.
Методы контроля, применяемые на этом этапе:
- статический просмотр-- внимательное прочтение текста внешнего описания разработчиком с целью проверка его полноты и непротиворечивости,
- смежный контроль-- контроль спецификации качества сверху разработчика требований к ПС, а смежный контроль функциональной это ее проверка разработчиками требований к ПС и-спецификации это-спецификации качества,
- пользовательский контроль-- выражает участие пользователя (заказчика) в принятии решений при разработке внешнего описания и его контроле,
- ручная имитация-- выражает своеобразный динамический контроль внешнего описания, точнее говоря, функциональной спецификации ПС.
Понятие архитектуры программного средства.
Известно, что технологический цикл конструирования программной системы (ПС) включает три процесса — анализ, синтез и сопровождение.
В ходе анализа ищется ответ на вопрос: «Что должна делать будущая система?».
В процессе синтеза формируется ответ на вопрос: «Каким образом система будет реализовывать предъявляемые к ней требования?». Выделяют три этапа синтеза: проектирование ПС, кодирование ПС, тестирование ПС (рис. 4.1).
Этап проектирования: Информационная модель описывает информацию, которую, по мнению заказчика, должна обрабатывать ПС. Функциональная модель определяет перечень функций обработки. Поведенческая модель фиксирует желаемую динамику системы (режимы ее работы). На выходе этапа проектирования — разработка данных, разработка архитектуры и процедурная разработка ПС.
Разработка данных — это результат преобразования информационной модели анализа в структуры данных, которые потребуются для реализации программной системы.
Разработка архитектуры выделяет основные структурные компоненты и фиксирует связи между ними.
Процедурная разработка описывает последовательность действий в структурных компонентах, то есть определяет их содержание.
Далее создаются тексты программных модулей, проводится тестирование для объединения и проверки ПС.
13. Основные классы архитектур программных средств.
Различают следующие основные классы архитектур программных средств [1]:
· цельная программа;
· комплекс автономно выполняемых программ;
· слоистая программная система;
· коллектив параллельно выполняемых программ.
Цельная программа представляет вырожденный случай архитектуры ПС: в состав ПС входит только одна программа. Такую архитектуру выбирают обычно в том случае, когда ПС должно выполнять одну какую-либо ярко выраженную функцию и её реализация не представляется слишком сложной.
Комплекс автономно выполняемых программ состоит из набора программ, такого, что:
· любая из этих программ может быть активизирована (запущена) пользователем;
· при выполнении активизированной программы другие программы этого набора не могут быть активизированы до тех пор, пока не закончит выполнение активизированная программа;
· все программы этого набора применятся к одной и той же информационной среде.
Слоистая программная система состоит из некоторой упорядоченной совокупности программных подсистем, называемых слоями, такой, что:
· на каждом слое ничего не известно о свойствах (и даже существовании) последующих (более высоких) слоёв;
· каждый слой может взаимодействовать по управлению (обращаться к компонентам) с непосредственно предшествующим (более низким) слоем через заранее определенный интерфейс, ничего не зная о внутреннем строении всех предшествующих слоёв;
· каждый слой располагает определенными ресурсами, которые он либо скрывает от других слоев, либо предоставляет непосредственно последующему слою (через указанный интерфейс) некоторые их абстракции.
Коллектив параллельно действующих программ представляет собой набор программ, способных взаимодействовать между собой, находясь одновременно в стадии выполнения.
Архитектурные функции.
В ряде случаев для обеспечения взаимодействия между программными подсистемами может потребоваться создание дополнительных программных компонент. Так для управления работой комплекса автономно выполняемых программ часто создают специализированный командный интерпретатор, более удобный в данной предметной области для подготовки требуемой внешней информационной среды и запуска требуемой программы, чем базовый командный интерпретатор используемой операционной системы. В слоистых программных системах может быть создан особый аппарат обращения к процедурам слоя (например, обеспечивающий параллельное выполнение этих процедур). В коллективе параллельно действующих программ для управления портами сообщений требуется специальная программная подсистема. Такие программные компоненты никаких внешних функций не выполняют — они реализуют функции, возникшие в результате разработки архитектуры программного средства. В связи с этим такие функции мы будем называть архитектурными.