Рациональный унифицированный процесс

ОБЕСПЕЧЕНИЕ

 

Содержание лекции

ЖИЗНЕННЫЙ ЦИКЛ_ 2

Структурные сущности_ 3

РАЦИОНАЛЬНЫЙ УНИФИЦИРОВАННЫЙ ПРОЦЕСС_ 6

РАБОЧИЕ ПРОЦЕССЫ_ 8

МОДЕЛИ_ 8

АНАЛИЗ И ПРОЕКТИРОВАНИЕ_ 9

УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ_ 10

СУЩНОСТИ UML_ 11

ОТНОШЕНИЯ UML_ 13

ДИАГРАММЫ UML_ 14

ПРАВИЛА ЯЗЫКА UML_ 16

ОБЩИЕ МЕХАНИЗМЫ ЯЗЫКА UML_ 17

СИСТЕМЫ И МОДЕЛИ_ 17

Определение технологии конструирования программного обеспечения 19

Классический жизненный цикл_ 19

Стратегии конструирования ПО_ 21

Инкрементная модель_ 21

Быстрая разработка приложений_ 22

Спиральная модель_ 23

Компонентно – ориентированная модель_ 23

ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ_ 24

Вспомогательные процессы ЖЦ ПО_ 25

Организационные процессы ЖЦ ПО_ 27

МОДЕЛИ И СТАДИИ ЖЦ ПО_ 28

Подход RAD_ 33

Модели качества процессов конструирования_ 35

МОДЕЛИ ОЦЕНКИ ХАРАКТЕРИСТИК КАЧЕСТВА И НАДЕЖНОСТИ ПО_ 38

 

ЖИЗНЕННЫЙ ЦИКЛ

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

При создании ПО выделяют пять основных стадий ЖЦ: анализ и формализация требований заказчика;проектирование; реализация; тестирование; внедрение и эксплуатация.
Среди разнообразия ЖЦ можно выделить два основных.

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

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

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

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

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

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

Выбор типа жизненного цикла зависит от ряда субъективных и объективных причин, сопутствующих проекту:

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

Структурные сущности

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

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

Итеративным (iterative) называется процесс, который предполагает управление потоком исполняемых версий системы.

Инкрементный (incremental) процесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий системы, причем каждая следующая версия усовершенствована по сравнению с предыдущей.

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

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

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

Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой. Класс реализует один или несколько интерфейсов.

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

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

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

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

