- •Общее положение стандартов
- •Международные организации разрабатывающие стандарты
- •Технические комитеты по стандартизации
- •Стандарты регламентирующие термины и определения
- •Эволюция инструментального по
- •Руководство проектом разработки по
- •Планирование проектных задач
- •Функционально-ориентированные метрики
- •Компоненты интегрированного case средства
- •Качество по
- •Case-технологии
- •Общие характеристики качества
- •Структура стандарта iso “цифра”
- •Выбор показателей качества
- •Оценка качества
- •Функциональная пригодность
- •Оценка корректности программных средств
- •Система управления качества
- •Модели и метрики оценки качества по
- •Правила формирования потокового графа
- •Формальные методы
- •Использование новых языковых и проектных подходов
- •Недостатки стандартизации
- •Основы жизненного цикла программных средств
- •Раздел 6 - это вспомогательные процессы и работы, поддерживающие жц программных средств. Раздел 7 – организационные процессы и управление жц программных средств. Процессы Взять табличку!
- •Принципы тестирования
- •Методы тестирования программ
- •Особенности жц пс в исо 155-04
- •Процессы жц
- •Выгоды аттестации для покупателей и заказчиков
- •Внешнее проектирование программного изделия
- •Внутреннее проектирование
- •Характеристики внутренних и внешних связей модуля
- •Функциональная связанность
- •Сцепление
- •Комплексное тестирование
- •Стандартизация тестирования
- •Критерии завершенности тестирования
Внутреннее проектирование
Внутреннее проектирование начинается с изучения внешних спецификаций. К началу проектирования все спецификации должны быть согласованны с пользователем и не могут произвольно меняться разработчиком. Далее формируется структура программного изделия и общее правило взаимодействия компонентов. Программное изделие создается на основе модульно-иерархической структуры.
Модуль – это отдельное, функционально законченная функциональная единица, которая может применяться самостоятельно либо быть частью программы.
Модуль состоит из интерфейсной части и части реализации.
Модульность – свойство системы, которая может подвергаться декомпозиции на ряд внутренне связанных и слабозависящих друг от друга модулей.
Модуль обладает тремя основными признаками:
Реализует одну или несколько функций. Функция представляет собой внешнее описание действий, представляемых модулем, без указания того как эти действия производятся.
Модуль имеет определенную логическую структуры. Логика модуля определяет его внутренний алгоритм, т.е. то, как модуль выполняет функцию.
Модуль используется в одном или нескольких контекстах. Контекст описывает конкретное использование модуля.
С увеличением количества модулей увеличиваются затраты на межмодульный интерфейс. Таким образом, существует оптимальное количество модулей, которое приводит к минимальной стоимости разработки.
Оптимальный модуль должен удовлетворять двум критериям:
Снаружи - проще, чем внутри.
Проще использовать, чем построить.
Правильно спроектированный модуль должен удовлетворять принципам информационной закрытости, согласно которому, содержание модулей должно быть скрыто друг от друга.
Информационная закрытость означает следующее:
Все модули независимы.
Обмениваются только информацией, необходимой для работы.
Доступ к операциям и структурам данных модуля ограничены.
Достоинства реализации данного принципа:
Обеспечивается возможность разработки модуля различными независимыми коллективами.
Обеспечивается легкая модификация системы.
Идеальный модуль играет роль «черного ящика». Он прост в использовании, его легко развивать и корректировать в процессе сопровождения программной системы. Модуль должен удовлетворят определенным требованиям внутренних и внешних связей.
Характеристики внутренних и внешних связей модуля
Связность – внутренняя характеристика модуля, которая определяется как мера независимости его частей. Чем выше связанность модуля, тем лучше результат проектирования. Выделяют следующие типы:
Вид связности |
Сила связности |
|
0 |
|
1 |
|
3 |
|
5 |
|
7 |
|
9 |
|
10 |
Функциональная связанность
Функционально связанный модуль содержит элементы, участвующие в выполнении одной и только одной проблемной задачи. При вызове модуля, выполняется одна задача без привлечения внешних разработчиков. Несмотря на сложность модуля, его действие может представить как единую проблемную функцию с точки зрения клиента.
Информационная связность. Элементы обработчики модуля образуют конвейер для обработки данных. Данный вид связности приводит к более низким возможностям повторного использования.
Коммуникативная связность. Элементы обработчики модуля используют одни и те же данные. С точки зрения клиента проблема применения коммуникативно связанного модуля состоит в избыточности получаемых результатов.
Процедурно связанный модуль состоит из элементов, для которых задан порядок работы. Зависимости по данным между элементами нет.
Причина возникновения этих модулей. Такая структура модуля может возникнуть при разбиении длинной программы на части в соответствии передачами управления, но без определения функционального базиса.
Временная связность. При связности по времени обработчики модуля привязаны к конкретному периоду времени из жизни программной системы. Элементы данного модуля почти не связанны друг с другом, а более тесно взаимодействуют с другими модулями, что приводит внешним связям. В процедурно связных и в модулях с временной связностью трудно объявить функцию модуля без перечисления внутренних деталей. Процедурные модули имеют тенденцию к совместному использованию циклов и ветвлений. Модули с временной связностью чаще содержат линейный код.
Модуль с логической связностью. Элементы логического связанного модуля принадлежат к действиям одной категории и из этой категории клиент выбирает выполняемое действие. Логический модуль можно рассматривать как совокупность доступных действий, вынужденных использовать один и тот же интерфейс модуля. Недостатки логической связности:
Сложный малопонятный интерфейс с различными параметрами, обеспечивающими различные виды доступа.
Запутанная внутренняя структура с множеством переходов.
Для того, чтобы воспользоваться модулем связностью по совпадению, модуль должен быть «белым ящиком», чья реализация полностью видима.
Причины, приводящие к возникновению модулей со связностью «по совпадению»:
Бездумный перевод монолитного кода в модули.
Необоснованное изменению модулей с плохой связностью.
Группировка в отдельный модуль одинаковых последовательностей операторов, обнаруженных в нескольких модулях.
