Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Учебное пособие.doc
Скачиваний:
434
Добавлен:
04.06.2015
Размер:
2.33 Mб
Скачать
      1. Пятый этап – разработка, ориентированная на архитектуру иCase-технологии (с началаXxIв. До нашего времени)

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

В ноябре 1997 года после продолжительного процесса объединения различных методик, группа OMG(ObjectManagementGroup) приняла получившийся в результате унифицированный язык моделирования (UnifiedModelLanguage–UML) в качестве стандарта. В 2001 году членыOMGначали работу над новой версиейUML, добавляя в неё недостающие элементы и устраняя недостатки, выявленные вUML1. ВерсияUML2 была принята в 2004 году. С официальной спецификациейUMLможно ознакомится на веб-сайтеOMGпо адресуwww.omg.org.

Идея создания языка UMLвключала в себя не только реализацию стандарта для документирования и общения разработчиков, но и реализацию возможности использованияUMLкак язык программирования. Этот момент вызывал массу проблем для реализации, так как язык визуального моделирования по определению не мог содержать в себе всей выразительности объектно-ориентированных языков в плане проектирования (программирования) динамики и реализации алгоритмов. Нужен был язык, который на более высоком (абстрактном) уровне смог бы обеспечить разработку наUML. Такой язык был создан – это объектный язык ограниченийOCL(objectconstraintlanguage).

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

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

    1. Эволюция моделей жизненного цикла программного обеспечения

      1. Каскадная модель

Первоначально (1970-1985 годы) была предложена и использовалась каскадная схема разработки программного обеспечения (Рис. 1 .9), котораяпредполагала, что переход на следующую стадию осуществляется после того, как полностью будут завершены проектные операции предыдущей стадии и получены все исходные данные для следующей стадии.

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

Рис. 1.9.Каскадная модель разработки программного обеспечения

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

Рис. 1.10.Каскадная модель разработки ПО с промежуточным контролем

Охарактеризуем содержание основных этапов.

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

Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Поскольку ПО является лишь частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, базами данных). На этом же этапе начинается решение задачи планирования проекта ПО. В ходе планирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.

Анализ требований относится к программному элементу – программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

Все определения документируется в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Проектирование состоит в создании представлений:

  • архитектуры ПО;

  • модульной структуры ПО;

  • алгоритмической структуры ПО;

  • структуры данных;

  • входного и выходного интерфейса (входных и выходных форм данных).

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

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

Тестирование – выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение – это внесение изменений в эксплуатируемое ПО. Цели изменений:

  • исправление ошибок;

  • адаптация к изменениям внешней для ПО среды;

  • усовершенствование ПО по требованиям заказчика.

Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла к существующей программе, но не в разработке новой программы.

Как и любая инженерная схема, классический жизненный цикл имеет достоинства и недостатки.

Достоинства классического жизненного цикла:

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

  2. простота планирования процесса разработки.

Недостатки классического жизненного цикла:

  1. реальные проекты часто требуют отклонения от стандартной последовательности шагов;

  2. цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);

  3. результаты проекта доступны заказчику только в конце работы.

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