Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Технологии и методы программирования. Учебное пособие-1

.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

2 Мб

Скачать

☆

<<< < Предыдущая 12 / 142 3 4 5 6 7 8 9 10 11 12 13 14 > Следующая >>>

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

2. Спецификации

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

3. Проектирование

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

4. Реализация

На этом этапе реализуются проектные решения: кодирование, проектирование форм выходных документов, установка технических средств, разработка эксплуатационной документации, которая

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

5. Тестирование

Этап обычно

оказывается распределенным во времени. На этом этапе проверяется наличие или отсутствие ошибок в ПО. Тестирование преследует две основные цели:

 обнаружение факта неработоспособности модуля;  проверку на соответствие модуля спецификации (наличие всех

необходимых функций, отсутствие лишних функций).

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

6. Сопровождение

Внедрение ИС разбивается на опытную и промышленную стадию

экс-

плуатации ИС, которая начинается после приемки ИС. Осуществляется

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

7. Развитие

Этот этап является наиболее длительным в ЖЦ ПО. В процессе эксплуатации ПО регистрируются ошибки, проводится экспертиза проектных решений, формулируются требования к модификации ПО в связи с изменениями объекта и функции управления, появлением

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

Каждый этап разработки ПО влияет на другие этапы

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

тестирова-

ние и документирование нередко оказываются тесно переплетенными.

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

Каскадная модель (водопадная) (рис. 3) предусматривает последо- вательное

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

Можно выделить следующие положительные стороны применения

каскадного подхода:

 на каждом этапе формируется законченный набор проектной до-

кументации, отвечающий критериям полноты и согласованности;

 выполняемые в логической последовательности этапы работ поз-

воляют планировать сроки завершения всех работ и соответствующие ресурсы.

В каскадной модели жизненного цикла ПО не предусмотрены обрат-

ные связи между отдельными этапами, поскольку предполагается, что

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

Рис. 3. Каскадная модель жизненного цикла ПО

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

Каскадная модель применима в разработке программного

обеспе-

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

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

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

реальным

потребностям.

Спиральная модель ЖЦ (рис. 4) была предложена для преодоления перечисленных проблем. Особое внимание уделяется начальным этапам разработки – анализу и проектированию, где реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии программной системы.

Рис. 4. Спиральная модель ЖЦ ПО

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

3. ПРОБЛЕМЫ РАЗРАБОТКИ СЛОЖНЫХ ПРОГРАММНЫХ СИСТЕМ

Сложность – это то, что требует большого труда, усилий; трудности. «Каждая профессия встречает на своем пути свои сложности, которые необходимо преодолевать» [10]. Сложность – характеристика, отражающая степень, при которой проектирование, реализация или поведение системы или элемента является трудной для понимания или верификации [11]. Фактически сложность определяется количеством ресурсов, связей задачи, и растет нелинейно по мере роста размеров проекта программной системы.

Программные продукты относятся к самым сложным системам, которые создаются человеком, и программное обеспечение по самой своей природе обладает рядом существенных и неотъемлемых свойств (таких как сложность, незримость и изменяемость), боту [12].

Сложность представляет неотъемлемое свойство программных систем, которое проявляется во времени и стоимости создания программ, в объеме или длине текста программ, характеристиках ее логической структуры, задаваемой операторами передачи управления (ветвления, циклы, вызовы подпрограмм и т. д.). «Дополнительно сложность обусловливается изменением требований к программной системе уже

процессе разработки, в основном из-за того, что само существование

в проекта программной системы часто изменяет проблему»» [13]. Как говорит Брукс, «сложность программного обеспечения – отнюдь не случайное его свойство» [12].

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

и компонентов, которые требуются для решения какой-либо

которые затрудняют ра-

например таких, как:

1) системы с обратной связью, которые управляют или сами управ-

ляются событиями физического мира. Для этих систем ресурсы времени и памяти ограничены;

2) системы поддержания целостности информации объемом в сотни

тысяч записей при параллельном доступе к ним.

3) системы управления реальными процессами и контроля за ними, например, диспетчеризация воздушного или железнодорожного транспорта.

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

Можно выделить пять источников сложности программирования:

 решаемая задача;

 язык программирования;

 среда

выполнения программы;

 технологический процесс коллективной разработки;

 стремление к универсальности и эффективности алгоритмов и ти-

пов данных.

Современные крупномасштабные проекты ПО характеризуются следующими особенностями [14]:

 сложностью описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними, что требует тщательного моделирования и анализа данных и процессов);