Активным классом (active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие. Активный класс практически полная копия обычного, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов.

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

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

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

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

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

РАБОЧИЕ ПРОЦЕССЫ

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

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

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

МОДЕЛИ

Артефакты в Рациональном Унифицированном Процессе подразделяются на две группы: административные и технические. Технические артефакты делятся на четыре большие подгруппы: группа требований - описывает, что система должна делать; группа проектирования - описывает, как система должна быть построена; группа реализации - описывает сборку разработанных программных компонентов; группа развертывания - содержит все данные, необходимые для конфигурирования предоставленной системы.

Модели - это самый важный вид артефактов в Рациональном Унифицированном Процессе.

Модель (model) - это упрощение реальности; она создается для лучшего понимания разрабатываемой системы. В Рациональном Унифицированном Процессе имеется девять моделей, которые совместно охватывают все важнейшие решения относительно визуализации, специфицирования, конструирования и документирования программной системы:
· модель бизнес-процессов - формализует абстракцию организации;
· модель предметной области - формализует контекст системы;
· модель прецедентов - формализует функциональные требования к системе;
· аналитическая модель (необязательная) - формализует идею проекта;
· проектная модель - формализует словарь предметной области и области решения:
· модель процессов (необязательная) - формализует механизмы параллелизма и синхронизации в системе;
· модель развертывания - формализует топологию аппаратных средств, на которых выполняется система;
· модель реализации - описывает части, из которых собирается физическая система;
· модель тестирования - формализует способы проверки и приемки системы.

 

АНАЛИЗ И ПРОЕКТИРОВАНИЕ

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

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

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

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

Стандарты семейства IDEF - это семейство методологий:

· IDEF0 - стандарт функционального моделирования.

· IDEF1 (X) - стандарт информационного моделирования (ER- диаграммы).

· IDEF2 - стандарт математического моделирования.

· IDEF3 - стандартов моделирования процессов (построение технологических карт).

СУЩНОСТИ UML

В UML имеется четыре типа сущностей: структурные; поведенческие; группирующие; аннотационные.

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

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

ClassName

-PrivateAttribute: char #ProtectedAttribute +PublicAttribute

+Operation1(in S: String) +Operation2()

Интерфейс (interface) - это совокупность операций, которые определяют определенную службу (сервис, набор услуг), которые предоставляет класс или компонент.

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

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

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

Активным классом (active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие. Графически активный класс изображается как простой класс, ограничивается прямоугольником с жирной линией, и включает имя, атрибуты и операции.

ClassName

-PrivateAttribute: char #ProtectedAttribute +PublicAttribute

+Operation1(in S: String) +Operation2()

 

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

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

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

Поведенческие сущности (behavioral things) являются динамическими составляющими модели UML. Это глаголы языка, они описывают поведение модели во времени и в пространстве. Существует всего два основных типа поведенческих сущностей.

Взаимодействие (interaction) - это поведение, суть которого заключается в обмене сообщениями (messages) между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких как сообщения, последовательности действий (поведение, инициированное сообщениями) и связи (между объектами). Графически сообщение изображается в виде стрелки, над которой пишется имя соответствующей операции.

Автомат (state machine) - алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события и реакции на эти события. С помощью автоматов описываются поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы из одного состояния в другое, события - сущности инициирующие переходы и виды действий - реакция на переходы.

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

Такая первичная сущность имеется в единственном экземпляре - это пакет.

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

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

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

ОТНОШЕНИЯ UML

В языке UML определены четыре типа отношений: · зависимость; · ассоциация; · обобщение; · реализация. Эти отношения являются основными связующими конструкциями в UML и применяются для построения корректных моделей.

Зависимость (dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.

Ассоциация (association) - структурное отношение, описывающее совокупность связей, где под связью понимается некоторая смысловая связь между объектами. Разновидностью ассоциации является агрегирование (aggregation) - так называется структурное отношение между целым и его частями. Графически ассоциация изображается в виде линии, рядом с которой могут присутствовать дополнительные обозначения.

Обобщение (generalization) - это отношение "специализация/обобщение", при котором объект специализированного элемента (проще говоря, потомок) может быть подставлен вместо объекта обобщенного элемента (родителя, предка). Как и положено в объектно-ориентированном программировании, потомок (child) наследует структуру и поведение своего предка (parent). Графически отношение обобщения изображается в виде линии с незакрашенной стрелкой, указывающей на предка.

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

Существую также их варианты, например уточнение (refinement), трассировка (trace), включение и расширение для зависимостей.

ДИАГРАММЫ UML

Диаграмма в UML - это графическое представление набора элементов, изображаемое в виде связанного графа с вершинами (сущностями) и ребрами (отношениями).

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

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

Диаграммы объектов (object diagram), на которых представляются объекты и отношения между ними. Это статические снимки экземпляров сущностей, показанных на диаграммах классов.

Диаграммы прецедентов (use case diagram), на которых представлены прецеденты, актеры (частный случай классов), отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения возможностей ее использования. Это вид диаграмм особенно важен при организации и моделирования поведения системы.

Диаграммы взаимодействия, на которых представлены связи между объектами, показаны, в частности, сообщения, которыми объекты могут обмениваться. Обычно рассматриваются два частных случая диаграмм: диаграммы последовательностей (sequence diagram), которые отражают временную упорядоченность сообщений, и диаграммы кооперации (collaboration diagram), на которых показана структурная организация обменивающихся сообщениями объектов. Эти виды диаграмм являются изоморфными, то есть свободно могут быть трансформированы друг в друга.

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

Диаграммы деятельности (activity diagram) - это частный случай диаграмм состояний. На диаграмме представляются переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм относится к динамическим представлениям системы, и является наиболее полезным при моделировании ее функционирования, так как отражает передачу потока управления между объектами.

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

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

ПРАВИЛА ЯЗЫКА UML

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

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

· имена, которые можно давать сущностям, отношениям и диаграммам;

· области действия - контексты, в которых имя имеет некоторое значение;

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

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

· выполнение, что означает выполнить или имитировать некоторую динамическую модель.

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

По этой причине создаются не только хорошо оформленные модели, но и такие, которые:

· содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие);

· неполные (отдельные элементы пропущены);

· несогласованные (целостность модели не гарантируется).

ОБЩИЕ МЕХАНИЗМЫ ЯЗЫКА UML

Моделирование упрощается и ведется более эффективно, если придерживаться некоторых соглашений. Работу с UML существенно облегчает последовательное использование общих механизмов: · спецификации (specifications); · дополнения (adornments); · принятые деления (common divisions); · механизмы расширения (extensibility mechanisms).

При моделировании объектно-ориентированных систем реальность делится с учетом двух методов.

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

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

Механизмы расширения UML включают:

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

· помеченные значения (tagged value), которые расширяют свойства основных конструкций UML, позволяя включать новую информацию в спецификацию элемента;

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

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

 

СИСТЕМЫ И МОДЕЛИ

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

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

В UML предусмотрены средства для графического представления систем и подсистем. Такая нотация позволяет визуализировать декомпозицию системы на меньшие подсистемы.

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

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

Основное отношение между системами и подсистемами - это агрегирование. Система (целое) может состоять из нуля и более подсистем (частей).

Модель - это упрощение реального мира, реальность в ней описывается в контексте моделируемой системы, это абстракция системы.

Классический жизненный цикл

Старейшей парадигмой процесса разработки ПО является классический жизненный цикл (автор Уинстон Ройс, 1970).

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

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

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

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

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

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

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

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

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

Сопровождение – это внесение изменений в эксплуатируемое ПО. Цели изменений: исправление ошибок; адаптация к изменениям внешней для ПО среды; усовершенствование ПО по требованиям заказчика.

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

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

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

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

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

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

Инкрементная модель

Инкрементная модель объединяет элементы последовательной водопадной моделью с итерационной философией макетирования.

Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработке слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте – более сложные возможности редактирования и документирования; в 3-м инкременте – проверку орфографии и грамматики; в 4 – инкременте возможности компоновки страницы.

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

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

Современная реализация инкрементного подхода программирование XP (Кент Бек, 1999). Оно ориентировано на очень малые приращения функциональности.

Спиральная модель

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

Достоинство спиральной модели: