42. Технологичность программного обеспечения. Модули. Требования к модулям.

В условиях индустриального подхода к разработке и сопровождению программного обеспечения особенного веса приобретают технологические характеристики розроблюваних программ. Для обеспечения необходимых технологических свойств применяют специальные технологические приемы и следуют определенными методиками, сформулированным всем предыдущим опытом создания программного обеспечения.

Под технологичностью понимают качество проекта программного продукта, от которого зависят труду и материальные расходы на его реализацию и следующие изменения. Хороший проект сравнительно быстро и легко кодируется, тестируется, налаживали и модифицируется.

Из опыта нескольких поколений разработчиков программного обеспечения известно, что технологичность программного обеспечения определяется разработанной его моделей, уровнем независимости модулей, стилем программирования и степенью повторного использования кодов.

Как следует из определения, высокая технологичность проекта особенно важна, если разрабатывается программный продукт, рассчитанный на многолетнее интенсивное использование, или необходимо обеспечить повышенные требования к его качеству.

Программный модуль - это любой фрагмент описания процесса, который оформляется как самостоятельный программный продукт, пригодный для использования в описаниях процесса. Это значит, что каждый программный модуль программируется, компилируется и налаживали отдельно от других модулей программы, и тем же, физически разделенный с другими модулями программы.Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполненные условия его использования, декларируемые в документации из этого модулю.

В общем случае операции есть багатотактного, то есть выполняются модулем за несколько тактов. Требования на такие операции бывают двух основных типов: требования на операцию в целом, которые не накладывают ограничений на то, на каком именно такте выполняется но другая ли микроопераций, и требования на временнýю композицию операции, в которых фиксируется, на каких тактах выполняются конкретные микрооперации.

Требования на операцию в целом допускают определенную свободу в реализации модуля. Не важно, на каком такте выполняется некоторая микроопераций, важно, чтобы по завершению всей операции результат этой микрооперации был доступен окружению.В процессе тестирования требования на операцию в целом проверяются по завершению операции.

Требования на временнýю композицию операции является жестче.У них отмеченные такты, на которых выполняются микрооперации.

43. Разработка программного обеспечения (восходящая и нисходящая).

Восходящий подход.

При использовании восходящего подхода сначала проектируют и реализуют компоненты нижнего уровня, потом предыдущего и т. д. По мере завершения тестирования и налаживания компонентов осуществляют их складывание, причем компоненты нижнего уровня при таком подходе часто помещают в библиотеки компонентов.

Подход имеет такие недостатки:

- увеличение вероятности несогласованности компонентов в результате неполноты спецификаций;

- наличие расходов на проектирование и реализацию тестирующих программ, которые нельзя превратить в компоненты;

- более позднее проектирование интерфейса, а соответственно невозможность продемонстрировать его заказчику для уточнения спецификаций и т. д.

Нисхідний подход. Нисхідний подход предусматривает, что проектирование и дальнейшая реализация компонентов выполняется сверху "вниз", то есть сначала проектируют компоненты верхних уровней иерархии, потом следующих и так далее к самим нижним уровням. В той же последовательности выполняют и реализацию компонентов. При этом в процессе программирования нування компоненты нижних

еще не реализованных уровней заменяют специально разработанными оценочный модуль - "заглушками", что позволяет тестировать и налаживать уже реализованную часть.

При использовании нисходящего подхода применяют иерархический, операционный и комбинированный методы определения последовательности проектирования и реализации компонентов.

Нисходящий подход допускает нарушение нисходящей последовательности разработки компонентов в специально определенных случаях.

Да, если определенный компонент нижнего уровня используется многими компонентами высших уровней, то его рекомендуют проектировать и разрабатывать раньше, чем вызывают его компоненты.

Нисходящий подход обычно используют и при объектно-ориентированном программировании. В соответствии с рекомендациями подхода сначала проектируют и реализуют для пользователя интерфейс программного обеспечения, потом разрабатывают классы некоторых базовых объектов предметной области, а уже потом, используя эти объекты, проектируют и реализуют другие компоненты. Нисходящий подход обеспечивает:

- максимально полное определение спецификаций проектируемого компонента и согласованность компонентов между собой;

- раннее определение интерфейса пользователя, демонстрация какого заказчика позволяет уточнить требования к создаваемому программному обеспечению:

- возможность нисходящего тестирования и комплексного налаживания.