Приложение в. Проектирование и разработка программы
Одним из основных компонентов отчета в лабораторных работах №№5-6 является модель написанной программы. Что под этим понимается?
Сложность задачи, которую необходимо решить в этих лабораторных работах, требует ознакомления с понятием процесса проектирования программного обеспечения. В упрощенном виде к основным этапам традиционного потока проектирования ПО можно отнести:
Разработку технического задания и спецификаций (в данном случае они уже представлены и предложены в виде варианта задания).
Архитектурное проектирование (по-другому, системное или концептуальное проектирование).
Разработку программного обеспечения (непосредственная реализация, т.е. кодирование).
Отладку и тестирование.
Создание рабочей документации (в данном случае это отчет).
Ввод в эксплуатацию, сопровождение (в данном случае это демонстрация преподавателю выполненной работы и ее защита).
Вопросам технологий проектирования программного обеспечения в частности и вычислительных систем в целом, проблемам в различных подходах к проектированию и разработке систем, так называемому «кризису сложности» в вычислительной технике посвящено множество статей и книг [28, 30, 40, 41, 42, 43, 49, 64, 69, 14, 15, 20, 25]. Однако недостаточное качество, многократно заваленные сроки выполнения, высокая стоимость до сих пор являются характерными чертами систем такого рода.
В данной работе Вам настоятельно рекомендуется не пропускать этап архитектурного проектирования, т.е. продумать, как Вы будете решать поставленную задачу, а потом уж приступать к кодированию придуманного. Что это Вам даст? Грамотное системное проектирование
Существенно сократит время реализации ПО в частности и срок выполнения работы в целом (примерное временное соотношение этапа №2 и этапа №3 – «80% к 20%»).
Сделает Вашу программу прозрачной, простой для понимания, предсказуемой, значит, легко отлаживаемой.
Повысит качество.
Сократит ресурсоемкость.
Добавит в Вашу программу возможность наращивания функциональности, модифицируемости и дальнейшего развития (если, конечно, критерий повторного использования учитывался на этапе проектирования).
Сделает более доступным анализ разработанного ПО.
и т.д.
Этап архитектурного проектирования обычно тесно связан с вопросом описания разрабатываемой системы. Недостатком вербального описания программного обеспечения является низкая степень формализации, т.е. практическая невозможность математического доказательства правильности тех или иных утверждений, выраженных таким способом. Блок-схема алгоритма, применяющаяся для описания сравнительно несложных программ, уже не дает никакого эффекта в крупных проектах. Еще в работах Дейкстры и Вирта, а далее в работах Йордона, Росса и др. было предложено описывать программные системы в виде совокупности структурных и поведенческих составляющих. Система разрабатывалась на основе декомпозиции (разделения) общих сущностей на более частные. Была предложена так называемая «абстракция», т.е. выделение существенных для проектировщика деталей проекта и сокрытие второстепенных.
Что такое структура и поведение? Структура системы – это совокупность частей (элементов и подсистем) и связи между ними. Поведение системы – это изменение структурных составляющих (подсистем и элементов), а также связей между ними во времени.
Для описания двух этих понятий, люди издавна используют графические изображения. К сожалению, пока не существует способа изображения на одной картинке всей структуры или поведения вычислительной системы. Приходится рассматривать и структуру, и поведение с разных позиций.
Структура может быть представлена следующими способами:
Совокупность блоков системы и интерфейсов (объект A соединен с объектом B с помощью интерфейса I2C).
Совокупность объектов и зависимостей (объект «дом» зависит от объекта «электростанция»).
Схема наследования классов (класс X происходит от классов Y и Z).
Схема включения классов (агрегация, класс Q включает в себя объекты S и D).
Поведение можно представить в виде:
Конечного автомата [96].
Временной диаграммы (процессограммы, диаграммы взаимодействий и т.п.).
Потоковой диаграммы (DFD, CFD и т.п.).
Эти перечни не претендуют на полноту. В книгах по проектированию вычислительных систем можно найти другие способы описания структуры и поведения или, так называемых, нотаций [30].
Требуемая в отчете модель программы – это и есть ее архитектурное описание. В случае прохождения этапа архитектурного проектирования представить эту модель не составляет труда.
Чтобы проанализировать и оценить логику работы программы (решения поставленной задачи), организацию работы с периферийными устройствами, алгоритмы управления в прикладной и системной части необходимо оторваться от строчек кода (абстрагироваться) и посмотреть на программу в целом, панорамно, по уровням. Поэтому Вам нужно выделить основные сущности Вашей программы и способы (каналы) их взаимодействия – соответственно получается модель первого уровня. Потом (на втором уровне) необходимо представить модели каждой из выделенных сущностей: чаще всего это может быть модель функционирования драйвера клавиатуры, последовательного канала, звукового излучателя, шины I2C, основного прикладного алгоритма и т.д. с выделением потока данных и/или управления (команд). Например, в лабораторной работе № 4 «Клавиатура» для представления задачи сканирования клавиатуры (это лишь часть драйвера клавиатуры) прекрасно подходят конечные автоматы (FSM) [30, 85, 96]. Также могут быть применены сети процессов Кана, DFD и другие перечисленные ранее способы описания структуры и поведения системы. Рекомендуется ознакомиться с этими нотациями, но можно использовать и свой способ описания, – главное, чтобы он удовлетворял перечисленным выше требованиям.