
- •Этапы развития технологии программирования
- •1). «Стихийное» программирование (до середины 60х гг.).
- •2). «Структурный» подход к программированию (60е – 70е гг.).
- •3). Объектный подход (середина 80-х – конец 90х гг.).
- •Компонентный подход к программированию и case-технологии.
- •Платформа .Net
- •Проблемы разработки сложных программных систем
- •Блочно-иерархический подход к созданию сложных систем
- •Жизненный цикл и этапы разработки программного обеспечения
- •Модели жизненного цикла программного обеспечения
- •Модели с промежуточным контролем.
- •Понятия эффективности и технологичности программного обеспечения.
- •Модули и их свойства (сцепление модулей).
- •Модули и их свойства (связность модулей)
- •Нисходящая и восходящая разработка программного обеспечения
- •Структурное программирование.
- •Линейный, 2)разветвляющий, 3) цикличный.
- •Средства описания структурных алгоритмов (псевдокоды, блок-схемы алгоритмов, Flow-формы, диаграммы Насси-Шнейдермана).
- •Правила оформления программ
- •Этап постановки задачи. Классификация программных продуктов по функциональному признаку.
- •Этап постановки задачи. Основные эксплуатационные требования к программным продуктам.
- •Этап постановки задачи. Предпроектные исследования предметной области.
- •Разработка технического задания.
- •Принципиальные решения начальных этапов проектирования (выбор архитектуры программного обеспечения, выбор пользовательского интерфейса, выбор языка программирования и т.Д.).
- •2) Выбор типа пользовательского интерфейса.
- •3) Выбор подхода к разработке.
- •4) Выбор языка программирования.
- •Классификация моделей разрабатываемого программного обеспечения
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Диаграммы переходов состояний.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Функциональные диаграммы.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Диаграммы потоков данных.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Структуры данных и диаграммы отношений компонентов данных.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Сетевая модель данных (Диаграммы «сущность-связь»)
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Математические модели.
- •Проектирование программного обеспечения при структурном подходе. Структурная и функциональная схемы.
- •Метод пошаговой детализации при проектировании структуры по
- •Структурный подход. Структурные карты Константайна
- •Проектирование программного обеспечения при структурном подходе. Проектирование структур данных
- •Модель использования. Определение вариантов использования. Диаграммы вариантов использования.
- •Построение диаграммы классов на этапе анализа технического задания.
- •Диаграмма последовательностей системы.
- •Построение диаграммы деятельности на этапе анализа технического задания.
- •Проектирование по при объектном подходе.
- •Диаграмма пакетов.
- •Диаграмма классов этапа проектирования. Уточнение отношений между классами на этапе проектирования.
- •Диаграммы последовательностей этапа проектирования.
- •Диаграммы состояний объекта
- •Диаграмма деятельности на этапе проектирования.
- •Диаграмма компонентов
- •Диаграмма размещения
- •Тестирование программных продуктов.
- •Структурное тестирование.
- •Функциональное тестирование.
- •Восходящее и нисходящее тестирование
- •Классификация ошибок
- •Методы отладки программного обеспечения
Модули и их свойства (связность модулей)
Результатом процедурной декомпозиции является иерархия процедур, в которой функции, связанные с принятием решения, реализуются с подпрограммами верхних уровней, а непосредственная обработка с подпрограммами нижних уровней. Это согласуется с принципом вертикального управления. Результатом объектной декомпозиции является совокупность объектов, которые затем реализуют, как переменные некоторых классов. Таким образом, при любой декомпозиции получают набор связанных соответствующими данными подпрограмм, которые в процессе реализации организуют модули. Модулем называют автономно компилируемую программную единицу. Термин модуль используется в двух смыслах:
когда размер программы был невелик, и все подпрограммы компилировались отдельно, под модулем понималась подпрограмма.
когда размер программы вырос, появилась возможность создавать библиотеки, термин модуль стал использоваться и в смысле автономно компилируемого набора программных ресурсов. Данный модуль можно получать и/или возвращать через общие области памяти или параметры.
Первоначально к модулям (подпрограммы) предъявлялись требования: одна точка входа, одна точка выхода, отдельно компиляция, возможность вызова других модулей, соответствие принципу вертикального управления, выполнение одной функции, небольшой размер, независимость от истории вызовов. Со временем, когда основные требования структурного подхода стали поддерживаться языком программирования и под модулем стали понимать 2), то требование независимости модулей стало основными. Практика показала, чем выше степени независимости модулей, тем меньше вероятность появления новых ошибок при исправлении старых или внесении изменений в программу (волновой эффект). Проще организовать разработку ПО группой и легче его сопровождать.
Связность модулей
Связность – это мера прочности соединения функциональных и информационных объектов внутри одного модуля. Если сцепление характеризует качество отделения модулей, то связность характеризует степень взаимосвязи элементов, реализуемых одним модулем.
Размещение сильно связанных элементов в одном модуле уменьшает межмодульные связи, то есть взаимное влияние модулей. Помещение сильно связанных элементов в разные модули усиливает межмодульные связи и усложняет понимание их взаимодействия. Объединение слабо связанных элементов также уменьшает технологичность модуля. Виды связности (в порядке убывания уровня):
Функциональная
Последовательная
Информационная (коммуникативная)
Процедурная
Временная
Логическая
Случайная
1). Все объекты модуля предназначены для выполнения одной функции: операции, объединяемые для выполнения одной функции, или данные, связанные с одной функцией.
Р
ис.2.1.
Связность одной функции.
Модуль, элементы которого связаны функционально, имеют четко определенную цель, при его вызове выполняется одна задача. Связность такого модуля максимальна, хорошие технологические качества: простота тестирования, модификации. Поэтому следует избегать неструктурированного распределения функций между модулями – библиотеками ресурсов.
2). Выход одной функции служит исходными данными для другой функции.
Р
ис.2.2.
Обычно такой модуль имеет одну точку входа, то есть реализует подпрограмму, реализующую две функции. Считают, что данные, используемые функциями, также связаны последовательно. Модуль можно разбить на два или более модуля, как с последовательной, так и с функциональной связью. Так как модуль выполняет несколько функций, его технологичность хуже.
3). Информационно связанным считают функции, обрабатывающие одни и те же данные. При использовании структурных языков программирования раздельное выполнение функций можно осуществить, если каждая функция выполняется своей подпрограммой.
Р
ис.2.3.
Имеет неплохие показатели технологичности, так как все функции, работающие с некоторыми данными, собраны в одно место, что при изменении формата данных изменять один модуль. Информационно связанными считаются данные, которые обрабатываются одной функцией.
4). Процедурно связаны функции или данные, которые являются частями одного процесса.
Рис.2.4.
О
бычно
такие модули получают, если в модули
объединены функции альтернативных
частей программы. Отдельные элементы
модуля связаны слабо, то есть реализуемые
ими действия связаны общим процессом.
Технологичность ниже.
5
).
Временная связность функций подразумевает,
что эти функции выполняются параллельно
или в течение некоторого времени.
Рис.2.5.
В
ременная
связность данных означает, что они
используются в некотором временном
интервале. Например, временную связность
имеют функции, выполняемые при
инициализации некоторого процесса.
Особенность временной связности в том,
что действия, реализуемые такими
функциями, обычно могут выполняться в
любом порядке. Содержание такого модуля
имеет тенденцию меняться: в него могут
включаться новые и/или исключаться
старые действия. Большая вероятность
модификации функций уменьшает показатели
технологичности.
6). Логическая связность базируется на объединении данных или функций в одну логическую группу.
Пример – функции обработки текстовой информации или данные одного и того же типа. Модуль с логической связностью функций часто реализует альтернативные операции.
7). Если связь между элементами мала или отсутствует, то они имеют случайную связность. Такие модули имеют самый низкий показатель технологичности.
Вид связности |
Сцепление (балл) |
Наглядность (понятность) |
Возможность изменения |
Сопровождаемость |
1). Функциональная |
10 |
Хорошая |
Хорошая |
Хорошая |
2). Последовательная |
9 |
Хорошая |
Хорошая |
Хорошая |
3). Информационная |
8 |
Средняя |
Средняя |
Средняя |
4). Процедурная |
5 |
Средняя |
Средняя |
Плохая |
5). Временная |
3 |
Средняя |
Средняя |
Плохая |
6). Логическая |
1 |
Плохая |
Плохая |
Плохая |
7). Случайная |
0 |
Плохая |
Плохая |
Плохая |
Обычно при хорошо продуманной декомпозиции модули верхних уровней иерархии имеют функциональную или последовательную связность функций и данных. Для модулей обслуживания данных характерна информационная связность функций. Данные таких модулей могут быть связаны по-разному. Модули, содержащие описание классов при объектно-ориентированном подходе, характеризуются информационной связностью методов и функциональной связностью данных. Получение в процессе декомпозиции модулей с другими типами связности обычно означает недостаточно продуманное проектирование. Исключением являются библиотеки ресурсов.