высокой технической сложностью, определяемой наличием сово-



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

 необходимостью интеграции существующих и вновь разрабаты- ваемых приложений;

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

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

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

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

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

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

3. Отсутствие удовлетворительных средств формального описа- ния поведения программных систем. Известные средства визуализации различных аспектов ПО (UML, семейство IDEF и другие [22–26]) не решают полностью этой задачи,

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

4. Коллективная разработка. Вследствие больших объемов ПС разработка ведется достаточно большим коллективом специалистов, иногда с привлечением субподрядчиков. Обеспечивать целостность и качество проекта в этом случае трудно

из-за сложности организации эффек-

тивного взаимодействия специалистов в таких коллективах.

5. Необходимость увеличения степени повторяемости кодов. Желание использовать ранее созданные компоненты программных систем в дальнейших проектах приводит к их универсализации (усложнению), а также включению не самого эффективного кода в новые разработки.

6. Большая программная система – это крупное капиталовложение, которое

желательно использовать, несмотря на изменение внешних требований, поэтому в процессе эксплуатации приходится решать следующие задачи (сопровождать систему):

 устранение ошибок, не выявленных в ходе разработки и опытной

эксплуатации;

 внесение изменений в систему в ответ на изменившиеся требова-

ния к ней (эволюция системы);

 использование всех возможных и

невозможных способов для под-

держания жизни в устаревающей части системе (сохранение).

Все перечисленные факторы существенно увеличивают сложность

разработки программных систем.

Основные проблемы разработки сложных программных систем связаны с нахождением разумного компромисса (рис. 5) между затратами на разработку (ресурсы и время) и качеством ее результата (возможности). В затраты входят все виды используемых ресурсов, из которых наиболее важны затрачиваемое время, бюджет проекта и персонал.

Рис. 5. Треугольник компромиссов

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

От сложности нельзя избавиться, но

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

Как отмечает Дейкстра: «Способ управления сложными системами был известен еще в древности – разделяй и властвуй» [15]. При проектировании сложной программной системы необходимо разделять ее на все меньшие и меньшие подсистемы, каждую из которых можно совершенствовать независимо от других.

Начало применения этого принципа в программировании было положено алгоритмической декомпозицией. Структурное проектирование «сверху вниз» воспринимается как обычное разделение алгоритмов, где каждый модуль системы выполняет один из этапов общего процесса.

Роль декомпозиции

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

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

Роль абстракции

Будучи не в состоянии полностью воссоздать сложный объект, раз-

работчик

просто игнорирует не слишком важные детали. Это особенно верно, когда предметная область рассматривается с объектно-ориентированной точки зрения, поскольку объекты как абстракции реального мира представляют собой отдельные связные информационные единицы. Повышение уровня абстрагирования – необходимое требование для программиста. Дейкстра подчеркивал [16], что программист должен обладать умением абстрагировать: «Язык программирования – это лишь средство описания абстрактных конструкций. Программист должен иметь способность полностью абстрагироваться от несущественных деталей, думая на нескольких уровнях абстракции одновременно».

Роль иерархии

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

с помощью соответствующих механизмов связи. Структура классов не менее важна: она определяет общность структур и поведения внутри системы.

4. ОРГАНИЗАЦИЯ ПРОЦЕССА ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ЦЕЛЬ ПРОЕКТИРОВАНИЯ

«Цель проектирования – выявление ясной и относительно простой внутренней структуры, иногда называемой архитектурой... Проект есть окончательный продукт процесса проектирования» [17].

Проектирование – процесс составления описания, необходимого для создания в заданных условиях еще не существующего объекта, на основе первичного описания этого объекта и/или алгоритма его функционирования или алгоритма процесса преобразованием (в ряде неоднократным) исходного описания, оптимизацией заданных характеристик объекта и алгоритма его функционирования или алгоритма процесса, устранением некорректности первичного описания и последовательным представлением (при необходимости) описаний на различных языках [18].

Применительно к процессу создания ПО проектирование – процесс определения архитектуры программного обеспечения, компонентов, модулей, интерфейсов и данных для программной системы творения заданных требований [19].

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

Результат проектирования – проектное решение (совокупность проектных решений), удовлетворяющее заданным требованиям и необходимое для создания объекта проектирования.

случаев

для удовле-

<<< < Предыдущая 12 / 142 3 4 5 6 7 8 9 10 11 12 13 14 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]