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

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

- видов деятельности (как) – работ, осуществляемых исполнителями;

Рисунок 1. Вид деятельности

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

Рисунок 2. Исполнитель

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

Рисунок 3. Примеры артефактов

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

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

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

Рисунок 4. Спиральная стратегия жизненного цикла

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

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

Рисунок 5. Интенсивность процессов при создании версии информационной системы

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

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

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

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

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

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

Вспомогательные технологические процессы обеспечивают выполнение основных и рассмотрены во второй части и в.

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

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

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

Рисунок 6. Обобщенная схема технологического процесса "Управление проектом"

 1.7 Артефакты

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

Таблица 1. Краткая характеристика моделей

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

Рисунок 7. Модель

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

Рисунок 8. Способы отображения вложенности моделей

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

Рисунок 9. Диаграмма артефактов технологического процесса "Управление проектом"

Глава 2 Унифицированный язык моделирования UML.

2.1 Язык UML

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

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

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

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

UML - это язык визуализации.

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

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

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

UML - это язык специфицирования

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

UML - это язык конструирования

UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования.

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

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