- •Учебно-методическое пособие по выполнению конструкторской, технологической и общих частей дипломного проекта
- •Глава 1. Основные направления разработки конструкторской части дипломного проекта
- •Глава 2. Порядок выполнения и основные требования к разработке конструкторской части дипломного проекта
- •Глава 3. Примерные темы для разработки конструкторской части дипломных проектов
- •4.1.1. Единая система конструкторской документации
- •4.1.2. Оформление текстовых документов
- •По специальности 160400 «Системы автоматического управления летательных аппаратов»
- •По специальности 200106 «Информационно-измерительная техника и технологии»
- •По специальности 230101 «Вычислительные машины, комплексы, системы и сети»
- •Глава 4. Указания и рекомендации по разработке конструкторской части дипломного проекта
- •4.1. Единая система конструкторской документации ескд
- •4.1.2.1. Требования к оформлению пояснительной записке дипломного проекта
- •4.1.2.3. Требования к оформлению инструкции по регулированию
- •4.1.2.4. Программа и методика испытаний
- •4.1.3. Правила оформления графического материала
- •4.1.3.1. Виды и типы схем
- •4.1.3.3. Электрические схемы
- •4.1.4.3. Чертежи габаритные, монтажные
- •4.1.4.4. Чертежи деталей
- •4.1.4.5. Чертежи печатных плат
- •4.1.5. Документы других видов
- •4.2. Системы автоматизированного проектирования сапр
- •4.2.1. Стандарты сапр
- •4.2.2. Структура сапр
- •4.2.3. Структура автоматизированного проектирования
- •4.2.4. Состав документации при автоматизированном проектировании
- •4.3. Единая система программной документации - еспд
- •4.3.1. Общие положения
- •4.3.2. Общие требования к программным документам
- •4.3.2.1.Титульная часть
- •4.3.2.2. Информационная часть
- •4.3.2.3. Основная часть
- •4.3.3. Общие требования выполнения программных документов
- •Техническое задание
- •4.3.3.3. Программа и методика испытаний
- •4.3.3.4. Текст программы
- •4.3.3.5. Описание программы
- •4.3.3.6. Ведомость держателей подлинников
- •4.3.3.7. Пояснительная записка
- •4.3.3.8. Формуляр
- •4.3.3.9. Описание применения
- •4.3.3.10. Руководство системного программиста
- •4.3.3.11. Руководство программиста
- •4.3.3.12. Руководство оператора
- •4.3.3.13 Описание языка
- •4.3.3.14. Ведомость эксплуатационных документов
- •4.3.3.15 Руководство по техническому обслуживанию
- •4.3.3.16. Оформление алгоритмов
- •Глава 5. Основные направления разработки технологической части дипломного проекта
- •Глава 6. Порядок выполнения и основные требования к разработке технологической части дипломного проекта
- •Глава 7. Примерные темы для разработки технологической части дипломных проектов
- •Глава 8. Указания и рекомендации по разработке технологической части дипломного проекта
- •8.1. Указания по соблюдению и использованию госТов
- •8.1.1. Единая система конструкторской документации
- •8.1.2. Единая система технологической документации (естд)
- •8.2. Последовательность проектирования технологических процессов
- •8.3. Математическое моделирование технологического процесса
- •8.3.1. Цели математического моделирования технологического процесса
- •8.4. Конструктивно-технологическая характеристика изделия и расчет технологичности конструкции
- •Коэффициент автоматизации и механизации монтажа изделий
- •Коэффициент применяемости эрэ
- •Коэффициент прогрессивности формообразования деталей
- •8.5. Указания по технологии разработки программного обеспечения
- •8.5.1. Требования к по
- •8.5.8. Отладка программы
- •8.5.9. Обработка результатов решения задачи и их документирование
- •8.6. Принципы разработки технологического процесса регулировки и испытания аппаратуры
- •8.6.1. Проектирование технологического процесса регулировки аппаратуры
- •8.6.1.1. Технологическая документация
- •8.6.2. Испытание аппаратуры
- •8.7. Принципы расчета надежности изделий и разработка технологического процесса и программы испытаний на надежность
- •8.7.1. Ориентировочный расчет надежности устройств
- •8.7.2. Разработка технологического процесса и программы испытаний устройства на надежность
- •8.8. Контроль выполнения технологической разработки
- •Литература
- •Содержание
8.5.1. Требования к по
Экономичность (затраты вычислительных ресурсов).
Тм – время машинное;
Пм – память машинная.
При оценке ПО по критерию экономичности рассматривается отношение Тм к Пм.
Удобство использования ПО включает в себя надежность, наличие проблемно-ориентированных языков и диагностических средств поиска ошибок пользователя.
Надежность ПО – свойство выполнять заданные функции в заданных условиях. Основной показатель надежности – вероятность получения првильного результата при использовании программ в заданных условиях.
Правильность ПО – свойство, характеризующее соответствие ПО спецификациям математических параметров.
Универсальность ПО характеризуется ограничением на применение ПО. (Требования универсальности прямо противоречат требованиям надежности). Учитывая, что дипломное проектирование прямо ориентировано на получение пороговой (зачетной или переводной) оценки, при разработке ПО необходимо делать упор на надежность).
Открытость ПО характеризуется возможностью внесения изменений в него в процессе эксплуатации.
Сопровождаемость ПО характеризует удобство поддержания ПО в работоспособном состоянии.
Мобильность ПО определяется легкостью переноса ПО на ЭВМ с одной системой команд на ЭВМ с другой системой команд.
Структура ПО
Для того, чтобы структурировать ПО используют следующие понятия:
Пакет прикладных программ (ППП) – это совокупность программ, объединенных общностью применений.
Комплекс – сложная программа, которая может разделяться на составные части.
Компоненты – составные части программ, имеющие свое функциональное назначение.
Типы ППП
- ППП простой структуры, которые характеризуются наличием только обрабатывающей части. Такие программы нужны для ограниченного применения на маршрутах проектирования, где последовательно выполняемые операции достаточно автономны. Примерами таких программ являются вычисления, реализованные в языках DOS-платформы, типа Бейсик и Паскаль.
- ППП сложной структуры и программируемой систеиы. Здесь есть собственная управляющая часть (монитор), а программируемая система имеет достаточно развитой интерфейс. В настоящее время такие программы реализуются методами визуального программирования в средах типа Delphi и C++Builder.
8.5.4. Принципы и этапы разработки ПО
Наиболее простой и разумной стратегией в разработке ПО для дипломного проекта является блочно-иерархический подход. Коротко его можно охарактеризовать как разбиениеосновной задачи программы на части по принципу функционального единства вычислений и их уровня. Затем произодится определение и установка связей между получившимися блоками, после чего программируются сами блоки. Среды визуального программирования располагают на настоящее время достаточно развитым уровнем менежмента проекта для применения блочно-иерархического подхода с опорой на строенные средства среды.
Модуль – структурная составляющая ПО, рассматриваемая как единое целое на определенной стадии разработки или эксплуатации.
Можно указать следующие уровни представления в порядке исходящего проектирования ПО (табл.8.2).
Си стемный уровень. На нем конкретизируются функции программы. Планируется ее структура и состав. Устанавливается степень использования, доступнго для приобретения готового общесистемного и базового ПО. Разрабатываются спецификации на отдельные программные пакеты.
Уровень прикладных программ. На нем выбирается математическое обеспечение (методы решения), разрабатываются специфические алгоритмы, устанавливается модульная структура программ, выбираются структуры данных, выбираются способы информационного интерфейса и выбирается язык программ. Разрабатываются спецификации на отдельные программные модули.
Уровень подпрограмм – уровень модулей. На нем производится конкретизация типов и структуры данных, осуществляется кодировна алгоритмов.
Таблица 8.2.
Этапы синтеза |
Уровни |
Этапы отладки |
|
Система |
7. Система отладки |
проектирование ПО
|
Программа |
6. Комплексная отладка |
|
Подпрограмма |
5. Этап отладки |
Спецификации могут быть следующими:
Функциональная спецификация – описание функций по переработке информации.
Эксплуатационная спецификация – предъявляет требования к быстродействию и надежности ресурсов.
Спецификация по единой программной документации – описание состава ПО и
перечень требований к программной документации.
На первом этапе разрабатывается функциональная спецификация, но могут быть отмечены и необходимые элементы эксплатационной спецификации.
Отладка нанижнем уровне осуществляется с помощью тестов.
Проектирование ПО
В методах разработки ПО существуют два подхода:
1. Генерация новой программы на базе адаптированного программного комплекса с по
мощью специальных инструментальных средств (Delphi, C++).
2. Проектированием полностью оригинальных программ (Бейсик, Паскаль).
Существует три группы методов проектирования ПО:
Методы нисходящего проектирования – методы функциональной декомпозиции.
Преимущества: облегчается разработка и понимание сложных программ; тестирование может проводиться на каждом уровне.
Недостатки: изменения в структуре программ, если их необходимо выявлять на последних стадиях разработки программ, обходится очень дорого.
Методы восходящего проектирования. Осуществляется предварительное выявление набора типовых функций и создание набора типовых модулей.
Преимущества: достаточно простое и дешевое внесение изменений на любом этапе разработки программ.
Недостатки: усложнение программы может выйти из-под контроля, тестирование становится менее доступно.
Методы расширения ядра. Они основаны на постепенном расширении функций и состава программного комплекса, начиная с определенного ядра. Ядро - это первоначальная версия программного комплекса, реализующая одни или несколько
коротких маршрутов проектирования, состоящих из отдельных
процедур.
Для разработки ПО дипломного проекта студенту рекомендуется выбрать метод восходящего проектирования.
8.5.5. Оценка трудоемкости разработки ПМК
Затраты времени на разработку:
P(N) [человеко-дней],
где N – объем программ [1000 условных машинных команд].
Из каталогов функций можно выбрать N.
P(N) может изменяться в зависимости от сложности программного обеспечения.
Длительность разработки ПО прогнозируется по формуле:
,
где Pi – трудоемкость разработки i-ой составляющей ПМК;
ni – число разработчиков;
Ф – фонд времени одного разработчика.
8.5.6. Подход к разработке структуры данных программы
При разработке и определении структуры данных программы необходимо помнить , что любая программа есть набор условий контролируемого преобразования информации с помощью ЭВМ. Отсюда можно выделить следующие группы данных:
Входные данные.
Выходные данные.
Промежуточные данные.
Любые из этих данных представляют собой набор переменных определенных типов. Отсюда формулируются задачи определения этих типов (задача качества представления) и определение необходимого и достаточного числа переменных (задача количества представления).
8.5.7.1. Задача определения типов данных
Задача определения типов данных сводится к выбору типа из предлагаемых средой разработки. Нижней границей применимоти выбора служит количество значений, которое может принять переменная этого типа. Верхней границей применимости можно считать требования по экономичности ПО и техническим возможностям ЭВМ.
При выборе типа данных надо учитывать будущие связи между модулями и следующее из этого количество преобразований типов, которое необходимо свести к минимуму.
Пример. Пусть необходимо выбрать переменную счетного цикла, перебирающего дни недели. Возможные решения ограничиваются перечисленными типами. Варианты
( Var Days: Integer; Var Days: Word; Var Days: Byte, а также пользовательский тип Type, Ddays=(Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday); Var Days: Ddays.
Очевидно, что пользовательский тип наиболее нагляден, что немаловажно для удобства программирования и объяснения программных решений внешнему наблюдателю. Однако от самый затратный по машинным ресурсам. Так как цикл по определению не может перебирать более , чем семь значений, выбор типа Integer или Word, так же нецелесообразен с точки зрения машинных ресурсов.
Примечание. Разумеется, для современных мощностей различие по вариантам в приведенном примере совершенно некритично и требование наглядности безусловно перевешивает. Тем не менее, сама проблема будет присутствовать всегда, вне зависимости от доступных вычислительных мощностей.
8.5.7.2. Задача определения количества переменных
В этой задаче наиболее ярко проявляется дилемма «память-скорость». Если используется минимально необходимое количество переменных,это всегда означает наибольшее время вычисления из возможных при прочих равных условиях. И наоборот, минимальное время вычислений всегда означает максимальный расход памяти.
Как было сказано выше, при доступных мощностях ЭВМ целесообрано ориентироваться на наглядность представления алгоритма, так как время вычислений для большинства задач, присутствующих в студенческих работах, некритично. Иными словами, студенту не рекомендуется экономить на количестве переменных в ущерб наглядности. Это значительно облегчает разработку программы, особенно если таковая ведется на протяжении достаточно долгого времени или со значительными перерывами
8.5.7.3. Разработка структуры входных данных программы
Входные данные программы в данном случае целесообразно квалифицировать по методу ввода, разделив их на ввод с панели графического интерфейса (клавиатура+мышь), чтение из файла, а также генерацию их самой программой (например, через датчик случайных чисел).
Ввод данных при помощи графического интерфейса будет рассмотрен в соответствующем разделе.
Чтение входных данных из файла подразумевает знание типа файла, так что в программу может быть просто импортирован тип данных, использовавшихся в программе, создавшей используемый файл. Если подобное невозможно, необходимо прибегнуть к методу блочного чтения с последующим поиском в блоке необходимых данных по известному смещению или формату.
Если известно постоянное смещение, то оптимальным по скорости решением такого типа поиска служит задание типа данных, соответствующего по размеру читаемому блоку, со структурой, так подобранной по размеру переменных, что в некоторой переменной окажутся нужные данные. В задаче поиска по формату можно выделить этапы задания маски и организации цикла поиска, вложенного в цикл чтения из файла.
При генерации данных самой программой (датчик псевдослучайных чисел) необходимо убедиться, что генерируемые последовательности отличаются от реализации к реализации.
8.5.7.4. Разработка структуры выходных данных программы
Выходные данные программы в данном случае целесообразно разделять по их виду на графические, текстовые и иные. Методы их вывода обычно интегрированы в систему и среду разработки (диалог TPrintDialog, например). Отсюда задача организации выходных данных в основе своей сводится к задаче организации файла, который впоследствии может быть просмотрен какими-то внешними программами, либо выведен на печать.
Основным требованием к выходным данным программы является наглядность, которую можно оценить через сведение необходимых дополнительных пояснений со стороны разработчика программы к невозможному минимуму. Отсюда следует необходимость тщательной разработки формы вывод в средах визуального программирования. Типы данных в современных средах обычно представляются готовыми.
Разработка структуры промежуточных данных программы
Эта задача может выглядеть по-разному в зависимости от темы прокта. Тем не менее, основным требованием является сведение к минимуму числа преобразований типов данных в программе.
8.5.7.6. Подход к разработке графического интерфейса
Среды визуального программирования представляют все возможности для разработки графического интерфейса. От пользователя требуется в первую очередь соблюсти требования к логической структуре интерфейса, то есть исключить возможность ввода противоречивых данных или данных, не соответствующих специфике задачи.
Условно данные, ввождимые с графического интерфейса, можно подразделить на две группы – численные данные для решения задачи и логические данные для определения реализации конкретного решения. Численные данные обычно вводятся через окна редактирования, логические данные задаются через выбор радиокнопок и т.п.
Студенту рекомендуется тщательо продумать вид и функции элементов интерфейса до начала программирования, в противном случае неизбежны значительные потери времени и ошибки в программировании.
