- •Общая характеристика технологии программных средств.
- •Принципиальная схема разработки программных средств. (Технология, процесс создания).
- •Способы описания алгоритмов.
- •Описание алгоритма с помощью таблиц решения.
- •Технология системного проектирования программных средств. Принципиальная схема разработки.
- •Современные методы и средства разработки прикладных программных средств.
- •Характеристики качества программного обеспечения.
- •Языки программирования.
- •Надёжность программного обеспечения.
- •Показатели надёжности.
- •Факторы, определяющие надёжность по.
- •Стандартизация. Дисциплина и творчество программирования.
- •Виды программ и программных документов.
- •Виды программных документов.
- •Эксплуатационные документы.
- •Классификация документов.
- •Работы, выполняемые на стадии «Эскизный проект».
- •Структурное программирование.
- •Терминология и обозначения.
- •Очевидно, что g и h являются простыми программами, иначе f была бы не простой.
- •Число управляющих линий в блоке h удовлетворяет соотношению:
- •Графическая иерархическая документация (гид).
- •Простейшие пути повышения качества программ.
- •Классификация ошибок.
- •Сквозной структурный контроль.
- •Стиль программирования и качества программ.
- •Case – технологии.
- •Моделирование данных.
- •Что дает применение case-средств?
- •Средства реализации case-технологий.
- •Общая характеристика case-средства
- •Особенности рабочего интерфейса
- •Начало работы с проектом в среде
- •Разработка диаграммы вариантов использования в среде Rational Rose.
- •Разработка диаграммы классов в среде
- •Диаграмма классов
- •Разработка диаграммы состояний в среде Rational Rose.
- •Разработка диаграммы последовательности в среде Rational Rose.
- •Разработка диаграммы кооперации в среде Rational Rose.
- •Разработка диаграммы компонентов в среде Rational Rose.
- •Разработка диаграммы развёртывания в среде Rational Rose.
- •Практические примеры диаграмм.
- •Актеры.
- •Диаграмма классов (основы)
- •Ассоциации
- •Заказ от одного клиента
- •Полезные советы по использованию диаграмм классов
- •Диаграмма взаимодействия
- •Диаграмма кооперации
- •Диаграмма кооперации
- •Диаграмма пакетов
- •Диаграмма состояний
- •Верификация программ.
- •Восходящее тестирование, нисходящее тестирование.
- •Методы тестирования компонентов.
- •Структура коллектива программистов.
- •Общая структура коллектива, работающего над крупным проектом.
- •Трудовые затраты по видам работ (человеко/месяц).
Работы, выполняемые на стадии «Эскизный проект».
Вид работы |
Содержание |
Разработка эскизного проекта |
Предварительная разработка структуры входных и выходных данных, уточнение методов решения задачи, разработка общего алгоритма решения, разработка пояснительной записки. |
Утверждение эскизного проекта |
Согласование и утверждение эскизного проекта. |
Результаты эскизного проектирования отображаются в документе «Пояснительная записка к эскизному проекту». ГОСТ 19.404-79.
Данный документ содержит следующие разделы:
Введение – указывает наименование программы и документы, на основании которых ведётся разработка.
Назначение и область применения – характеристики области применения должны точно соответствовать характеристикам, указанным в техническом задании, но быть более подробно с точки зрения функционирования программного комплекса.
Технические характеристики – содержат следующие подразделы:
Постановка задачи на разработку программы;
Описание примерных математических методов;
Описание алгоритма;
Описание метода.
Структурное программирование.
В настоящее время наиболее распространёнными являются следующие подходы к программированию:
Восходящее проектирование;
Нисходящее проектирование;
Структурное программирование.
В основе восходящего проектирования лежит идея выделения достаточно крупных модулей, реализующих определённые функции в общей программе. Выбор модулей определяется различными соображениями:
Понятностью реализации функций;
Размерами;
Структурами данных;
Наличия сходства с уже имеющимися программами.
Для каждого из модулей даётся описание, определяется интерфейс по входу и выходу. Затем модуль автономно программируется, отлаживается и проверяется.
Затем осуществляется объединение этих частей на основе ранее определенных интерфейсов и отдельно разрабатываемой управляющей программы. Затем идёт отладка. Основной недостаток: сложность процесса объединения отдельных модулей в единую систему, трудности исправления ошибок, допущенных на стадии разработки.
Довольно часто отдельные модули имеются вне в связи со всей задачей и при различных предположениях об общей структуре, поэтому такую программу трудно корректировать при изменении внешних требований к ней и при обнаружении ошибок.
Сложность процесса программирования ведётся к необходимой научно-обоснованной методологии разработки и документирования сложной программы. Эта методология касается анализа исходной задачи, разделение её на достаточно самостоятельные части и программирование этих частей по возможности независимо друг от друга.
Одной из такой методологии является структурное программирование. В его основу положены следующие простые положения:
Программа должна составляться мелкими шагами. Размер шага определяется качеством решений, применяемых программистом на этом шаге.
Сложная программа должна разбиваться на достаточно большие легко воспринимаемые части, каждая из которых имеет один вход и один выход.
Логика программы должна опираться на минимальное число достаточно простых базовых управляющих структур, подобно тому, как любая функция алгебры логики может быть выражена через дизъюнкцию, конъюнкцию, отрицание.
Использование этих положений позволяет внести определённую систему в работу программиста и составлять удобочитаемые программы.
Не менее существенным является то, что использование базовых управляющих структур облегчает доказательство правильности программиста.
Идея структурированного программирования в наиболее полной формуле были высказаны Дейкстройем, однако они в значительной мере опираются на более ранние работы Бема, Джекопини, Наура, Флойда.
Фундаментом структурного программирования является доказанная Бемом и Джекопини теорема о структурировании.
Теорема устанавливает, что как бы трудна не была задача, блок-схема соответствующей программы всегда может быть представлена с использованием весьма ограниченного ряда элементарных управляющих структур:
Тогда (THEN);
Если – тогда - иначе (IF – THEN – ELSE);
Делать пока (DO WHILE).
Эти элементарные структуры могут объединяться между собой, образуя более сложные структуры, но тем же самым элементарные схемы.