К средствам данного уровня можно отнести, например, Telelogic System Architect, Telelogic Focal Point, Telelogic Dashboard, средства линейки AllFusion Modeling Suite.

2. Средние (Middle) CASE-средства

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

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

CASE-средства данного уровня зачастую поддерживают прототипирование и автоматическое документирование.

К CASE-средствам данного уровня можно отнести, например, линейку AllFusion Modeling Suite, средства Telelogic DOORS, Telelogic Modeler, Telelogic Tau, Telelogic Rhapsody, Telelogic Statemate, Telelogic DocExpress.

3. Нижние (Lower) CASE-средства

CASE-средства данного уровня поддерживают вторую половину работ процесса разработки ПС. Содержат графические средства, исключающие необходимость разработки физических мини – спецификаций для программных модулей. Спецификации представляются обычно в виде моделей, которые непосредственно преобразуются в программные коды разрабатываемого программного средства или системы. Автоматически генерируется до 90 % кодов. Входной информацией для кодогенераторов являются спецификации, разработанные как в CASE-средствах данного уровня, так и в CASE-средствах среднего уровня.

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

К CASE-средствам данного уровня можно отнести AllFusion Data Modeler, Telelogic Rhapsody, Telelogic Tau, Telelogic Statemate, Telelogic TAU Logiscope, Telelogic Change, Telelogic Synergy, Telelogic DocExpress.

Следует отметить, что в состав CASE-средств среднего и высокого уровней интегрированности обычно входят инструментальные средства, относящиеся к нескольким уровням. Линейки CASE-средств, предназначенные для поддержки всего ЖЦ ПС и систем, включают в свой состав средства всех трех уровней.

---

Резюме

Классификация по уровням связана с областью действия CASE-средств в ЖЦ ПС и систем. Различают верхние, средние и нижние CASE-средства. Линейки CASE-средств включают в свой состав средства всех трех уровней.
1.3 Модели процесса разработки программного обеспечения
Исторически в ходе развития теории проектирования программного обеспечения и по мере его усложнения утвердились четыре основные модели ЖЦ.

Первой по времени появления и самой распространенной явилась каскадная модель (рисунок 1.1).



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

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

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

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

Следующей стадией развития теории проектирования ПО стала итерационная модель ЖЦ, или так называемая поэтапная модель с промежуточным контролем (рисунок. 1.2). Основной ее особенностью является наличие обратных связей между этапами, вследствие этого появляется возможность проведения проверок и корректировок проектируемой ИС на каждой стадии разработки. В результате трудоемкость отладки по сравнению с каскадной моделью существенно снижается. Итерационность модели проявляется в обработке ошибок, выявленных промежуточным контролем. Если на каком-либо этапе в ходе промежуточной проверки обнаружена ошибка, допущенная на более ранней стадии разработки, необходимо повторить весь цикл работ этой стадии. При этом анализируются причины ошибки и корректируются в случае необходимости исходные данные этапа или его содержание (последовательность действий).



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

---

Рисунок 1.3 – Спиральная модель жизненного цикла ПО
Третья модель ЖЦ ПО — спиральная (spiral) модель (рисунок 1.3) — поддерживает итерации поэтапной модели, но особое внимание уделяется начальным этапам проектирования: анализу требований, проектированию спецификаций, предварительному проектированию и детальному проектированию. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии ПО, уточняются цели и требования к про грамм ному обеспечению, оценивается качество разработанного фрагмента или версии и планируются работы следующей стадии разработки (витка). Таким образом, углубляются и конкретизируются все детали проектируемого ПО, в результате получается продукт, который удовлетворяет всем требованиям заказчика.
RationalObjectoryProcess— модель жизненного цикла (методология объектно-ориентированного программирования)

Известно, что объектно-ориентированное проектирование программного обеспечения стало результатом появления объектно-ориентированного программирования (ООП), т. е. применение новой методологии, как псегда¹, началось с этапа кодирования. Ранние стадии описания предметной области и разработки архитектуры системы не поддерживались, первые варианты использования объектно-ориентированной методологии в большей степени являлись чистым повторением принципов ООП. Такие вопросы» как декомпозиция предметной области, спецификация требований, интерфейс пользователя, не рассматривались, однако успехи объектно-ориентированного программирования заставили распространить новую технологию на весь жизненный цикл ПО. В результате все преимущества подхода применяются не только в процессе кодирования, но и на более ранних этапах. Таким образом, были определены основные компоненты методологии:

• 
  модель жизненного цикла;
  
• 
  действия;
  
• 
  нотация языка.
  

Жизненныйцикл UML (Rational Objectory Process)

Фирма Rational Software, разработавшая язык UML (Unified Modeling Language — унифицированный язык моделирования), предложила также и свою модель ЖЦ, которая называется Rational Objcctory Process (ROP). Означенная технология прямого перс-вода не имеет, так как rational в данном случае употребляется в значении «рациональный» и как название фирмы одновременно, во-вторых, слова objectory в английском языке не существует, его лингвообразованис аналогично слову repository (накопитель).

---

Перечислим основные свойства ROP-технологии.

Rational Objectory Process — итеративный процесс, в течение которого происходит последовательное уточнение результатов.

Rational Objectory Process направлен именно на создание моделей, а не на разработку каких-либо других элементов проекта (например, текстовых документов).

Действия Rational Objectory Process определяются в первую очередь блоками использования (use case) (рисунок 1.4).



Рисунок 1.4 – Молель жизненного цикла UML
Rational Objectory Process разбит на циклы, каждый из которых, в свою очередь, состоит из четырех фаз:

• 
  начальная стадия (Inception);
  
• 
  разработка (Elaboration);
  
• 
  конструирование (Construction);
  
• 
  ввод в эксплуатацию (Transition).
  

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

Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и приниматься критически важные решения о дальнейшей разработке.

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

Окончанием начального этапа могут служить следующие результаты:

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

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

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

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

---

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

• 
  оценка времени реализации каждого варианта использования;
  
• 
  идентификация всех наиболее серьезных рисков и возможности их ликвидации.
  

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

При этом необходимо отмстить следующее:

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

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

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

---

Смотрите также файлы

• Практикум по курсу Базы данных для студентов.docx

• Р. А.адырлов, Н.. Беристемова.docx

• Контрольная работа по дисциплине Электромагнитная совместимость и средства защиты Тема Расчет характеристик питания нагрузок в сети электроснабжения железных дорог.docx

• Цифровые компетенции Цифровая безопасность Цифровое потребление.docx

• Специальные пожарные автомобили.doc