
- •Этапы развития технологии программирования
- •1). «Стихийное» программирование (до середины 60х гг.).
- •2). «Структурный» подход к программированию (60е – 70е гг.).
- •3). Объектный подход (середина 80-х – конец 90х гг.).
- •Компонентный подход к программированию и case-технологии.
- •Платформа .Net
- •Проблемы разработки сложных программных систем
- •Блочно-иерархический подход к созданию сложных систем
- •Жизненный цикл и этапы разработки программного обеспечения
- •Модели жизненного цикла программного обеспечения
- •Модели с промежуточным контролем.
- •Понятия эффективности и технологичности программного обеспечения.
- •Модули и их свойства (сцепление модулей).
- •Модули и их свойства (связность модулей)
- •Нисходящая и восходящая разработка программного обеспечения
- •Структурное программирование.
- •Линейный, 2)разветвляющий, 3) цикличный.
- •Средства описания структурных алгоритмов (псевдокоды, блок-схемы алгоритмов, Flow-формы, диаграммы Насси-Шнейдермана).
- •Правила оформления программ
- •Этап постановки задачи. Классификация программных продуктов по функциональному признаку.
- •Этап постановки задачи. Основные эксплуатационные требования к программным продуктам.
- •Этап постановки задачи. Предпроектные исследования предметной области.
- •Разработка технического задания.
- •Принципиальные решения начальных этапов проектирования (выбор архитектуры программного обеспечения, выбор пользовательского интерфейса, выбор языка программирования и т.Д.).
- •2) Выбор типа пользовательского интерфейса.
- •3) Выбор подхода к разработке.
- •4) Выбор языка программирования.
- •Классификация моделей разрабатываемого программного обеспечения
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Диаграммы переходов состояний.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Функциональные диаграммы.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Диаграммы потоков данных.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Структуры данных и диаграммы отношений компонентов данных.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Сетевая модель данных (Диаграммы «сущность-связь»)
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Математические модели.
- •Проектирование программного обеспечения при структурном подходе. Структурная и функциональная схемы.
- •Метод пошаговой детализации при проектировании структуры по
- •Структурный подход. Структурные карты Константайна
- •Проектирование программного обеспечения при структурном подходе. Проектирование структур данных
- •Модель использования. Определение вариантов использования. Диаграммы вариантов использования.
- •Построение диаграммы классов на этапе анализа технического задания.
- •Диаграмма последовательностей системы.
- •Построение диаграммы деятельности на этапе анализа технического задания.
- •Проектирование по при объектном подходе.
- •Диаграмма пакетов.
- •Диаграмма классов этапа проектирования. Уточнение отношений между классами на этапе проектирования.
- •Диаграммы последовательностей этапа проектирования.
- •Диаграммы состояний объекта
- •Диаграмма деятельности на этапе проектирования.
- •Диаграмма компонентов
- •Диаграмма размещения
- •Тестирование программных продуктов.
- •Структурное тестирование.
- •Функциональное тестирование.
- •Восходящее и нисходящее тестирование
- •Классификация ошибок
- •Методы отладки программного обеспечения
Проблемы разработки сложных программных систем
Большинство современных программных систем объективно очень сложны. Эта сложность обусловлена многими причинами, главная из которых логическая сложность решаемых ими задач. Пока вычислительных машин было мало, их возможности были ограничены. ЭВМ применялись в узких областях науки и техники и основном там, где решаемые задачи были хорошо детерминированы и требовали больших вычислений. В настоящее время, когда созданы мощные компьютерные сети, появилась возможность переложить на них решение сложных ресурсоёмких задач. В процесс компьютеризации вовлекаются новые предметные области и усложняются постановки задач для уже освоенных областей.
Дополнительные факторы, увеличивающие сложность разработки программных систем:
1). Сложность форматного определения требований к программным системам.
2). Отсутствие удовлетворительных средств описания поведения дискретных систем с большим числом состояний при недетерминированной последовательности входных воздействий.
3). Коллективная разработка.
4). Необходимость увеличения степени повторяемости кодов.
Сложность определения требований обуславливается двумя факторами:
1). При определении требований необходимо учитывать большое количество различных факторов.
2) Разработчики программных систем не являются специалистами в автоматизируемых предметных областях и наоборот.
Вместе взятые эти факторы существенно увеличивают сложность процесса разработки. Очевидно, что они все напрямую связаны со сложностью объекта разработки программной системы.
Блочно-иерархический подход к созданию сложных систем
Большинство сложных систем в природе и технике имеет иерархическую внутреннюю структуру. Это связано с тем, что связи элементов сложных систем различны по типу и по силе, что позволяет рассматривать системы как совокупность взаимозависимых подсистем. Внутренние связи элементов таких подсистем сильнее, чем связи между подсистемами. Используя то же различие связей, каждую подсистему можно разделить на подсистемы и т.д. до самого нижнего «элементарного» уровня (выбор уровня, компоненты которого следует считать элементарными, остается за исследователем). На элементарном уровне система состоим из немногих типов подсистем, по-разному скомбинированных и организованных. Иерархии такого типа получили название «целое – часть».
Поведение системы в целом сложнее поведения отдельных частей, из-за более сильных внутренних связей особенности системы в основном обусловлены отношениями между ее частями, а не частями как таковыми.
В природе существует и иерархия «простое – сложное» или иерархия развития (усложнения) систем в процессе эволюции. Здесь любая функционирующая система является результатом развития более простой системы (данный вид иерархии реализуется механизмом наследования ООП).
Программные системы – отражение природных и технических систем – обычно являются иерархическими, т.е. обладают описанными выше свойствами. На этих свойствах иерархических систем строится блочно-иерархический подход к их исследованию или созданию. Этот подход предполагает сначала создавать части таких объектов (блоки, модули), а затем собирать из них сам объект.
Процесс разбиения сложного объекта на сравнительно независимые части называется декомпозицией. При декомпозиции учитывают, что связи между отдельными частями должны быть слабее, чем связи элементов внутри частей. Чтобы из полученных частей можно было собрать разрабатываемый объект, в процессе декомпозиции необходимо определить все виды связей частей между собой.
При создании сложных объектов процесс декомпозиции выполняется многократно: каждый блок декомпозируют на части, пока не получают блоки, которые сравнительно легко разработать. Такой метод разработки получил название пошаговой детализации.
В процессе декомпозиции стараются выделить аналогичные блоки, которые можно было бы разрабатывать на общей основе. Таким образом обеспечивают увеличение степени повторяемости кодов и, соответственно, снижение стоимости разработки.
Результат декомпозиции обычно представляют в виде схемы иерархии, на нижнем уровне которой располагают сравнительно простые блоки, а на верхнем – объект, подлежащий разработке. На каждом иерархическом уровне описания блоков выполняют с определенной точностью детализации, абстрагируясь от несущественных деталей. Следовательно, для каждого уровня используют свои формы документации и свои модели, отражающие сущность процессов, выполняемых каждым блоком. Для объекта в целом формулируют лишь самые общие требования, а блоки нижнего уровня олжны быть специфицированы так, чтобы из них можно было собрать работающий объект. Чем больше блок, тем более абстрактным должно быть его описание.
При соблюдении этого принципа разработчик сохраняет возможность осмысления проекта и может принимать наиболее правильные решения на каждом этапе, что называют локальной оптимизацией.
Итак, в основе блочно – иерархического подхода лежат декомпозиция и иерархическое упорядочение. Важную роль играют принципы:
непротиворечивость – контроль согласованности элементов между собой;
полнота – контроль на присутствие лишних элементов;
формализация – строгость методического подхода;
повторяемость – необходимость выделения одинаковых блоков для удешевления и ускорения разработки;
локальная оптимизация – оптимизация в пределах уровня иерархии.
Совокупность языков моделей, постановок задач, методов описаний некоторого иерархического уровня называют уровнем проектирования.
Каждый объект в процессе проектирования приходится рассматривать с нескольких сторон. Различные взгляды на объект проектирования называют аспектами проектирования.
Использование блочно-иерархического подхода:
делает возможным создание сложных систем;
упрощает проверку работоспособности системы в целом и отдельных блоков;
обеспечивает возможность модернизации систем, например, замены ненадежных блоков с сохранением их интерфейсов.
Использование блочно-иерархического подхода применительно к программным системам стало возможным только после конкретизации общих положений подхода и внесения некоторых изменений в процесс проектирования. При этом структурный подход учитывает только свойство иерархии «целое–часть», а объектный – использует еще и свойства иерархии «простое-сложное».