Меркулов В.И., Дрогалин В.В. Авиационные системы радиоуправления. Том 2 (2003) (1151998), страница 32
Текст из файла (страница 32)
9.7.2. ФУНКЦИОНАЛЬНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ Общая характеристика и показатели сложности. Функциональное программное обеспечение предназначено для решения основных и вспомогательных задач ИВС. В качестве вспомогательной, но весьма важной задачи можно назвать задачу обеспечения устойчивости функционирования ПО в условиях наличия ошибок в программах, появления сбоев и частичных отказов в ИВС, а так же всевозможных клинчей и перегрузок в БВС.
Существенным требованием к ФПО является возможность развития программной системы, что предусматривается фазой жизненного цикла ПΠ— сопровождением, но при этом необходима разработка большого объема хорошо сопровождаемой документации.
Требования обеспечения устойчивости и развития ФПО приводят к необходимости использования открытой модульной архитектуры ФПО ИВС. Большие объемы ФПО современных ИВС и необходимость сопровождения требуют применения апробированных технологий, соблюдения стандартов и автоматизации, прежде всего, рутинных работ. В связи с высокой сложностью ФПО разрабатывается в виде последовательности наращиваемых по функциям версий. Обычно различают математическую (техническую) и логическую сложность программного обеспечения. Чтобы охарактеризовать слож- 167 ность используют те или иные показатели.
Так, например, в 1791 предложены две группы показателей: сложность проектирования и сложность функционирования. Сложность проектирования определена в виде трех компонентов: сложности программных модулей, сложности структуры данных, сложности структуры комплекса программ и связей между модулями. Показатели сложности функционирования связаны с потреблением ресурсов ВС и включают: временную сложность, характеризуемую длительностью исполнения комплекса программ, программную сложность, определяемую объемом памяти, необходимым для размещения всего программного комплекса, информационную сложность, представляемую объемом памяти, требуемой для накопления и хранения информации, используемой программами. Деление показателей на две группы достаточно условно, так как в действительности уровень использования ресурсов ВС и их доступность зависят не только от сложности функционирования, но и структурной сложности, в частности, степени взаимодействия программных модулей.
Эти взаимодействия в итоге определяют возможность распараплеливания процессов вычисления и организацию памяти БВС. Методы разработки и технологии создания. Разработка ФПО (алгоритмов, временных диаграмм, протоколов, программ обработки информации и управления, а так же комплектов программной и конструкторской документации) в значительной степени определяет стоимость и длительность разработки, а так же эффективность решения основных целевых задач ИВС.
Методы разработки программного обеспечения интенсивно развивались на протяжении последних пятидесяти лет и представляют собой сегодня некоторую синтезированную научную дисциплину с использованием математических методов и инженерных расчетов, моделирования и методов управления разработкой, а так же технологий, поддерживающих процессы жизненного цикла (ЖЦ) ПО.
Современная технология создания сложного программного обеспечения включает в себя регламентированные производственные процессы, поддерживаемые автоматизированными средствами и комплексом руководящих документов, а такзке соответствующей организацией работ коллектива специалистов, часто довольно крупного, а иногда и обьединенного в кооперацию. 168 Такие технологические процессы должны регулировать выполнение этапов системного анализа, проектирования, написания программ (модулей), отладки, испытания, документирования, а так же управление работой специалистов и поддержку эксплуатации и сопровождения программного обеспечения.
Технология создания и развития программного обеспечения опирается на используемую модель его ЖЦ. Модели ЖЦ программного обеспечения неоднократно изменялись, отражая тот или иной подход к методам проектирования ПО и его разработке в целом. Наиболее простой и часто используемой является каскадная модель ЖЦ, суть которой сводится к описанию некоторой последовательности этапов (каскадов) ЖЦ и их довольно сложного взаимодействия между собой [77). Рост сложности ФПО, плохая обозримость сложного ФПО, вызывающие уже на этапе разработки требований большие затраты людских ресурсов н времени, привели к созданию модели ЖЦ с использованием прототипа [14]. Суть этой модели заключается в расширении стадии разработки за счет введения в нее этапа создания прототипа (макета разрабатываемого ФПО), его анализа, уточнения требований к ФПО и переходу к его полномасштабной разработке.
Появление фонтанной модели ЖЦ [831 связано с возникновением объектно-ориентированного проектирования и программирования, в рамках которых создаются классы объектов, собираемые в библиотеки. Суть объектно-ориентированного подхода сводится к упрятыванию лишней с точки зрения пользователя информации и к четким определениям интерфейса объекта и порядка его взаимодействия с другими объектами. Прн этом предполагается, что объект будет использован не только в текущей разработке ФПО, но и ряде последующих разработок, используя принцип наследования. Это многократное использование и образует «фоитан».
Жизненный цикл программного обеспечения обычно описывается в терминах функциональной декомпозиции. Основной вопрос системного анализа и проектирования заключается в формулировании ответа на вопрос: что делает система? Методы функционального проектирования и функциональной декомпозиции, используемые для решения задачи, основаны на интерпретации проблемного пространства и его преобразовании в пространство возможных решений как взаимозависимое множество функций или процедур. Функциональная декомпозиция представляет собой методику анализа и проектирования «сверху вниз». Хотя анализ и проектирование не является синонимами, большинство известных методов системного анализа и проектирования имеют много общего.
169 При использовании функциональной декомпозиции, сначала система рассматривается с точки зрения ее назначения, а процедуры и алгоритмы только подразумеваются разработчиком. Затем на стадии детального проектирования решаются вопросы о способах организации необходимых процессов. Для поддержки этой методики, основанной главным образом на потоках данных, используются диаграммы потоков данных, словари данных и структурные схемы. Функциональную декомпозицию удачно поддерживают появившиеся ранее процедурные языки. Добавление в эти языки подпрограмм позволило достигнуть определенной степени автономности и закрытости от пользователя несущественной для него информации. Проектирование «сверху вниз» вводит определенную дисциплину, которой должны подчиняться системный аналитик и программист.
Основным недостатком метода проектирования «сверху вниз» является наличие большого числа ограничений, которые затрудняют применение современных методов программирования. К таким ограничениям следует отнести: отсутствие учета эволюционных изменений; описание системы одной функцией, что может быть не всегда целесообразно; базирование системы на функциональных методах, при которых игнорируется аспект организации структур данных; невозможность многократного использования.
В объектно-ориентированном проектировании в простейшем случае участвуют данные и процедуры. В нем уменьшена зависимость от процедур, и данные группируются вместе с процедурными функциями. При декомпозиции с использованием объектно-ориентированного метода система рассматривается как совокупность объектов (иногда называемая категорией или классом объектов). Анализ и проектирование высокого уровня осуществляются с использованием не только этих объектов, но и услуг, выполняемых ими.
Для этого используется модель типа «клиент-обслуживатель», в которой объекгы взаимодействуют друг с другом посредством сообщений. Сообщение передает информацию, вызывает объекты для выполнения процедуры и т.д. Использование модели «клиент-обслуживатель» приводит к тому, что система описывается как «движимая ответственностью» (83]. Детальное проектирование, включающее в себя реализацию процедур и спецификацию структур данных, откладывается на более позднее время.
Элементы детального проектирования являются собственными элементами объекта, поэтому они относятся только к концепции сокрытия от пользователя несущественной информации. Следовательно, алгоритмические процедуры и структуры данных не являются более 170 «замороженными» на уровне системного проектирования. В результате этого система, основанная на представлении объекта, становится более гибкой, т.к. изменения на уровне реализации осуществляются легче, без внесения изменений в сам системный проект. Важным моментом является то, что структуры данных не нужно указывать на самых ранних стадиях проектирования.
Категории данных могут обеспечить основу идентификации объекта, вокруг которой затем строится интерфейс. Построение объекта использует абстракцию данных, а не фиксацию конкретных структур данных в спецификации объекта. Ввиду того, что разработка объектно-ориентированной программы происходит главным образом «снизу вверх», различие между стадиями проекгирования программы и написания текста менее заметно, чем в жизненном цикле систем, основанных на использовании функционального подхода. Однако на этой поздней стадии целесообразно внутри программных модулей, называемых в объектно-ориентированной системе классами, использовать средства функциональной декомпозиции на высоком уровне и системного проектирования «сверху вниз», например„ диаграммы потока данных.
Другими графическими средствами, используемыми на различных стадиях жизненного цикла объектно-ориентированных систем, являются графы взаимоотношений объектов, диаграммы «клиент-обслуживатель», диаграммы наследования свойств н графы сотрудничества. В отличие от традиционного анализа структурированных систем, основанного главным образом на функциональной декомпозиции «сверху вниз», объектно-ориентированные проектирование и анализ имеют много атрибутов как проектирования «сверху вниз», так и проектирования «снизу вверх».
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
