Файл: Применение объектно-ориентированного подхода при проектировании информационной системы).pdf

Структура Унифицированного языка моделирования

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

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

Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста [6].

Таким образом, применительно к UML, семантика и синтаксис определяют стиль изложения (построения моделей), который объединяет естественный и формальный языки для представления базовых понятий (элементов модели) и механизмов их расширения.

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

Сущности — это определенные в UML три типа понятий [12]:

1. структурная – абстракция, являющаяся отражением концептуального или физического объекта;
2. группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы;
3. поясняющая (аннотационная) – комментарий к элементу диаграммы.

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

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

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

Диаграмма — это группировка элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами [1]. Диаграмма прецедентов отображает функции системы, взаимодействие между актерами и функциями, диаграмма классов — набор классов, интерфейсов и отношений между ними, диаграмма пакетов — набор пакетов и отношений между ними. Диаграмма поведения представлена диаграммой автоматов (отображает состояния сущности и переходы между ними в процессе ее жизненного цикла), диаграммой деятельности (отображает бизнес-процессы в системе и алгоритмы поведения), и диаграммой взаимодействия, которая в свою очередь представлена диаграммой последовательности (отображает последовательность передачи сообщений между объектами и актерами) и диаграммой коммуникации (аналогична диаграмме последовательности, но основной акцент делается на структуру взаимодействия между объектами). Также есть диаграмма реализации, которая также представлена диаграммой компонентов (отображает компоненты системы и связи между ними) и диаграммой развёртывания (отображает размещение компонентов по узлам сети, а также ее конфигурацию) [1].

Все виды отношений UML, используемых на диаграммах для указания связей между сущностями, описываются через ассоциацию (наиболее общий вид отношения, описывающего значимую связь между двумя и более сущностями), агрегацию (подвид ассоциации, описывающей связь «часть–целое» между сущностями одного типа, в котором «часть» может существовать отдельно от «целого»), композицию (подвид агрегации, в которой «части» не могут существовать отдельно от «целого»), зависимость (отношение между двумя сущностями, в котором изменение в независимой сущности может влиять на состояние или поведение другой, зависимой, сущности), обобщение (отношение между обобщенной, родительской, сущностью, и специализированной сущностью — потомком, относящейся к тому же типу) и реализацию (отношение между интерфейсами и классами/компонентами, или между классами и кооперациями, где одна сущность определяет действие, которое другая сущность обязуется выполнить) [14].

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

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

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

Структура Унифицированного процесса

Унифицированный процесс как процесс разработки программного обеспечения представляет собой методологию, отвечающую на вопросы «когда, как, кто, что и с помощью чего реализуется проект?», а именно содержит описание [8][9][12]:

1. технологических процессов (когда) – последовательности видов деятельности (работ), дающих ощутимый результат. Технологический процесс, как правило, представляется в виде диаграммы, отображающей состав работ и их последовательность на той или иной стадии разработки ПО;
2. видов деятельности (как) – работ, осуществляемых исполнителями;
3. исполнителей (кто) – заинтересованных в реализации проекта отдельных лиц или групп. Исполнитель характеризуется строго определенным поведением и обязанностями (ролью). Поведение выражается через виды деятельности, осуществляемые исполнителем, а обязанности – через результаты, получаемые в процессе выполнения работ. В процессе реализации проекта один и тот же человек может выступать в разных ролях;
4. артефактов (что) – информации, создаваемой, изменяемой или используемой исполнителями в проекте. Другими словами, артефакт – это не только то, что создается в результате деятельности (технические артефакты – модели системы, исходные коды программ, готовый программный продукт, документация к нему и т. д.), но и то, что направляет эту деятельность (артефакты управления – календарный план, техническое задание, инструкции и т. д.);
5. используемых утилит (с помощью чего) – программных продуктов, рекомендуемых при выполнении работ.

Технологические процессы

Унифицированный процесс придерживается спиральной модели (стратегии) жизненного цикла ПО.

Каждый виток характеризуется приращением (инкрементом) функциональности системы и одинаковым набором технологических процессов и стадий (в Унифицированном процессе – фаз). В рамках одной стадии также используется идея спиральной разработки. Перед началом выполнения каждой стадии планируется количество итераций, каждая из которых характеризуется некоторым приращением результатов. В рамках одной итерации выполняются основные процессы, начиная от формирования требований и заканчивая внедрением [8][9][12].

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

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

Уточнение (англ. «elaboration»). Целью фазы является разработка архитектуры и моделей проектируемой системы, основным результатом – технический проект.

Конструирование (англ. «construction»). Целью фазы является разработка действующей версии системы, основным результатом – версия системы.

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

Организация работ по содержанию разбита на две группы технологических процессов: основные и вспомогательные [8][9][12].

Артефакты

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

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

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

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

Модель реализации — применяемая на этапе реализации модель, которая содержит описание исполняемой системы (компонентов и схемы развертывания системы).

Модель тестирования — применяемая на этапе тестирования модель, предназначенная для проверки соответствия полученного ПО требованиям.

Модели описывают проектируемую систему с различных точек зрения и на разном уровне абстракции. При этом некоторые элементы (например, диаграммы или классы) могут одновременно входить в разные модели. Более того, один и тот же элемент может входить в две и более моделей с разной степенью детализации. Также модели могут быть вложены друг в друга. В Унифицированном процессе набор получаемых артефактов, как и технологический процесс, также может отображаться в виде диаграммы. [8][12]

1.2. Понятия, относящиеся к утилитам UML-моделирования

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

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