ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.02.2024
Просмотров: 295
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Конструктивный подход
Конструктивный подход к разработке программы представляет собой модификацию нисходящей разработки, при которой модульная древовидная структура программы формируется в процессе программирования модуля. Сначала программируется головной модуль, исходя из спецификации программы в целом (спецификация программы является одновременно спецификацией головного модуля). В процессе программирования головного модуля в случае, если эта программа достаточно большая, выделяются подзадачи (некоторые функции) и для них создаются спецификации реализующих эти подзадачи фрагментов про граммы. В дальнейшем каждый из этих фрагментов будет представлен поддеревом модулей (спецификация выделенной функции является одновременно спецификацией головного модуля этого поддерева).
Таким образом, на первом шаге разработки программы (при программировании ее головного модуля) формируется верхняя часть дерева, например, как на рисунке 2.11.
Рисунок 2.12 – Первый шаг формирования модульной структуры программы
По тому же принципу производится программирование следующих по уровню специфицированных, но еще не запрограммированных модулей в соответствии со сформированным деревом.
Рисунок 2.12 – Второй шаг формировании модульной структуры программы при конструктивном подходе
В результате к дереву добавляются очередные уровни, как показано на рис. 2.12.
Архитектурный подход
Архитектурный подход к разработке программы представляет собой модификацию восходящей разработки, при которой мо дульная структура программы формируется в процессе программирования модуля. Целью разработки в данном методе является повышение уровня языка программирования, а не разработка конкретной программы. Это означает, что для заданной предметной области выделяются типичные функции, специфицируются, а затем и программируются отдельные программные моду ли, выполняющие эти функции. Сначала в виде модулей реализуются более простые функции, а затем создаются модули, использующие уже имеющиеся функции, и т. д. Это позволяет существенно сократить трудозатраты на разработку конкретной программы путем подключения к ней уже имеющихся и проверенных на практике модульных структур нижнего уровня, что также позволяет бороться с дублированием в программировании. В связи с этим программные модули,
создаваемые в рамках архитектурного подхода, обычно параметризуются для того, чтобы облегчить их применение настройкой параметров.
Нисходящая реализация
В классическом методе нисходящей разработки сначала асе модули разрабатываемой программы программируются, а затем тестируются в нисходящем порядке. При этом тестирование и отладка модулей могут привести к изменению спецификации подчиненных модулей и даже к изменению самой модульной структуры программы. В результате может оказаться, что часть модулей вообще не нужна в данной структуре, а часть модулей придется переписывать. Более рациональна каждый запрограммированный модуль тестировать сразу же до перехода к программированию другого модуля. Такой метод в литературе получил название метода нисходящей реализации.
Целенаправленная конструктивная реализация
В зависимости от того, в какой последовательности в процессе разработки программы обходятся узлы дерева, существуют разновидности описанных выше методов. Например, метод целенаправленной конструктивной реализации, при котором в рамках конструктивного подхода реализуются сначала модули, необходимые для самого простого рабочего варианта программы, остальные модули заменяются их имитаторами. Затем к имеющемуся варианту добавляются другие модули, обеспечивающие работу программы для других наборов данных, и так далее до полной реализации программы. Достоинством этого метода является то, что уже на достаточно ранней стадии создается работающий вариант разрабатываемой программы. Психологически это играет роль допинга, резко повышающего эффективность разработчика.
Подводя итог сказанному, на рис. 2.13 представлена общая схема классификации рассмотренных методов разработки структуры программы.
Рисунок 2.13 - Классификация методов разработки структуры программ
Контрольные вопросы
-
Приведите пример структурной схемы ПО. -
Опишите основные элементы функциональных схем ПО. -
Как составляются структурные схемы Константайна? -
Как составляются структурные карты Джексона? -
Что такое CASE-технологии? -
Что такое RAD-технологии? -
Что такое связность модуля? -
Назовите и охарактеризуйте типы и силы связности модулей. -
Что такое сцепление модулей? -
Назовите и охарактеризуйте типы и степени сцепления модулей.
3 Методологии моделирования предметной области
3.1 Основные принципы разработки надежного программного обеспечения
Прежде всего необходимо сказать, что в данной работе подразумевается под термином «надежное программное обеспечение». Надежное ПО – это программное обеспечение, способное с высокой вероятностью выполнять свою целевую функцию в заданных условиях. Под условиями понимаются программно-аппаратное окружение ПО, заданное время работы, различные ограничения и требования, накладываемые на работу ПО. Надежное программное обеспечение должно обладать свойствами: безотказности, работоспособности, устойчивости к ошибкам.
Если к надежному программному обеспечению предъявляется еще одно требование – безопасная работа, под которым понимается невозможность ПО быть причиной или участвовать в причинении человеку физического вреда, то такое программное обеспечение будем называть «безопасным» или «критическим», а программно-аппаратные системы, в которых оно работает – «критическими системами». Рекомендации стандартов DO178B/DO178С непосредственно относятся к этому программному обеспечению. Для критического программного обеспечения также задаются определенные значения вероятности возникновения отказов, которые оно обязано соблюдать. Любое другое программное обеспечение, для которого требование безопасности не выдвигается, будем назвать «обычным ПО» или «некритическим ПО».
Далее будет часто использоваться термин "жизненный цикл разработки программного обеспечения". Под ним подразумевается часть жизненного цикла программного обеспечения, которая не включает в себя этапы поддержки и обслуживания.
Набор приведенных ниже принципов описывает черты процесса создания ПО, без которых, по мнению автора, нельзя обойтись при разработке надежного ПО. Все они построены на базе рекомендаций, приведенных в авиационных стандартах DO178B/DO178С, и опыта автора по сертификации ПО, согласно этим стандартам. В отличие от принципов разработки критического ПО, приведенные ниже принципы, как правило, гораздо менее жесткие, чем те, что устанавливают авиационные стандарты, поскольку речь идет о надежном ПО, а не о том, которое может причинить вред здоровью человека. Для каждого принципа дается пояснение что под ним подразумевается и то как его можно применить для разработки надежного программного обеспечения.
Определение процесса разработки ПО
Невозможно разработать качественный программный продукт, если процесс его создания является неупорядоченным и бессистемным. Только в результате строго регламентированного процесса можно создать что-то по-настоящему стоящее – утверждают авиационные стандарты. Создание такого процесса является первым шагом в сторону качественного программного обеспечения.
Любая разработка ПО должна начинаться с определения того, что из себя будет представлять весь процесс разработки, какой модели жизненного цикла он будет придерживаться, какие основные процессы должны в него входить. Выбранная модель жизненного цикла позволит упорядочить разработку путем установки всех его основных этапов. Для каждого этапа разработки необходимо наметить цели, а также установить способы их достижения. Выбранную модель жизненного цикла нужно строго соблюдать, и она не может быть изменена в процессе разработки. Смена модели разработки отбрасывает проект к самому его началу.
На сегодняшний день существует множество различных моделей жизненного цикла и, в принципе, почти все они подходят для разработки надежного и качественного ПО. Нельзя со строгой определенностью сказать, что в результате следования вот этой модели программный продукт получается более надежным, нежели в результате разработки согласно той. Для разработки надежного ПО главное – это выполнение установленных целей и задач по обеспечению надежности и строгое соблюдение всех правил, диктуемых моделью. Поэтому нет особого смысла для получения более надежного ПО переходить на другую модель, если есть хороший опыт использования определенного типа модели.
Авиационные стандарты не требуют использования какой-то определенной модели жизненного цикла разработки, но они устанавливают набор процессов, которые обязательно должны в него входить. Для каждого из этих процессов они определяют цели и задачи, которые должны быть выполнены, а также виды деятельности, которые должны быть осуществлены. Для разработки бортового программного обеспечения часто используют V-модель жизненного цикла, спиральную модель разработки или их гибридные варианты.
Рассмотрение вопросов надежности на каждом из этапов разработки
Ключевым отличием разработки критического программного обеспечения от разработки обычного (не связанного с безопасностью) является частичное смещение приоритетов. Для некритического программного обеспечения главными являются требования, установленные его заказчиком или требования, диктуемые его намеченной функцией. Для критического программного обеспечения его безопасная работа более важна, чем функциональность. Поэтому любые действия каждого из процессов, участвующих в работе программного обеспечения, должны быть оценены с точки зрения безопасности.
Для надежного программного обеспечения требования надежности должны быть, по крайней мере, на одном уровне с требованиями к его функциональности. Если мы хотим, чтобы наше программное обеспечение было надежным, даже если мы не разрабатываем критическое ПО, то об этом поздно вспоминать в момент, когда уже начато тестирование. Каждый разработанный план, каждый вид деятельности любого из процессов, входящих в жизненный цикл разработки, каждое функциональное требование и тестовая функция, должны быть рассмотрены через призму надежности. Мы постоянно должны задаваться вопросами: наши действия повышают или понижают надежность ПО; если понижают, то как этого избежать, как сделать так, чтобы надежность не пострадала, что еще можно сделать для стабильной работы, достаточно ли мы приложили усилий, чтобы это правильно работало.
Если во время процесса разработки надежного ПО возникла необходимость изменить или дополнить функциональные возможности программного обеспечения, то должна быть произведена оценка того, как эти изменения повлияет на надежность работы всего программного продукта. Если такое влияние обнаруживается, все действия по обеспечению надежности, в том числе планы, требования, тесты, должны быть пересмотрены, чтобы учесть это влияние. Было бы хорошей идеей во время процесса планирования описать, какие функциональные требования к программному обеспечению являются жестко фиксированными, так что при их смене процесс разработки должен будет начаться сначала, а какие могут быть изменены без рестарта этого процесса.
Доказательство надежности
Ничего не берется на веру – все нужно доказать. Этот принцип – один из основополагающих при разработке надежного и безопасного программного обеспечения. Стандарты DO178B/DO178С однозначно говорят, что если мы не можем доказать