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

Содержание:

Введение

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

Цель данной работы является обзор и анализ основных принципов и особенностей объектно-ориентированного подхода, а также его неотъемлемого инструмента унифицированного языка моделирования (UML).

Задачи работы:

• Обзор основных понятий и концепций объектно-ориентированного подхода

• Обзор основных структур унифицированного языка моделирования

• Обзор CASE-средств для построения диаграмм UML.

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

В заключении приведены основные выводы, возникшие в ходе выполнения данной работы.

Глава 1. Сущность объектно-ориентированного подхода

1.1 Сущность объектно-ориентированного подхода

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

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

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

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

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

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

Наиболее популярными методологиями, поддерживающими данный подход, в настоящий момент являются:

- Унифицированный процесс (Unified Process, UP);

- экстремальное программирование (eXtreme Programming, XP);

- гибкое моделирование (Agile Modeling, AM).

Базовым средством фиксации (документирования) результатов проектирования систем посредством этих методологий является Унифицированный язык моделирования (Unified Modeling Language, UML).

1.2 Основные понятия, используемые в объектно-ориентированном подходе

Термин «объект» или эквивалентные ему понятия появились практически независимо в различных областях, связанных с компьютерами, в процессе разработки]:

-архитектуры компьютеров (Burroughs 5000, Plessey 250, IBM System/38, Intel 432);

-объектно-ориентированных операционных систем (Plessey/System 250, Secure UNIX, StarOS, iMax);

-объектно-ориентированных языков программирования (Simula, Smalltalk, Modula);

-теории баз данных (модели «сущность-связь»);

-систем искусственного интеллекта (фреймы).

При разработке программного обеспечения термин «объект» впервые был введен Оле-Джоаном Далем, Бьорном Мюрхогом и Кристеном Ныгардом из Норвежского вычислительного центра (г. Осло). Они разработали язык Simula 67, созданный на основе языка Algol-60 и предназначенный для моделирования и описания сложных систем. Однако по-настоящему широкое внедрение этой идеи произошло при разработке языка SmallTalk в 1990 г. Аланом Кейем из Исследовательского центра фирмы Xerox (г. Пало-Альто). В SmallTalk использовались только объектно-ориентированные конструкции.

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

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

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

Индивидуальность – это свойство сущности, с помощью которого ее можно отличить от других. Т. е., говоря об объекте «поезд», имеется в виду не обобщенное понятие поезд, как нечто состоящее из локомотивов и вагонов, а конкретный грузовой поезд с номером 1025, весом 4600 т, ведомый электровозом переменного тока ВЛ80Т с серийным номером 027, состоящий из четырехосных полувагонов с конкретными номерами и т. д. В то же время степень абстракции с точки зрения решаемой задачи может быть и более высокой. Например, при выполнении тяговых расчетов к графику движения поездов не требуется информация о серийных номерах локомотивов и вагонов, т. е. нет потребности в отличии друг от друга электровозов ВЛ80Т с серийными номерами 027 и 028.

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

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

Говоря об объектно-ориентированном подходе, в первую очередь отмечают наследование, инкапсуляцию и полиморфизм. Эти механизмы и принципы проектирования более естественно и полно реализованы в объектно-ориентированном подходе по сравнению со структурным.

Наследование – принцип, в соответствии с которым знание об общей категории разрешается применять для более узкой. Применительно к классам это означает, что дочерний класс (узкая категория) полностью включает в себя (наследует) все атрибуты и методы, определенные в родительском классе (общей категории). При этом в дочернем классе могут быть определены дополнительные атрибуты и методы. Например, дочерний класс «круг» будет наследовать от родительского класса «геометрическая фигура» все атрибуты (x, у – координаты центра фигуры, color – цвет фона и т. д.) и все методы (draw() – нарисовать фигуру, move(dx, dy) – переместить фигуру и т. д.), а также иметь дополнительный атрибут (r – радиус).

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

Полиморфизм – принцип построения элементов модели так, чтобы они могли принимать различные внешние формы или функциональность (поведение) в зависимости от обстоятельств. Например, методы draw() (нарисовать) или calculateS() (рассчитать площадь) для классов «круг» и «ромб», определенных путем наследования атрибутов и методов родительского класса «фигура», алгоритмически должны быть реализованы по-разному.

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

1.3 Базовые составляющие объектно-ориентированного подхода

Базовыми составляющими объектно-ориентированного подхода являются:

- Унифицированный процесс;

- Унифицированный язык моделирования;

- шаблоны проектирования.

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

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

На стадиях анализа и проектирования часто используются так называемые шаблоны (паттерны) проектирования. Шаблон – это именованная пара «проблема/решение», содержащая готовое обобщенное решение типичной проблемы. Как правило, шаблон помимо текстового описания содержит также одну или несколько диаграмм UML (например, диаграммы классов, последовательности и/или коммуникации), графически иллюстрирующих состав и структуру классов, а также особенности их взаимодействия при решении поставленной проблемы. Шаблоны разрабатываются опытными профессионалами и являются проверенными, эффективными (порой оптимальными) решениями. Применение шаблонов может резко сократить затраты и повысить качество разработки ПО.

1.4 Преимущества объектно-ориентированного подхода

В отличие от структурного подхода объектно-ориентированный имеет ряд преимуществ:

-описание системы в виде объектов больше соответствует содержательному смыслу предметной области. Например, при использовании структурного подхода БД должна удовлетворять требованиям нормализации, в соответствии с которыми данные по одному и тому же объекту (сущности из реального мира) могут храниться в нескольких таблицах;

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

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

о адаптации системы к изменению существующих или появлению новых требований;

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

о повторного использования компонентов;

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

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

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

Унифицированный процесс как процесс разработки программного обеспечения представляет собой методологию, содержащую детальное описание работ по созданию и внедрению ПО (авторы Ивар Якобсон, Гради Буч и Джеймс Рамбо). Она отвечает "на вопросы когда, как, кто, что и с помощью чего реализуется проект", а именно содержит описание:

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

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

Рисунок 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 в силу своей выразительности и однозначности позволяет непосредственно исполнять модели, имитировать поведение систем и контролировать действующие системы.

UML - это язык документирования

Компания, выпускающая программные средства, помимо исполняемого кода производит и другие артефакты, в том числе следующие:

• требования к системе;
• архитектуру;
• проект;
• исходный код;
• проектные планы;
• тесты;
• прототипы;
• версии, и др.

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

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

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

2.2 Где используется UML

Язык UML предназначен прежде всего для разработки программных систем. Его использование особенно эффективно в следующих областях:

• информационные системы масштаба предприятия;
• банковские и финансовые услуги;
• телекоммуникации;
• транспорт;
• оборонная промышленность, авиация и космонавтика;
• розничная торговля;
• медицинская электроника;
• наука;
• распределенные Web-системы.

2.3 Преимущества UML

UML объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках;

UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

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

UML получил широкое распространение и динамично развивается.

2.4 Строительные блоки UML

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

• сущности;
• отношения;
• диаграммы.

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

Обобщение (Generalization) - это отношение "специализация/обобщение", при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка).

Рисунок 10. Обобщения

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

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

Рисунок 11 Реализации

Таким образом, в UML выделяют девять типов диаграмм:

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

2.5 Правила языка UML

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

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

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

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

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

Почему нужно несколько видов диаграмм

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

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

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

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

Диаграмма - это графическое представление множества элементов. Обычно изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Примеров диаграмм можно привести множество. Это и знакомая нам всем со школьных лет блок-схема, и схемы монтажа различного оборудования, которые мы можем видеть в руководствах пользователя, и дерево файлов и каталогов на диске, которое мы можем увидеть, выполнив в консоли Windows команду tree, и многое-многое другое. В повседневной жизни диаграммы окружают нас со всех сторон, ведь рисунок воспринимается нами легче, чем текст...

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

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

2.6 Виды диаграмм

UML 1.5 определял двенадцать типов диаграмм, разделенных на три группы:

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

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

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

2.6.1 Диаграмма прецедентов (use case diagram)

Любые (в том числе и программные) системы проектируются с учетом того, что в процессе своей работы они будут использоваться людьми и/или взаимодействовать с другими системами. Сущности, с которыми взаимодействует система в процессе своей работы, называются экторами, причем каждый эктор ожидает, что система будет вести себя строго определенным, предсказуемым образом. Попробуем дать более строгое определение эктора. Для этого воспользуемся замечательным визуальным словарем по UML Zicom Mentor:

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

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

Рисунок 12. Эктор

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

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

Рисунок 13. Прецендет

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

Рисунок 14 Пример диаграммы прецедентов.

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

Еще один пример (рис. 2.4).

Рисунок 14. Пример диаграммы прецедентов.

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

Подводя итоги, можно выделить такие цели создания диаграмм прецедентов:

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

2.6.2 Диаграмма классов (class diagram)

Класс (class) - категория вещей, которые имеют общие атрибуты и операции.

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

Классы используются в процессе анализа предметной области для составления словаря предметной области разрабатываемой системы. Это могут быть как абстрактные понятия предметной области, так и классы, на которые опирается разработка и которые описывают программные или аппаратные сущности.

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

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

Рисунок 15. Диаграмма классов

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

Рисунок 16. Диаграмма классов

2.6.3Диаграмма объектов (object diagram)

Как же обозначается объект в UML? А очень просто - объект, как и класс, обозначается прямоугольником, но его имя подчеркивается. Под словом имя здесь мы понимаем название объекта и наименование его класса, разделенные двоеточием. Для указания значений атрибутов объекта в его обозначении может быть предусмотрена специальная секция. Еще один нюанс состоит в том, что объект может быть анонимным: это нужно в том случае, если в данный момент не важно, какой именно объект данного класса принимает участие во взаимодействии.

Рисунок 17.Диаграмма объектов

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

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

Рисунок 18. Диаграмма объектов

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

2.6.4 Диаграмма последовательностей (sequence diagram)

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

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

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

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

Рисунок 19. Диаграмма последовательностей

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

2.6.5 Диаграмма взаимодействия (кооперации, collaboration diagram)

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

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

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

Рисунок 20.Диаграмма взаимодействия

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

2.6.6 Диаграмма состояний (statechart diagram)

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

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

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

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

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

Приведем пример простейшей диаграммы состояний (рис. 21):

Рисунок 21. Диаграмма состояний

2.6.7 Диаграмма активности (деятельности, activity diagram)

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

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

Рисунок 22. Диаграмма активности

2.6.8 Диаграмма развертывания (deployment diagram)

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

Рисунок 23. Диаграмма развертывания

Глава 3. Обзор CASE-средств для построения диаграмм UML

Чтобы облегчить труд проектировщика, были созданы CASE-средства - программы специального вида.

CASE-средства (от Computer Aided Software/System Engineering) - позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE-средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций. Применимы практически во всех сферах деятельности. Результат использования CASE-средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок.

3.1 IBM Rational Rose

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

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

• Rational Rose Modeler

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

• Rational Rose Professional

Как видно из названия, это профессиональная редакция продукта. В зависимости от выбранного языка программирования позволяет выполнять прямое и обратное проектирование. Rose Professional заказывается только в определенной конфигурации (например, Rose Professional С++ или Rose Professional С++ DataModeler). Rational Rose Professional, конечно, не создает 100 % исполняемого кода. На выходе разработчик получает каркасный код информационной системы на определенном (заказанном) языке программирования, который впоследствии нужно еще программировать и программировать. Продукт нацелен и на аналитиков, и на разработчиков.

• Rational Rose RealTime

Версия продукта, созданная специально для получения 100 % исполняемого кода в реальном масштабе времени. Конечно, RealTime позволяет проводить прямое и обратное проектирование на языках С или С++. По заверениям разработчиков, на выходе модель автоматически компилируется и собирается в исполняемый файл. Само собой, продукт предназначен именно для разработчиков.

• Rational Rose Enterprise

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

• Rational Rose DataModeler

Это не конкретный вариант продукта, а функциональность по проектированию баз данных. Функции DataModeler входят в состав Rose Enterprise или Professional.

Рисунок 24. Rational Rose

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

• прямое и обратное проектирование на языках: ADA, Java, С, C++, Basic;
• поддержка технологий COM, DDL, XML;
• возможность генерации схем БД Oracle и SQL.

Также Rational Rose имеет открытый API, позволяющий самому создавать модули для других языков программирования. На рынке уже имеется достаточное число модулей для популярных языков программирования и RAD-систем, таких как Delphi, ErWin, Jbuilder, VisualCafe, Jdeveloper, VisualAge SmallTalk. Одна из ведущих компаний в области создания дополнительных модулей - Ensemble Systems (http://www.ensemble-systems.com/).

С помощью Visual Modeler можно рисовать диаграммы классов в трех различных нотациях - нотации Буча, ОМТ и на UML. По диаграммам классов можно провести генерацию каркасного кода (на C++, VB или Java). Такая генерация программного кода называется прямым проектированием (forward engineering). Взаимозависимости классов, изображенных на диаграмме классов, отображаются в программном коде.

Большой интерес представляет обратное проектирование (reverse engineering), когда по исходному коду восстанавливается диаграмма классов, позволяющая понять структуру программы. Это тоже можно делать с помощью Visual Modeler, причем на основе Microsoft Foundation Classes (MFC) К ограничениям Visual Modeler относится тот факт, что он не поддерживает диаграммы развертывания, описывая лишь внутреннюю функциональность создаваемой системы.

Также Rational Rose интегрируется с Visual Component Manager, репозиторием Microsoft Repository, системой управления версиями Microsoft Visual SourceSafe и Rational ClearCase.

3.2 Borland Together

Очень симпатичный продукт от Borland. Borland Together ControlCenter - это интегрированная платформа разработки, позволяющая упростить и ускорить анализ, дизайн, разработку и развертывание комплексных корпоративных приложений. Эти возможности сочетаются в одном интегрированном решении с поддержкой UML, помогающем командно разрабатывать высококачественные системы быстрее и эффективнее. Технология Borland LiveSource, интегрированная в ControlCenter, автоматически синхронизирует все артефакты, так что изменения в них не прерывают процесс разработки (что очень похоже на концепцию "живых документов" от Microsoft). Таким образом, ситуация, когда модель и код не соответствуют друг другу, теперь невозможна - любые изменения в модели сразу же отображаются в коде и наоборот. ControlCenter предоставляет единую среду разработки, общий язык, диаграммы и строительные блоки, избавляя команду от необходимости использовать несколько продуктов, переключаясь между ними.

Вот некоторые особенности Borland Together:

• Поддержка XP ("экстремальное программирование")

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

• Ускорение процессов разработки путем применения паттернов

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

• Развертывание на несколько серверов приложений выполняется быстро, без перекодирования

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

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

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

Из вышесказанного становится ясно, что Borland Together - это нечто гораздо большее, чем просто пакет для рисования "картинок в стиле UML". Мы уже говорили о некоторых дополнительных возможностях программы, но какие же возможности предоставляет Together именно в плане визуального моделирования?

• Как уже говорилось ранее, поддержка всех основных видов диаграмм UML, включая диаграммы классов, прецедентов, последовательностей, кооперации, деятельности, состояния, компонентов…
• Поддержка ER-диаграмм (схем баз данных).
• Генерирование исходного кода из диаграмм последовательностей и обратное проектирование существующего кода в одну или более диаграмм последовательностей.
• Моделирование бизнес-процессов с помощью соответствующих диаграмм.
• Поддержка паттернов, о чем мы уже упоминали ранее, включая построитель шаблонов кода и множество видов встроенных паттернов.
• Эффективные метрики контроля качества для разных языков с возможностью их повторного использования.
• Простая генерация актуальной проектной документации в стиле "нескольких щелчков мыши" (а-ля Microsoft) или через командную строку в виде HTML, RTF или текстовом формате.
• Удобный настраиваемый редактор исходного кода.
• Визуальный построитель графического интерфейса пользователя.
• Плюс многое, многое другое...

Рисунок 25. Borland Together

3.3 Microsoft Visio

Visio - решение для построения диаграмм от Microsoft. По словам разработчиков, Visio помогает преобразовать технические и бизнес-концепции в визуальную форму. И действительно, этот пакет из семейства Microsoft Office предназначен исключительно для рисования диаграмм. Visio имеет некоторые дополнительные возможности, но все же, повторим, по большей мере - это только средство для иллюстрирования документов MS Office, "не дотягивающее" до уровня пакетов, которые мы описывали ранее.

• Изобразительные же возможности Visio действительно весьма широки:
• Используя предопределенные фигуры Visio Professional , drag-and-drop и мастера, вы можете быстро и просто создавать понятные и информативные диаграммы.
• Возможности Visio можно легко расширять, используя новые шаблоны бизнес-диаграмм. Вы можете включать внешние источники данных, хранилища или коллекции хранимых шаблонов.
• В Visio можно прототипировать интерфейс приложений с помощью встроенных шаблонов пользовательского интерфейса Microsoft Windows XP, что позволяет создавать модель пользовательского интерфейса в стандартном Windows XP-стиле.
• Можно легко рисовать диаграммы сетевых ресурсов, иллюстрирующие развертывание нового ПО на существующие сетевые ресурсы.
• Visio Professional также тесно интегрируется с Microsoft Office Project, что позволяет, например, импортировать оттуда задачи для членов команды.
• С помощью шаблонов UML вы можете создавать UML-диаграммы статической структуры ПО или проводить обратное проектирование с помощью Visio 2003 Reverse Engineer Wizard.
• Visio 2003 может документировать для вас структуру существующих веб-сайтов, помогая таким образом в разработке, реализации или интеграции веб-приложений.
• Можно также создавать отчеты, сохранять диаграммы как вебстраницы и еще многое-многое другое...

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

Внешне Visio похожа на другие программы семейства Microsoft Office, хотя и выглядит немного более архаично. Особенно это заметно в версии 2007 - интерфейс Visio 2007 разительно отличается от остальных приложений MS Office и выглядит так, будто это программа из предыдущей версии "офиса".

Рисунок 26. Microsoft Visio

Если верить разработчикам программы, есть по крайней мере 10 причин, чтобы использовать Visio:

• Документирование и анализ бизнес-процессов

Проектирование, документирование и анализ бизнес-процессов, используя шаблоны и символы, поддерживающие управление бизнес-процессами (BPM), включая Six Sigma quality improvement и ISO 9000-документацию.

• Отслеживание комментариев членов команды

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

• Сотрудничество по-новому

За этим рекламным лозунгом скрывается интеграция с Microsoft SharePoint и возможность экспорта диаграмм в SVG-формат или сохранения их как веб-страниц.

• Поддержка Tablet PC

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

• Инструменты для мозгового штурма

Visio можно использовать для генерации и структурирования идей во время сессий мозгового штурма. Потом диаграммы, полученные в результате мозгового штурма, можно экспортировать в Microsoft Word, Microsoft Excel или XML, положив таким образом хорошее начало созданию других бизнес-файлов.

• Простое создание и использование технических диаграмм

Как уже говорилось выше, в Visio можно создавать диаграммы баз данных, инженерные диаграммы, сетевые, диаграммы разработки ПО и веб-приложений.

• Более быстрое создание и редактирование диаграмм

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

• Visio поддерживает множество локальных языков

Visio доступна на 17 языках, включая улучшенную поддержку азиатских языков и двунаправленного текста. Впрочем, вряд ли этот факт может считаться серьезным преимуществом людьми, которые "по жизни" пользуются исключительно англоязычным ПО.

• Отличная интеграция с другими приложениями MS Office

3.4 Dia

Dia – программа для создания диаграмм, базирующаяся на gtk+ и распространяющаяся по лицензии GPL. Dia создавалась по подобию коммерческой Windows-программы Visio. Она может быть использована для рисования многих видов диаграмм. На данном этапе развития Dia имеет средства для рисования:

• ER-диаграмм (проектирование баз данных);
• диаграмм UML;
• блок-схем;
• сетевых диаграмм;
• простых схем электрических цепей;
• и многого другого…

Возможности программы легко расширить путем введения новых символов, определяемых в XML-файлах с помощью подмножества тегов SVG для изображения фигур. Dia может загружать и сохранять диаграммы в своем XML-формате (по умолчанию - сжимаемом gzip для экономии места), может экспортировать диаграммы в EPS- или SVG-формат и печатать их (включая разбивку на несколько страниц).

Dia - самая простая программа в этом обзоре. Она работает под управлением Linux в среде Gnome, требует библиотек gtk+ и glib. Существует порт Dia для Windows, который производит в целом приятное впечатление. Несмотря на то что программа еще не дошла до стадии финального релиза, Dia уже существует в состоянии, пригодном для использования, и продукт все время динамично развивается. Да, кстати, Dia поддерживает множество языков и региональных стандартов, в том числе и русский с украинским.

Интерфейс Dia похож на интерфейс Gimp. Этот стиль интерфейса, когда панель инструментов, рабочая область и другие элементы организованы в виде отдельных окон, немного непривычен для глаз пользователей Windows. Но главное - Dia абсолютно бесплатна. Вы можете загрузить с домашней страницы и исполняемый файл, и исходные коды, можете вносить изменения в код, распространять его и т. д. (рис. 27).

Рисунок 27. Dia

3.5 StarUML

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

StarUML - это пакет с открытым программным кодом, написанный на Delphi и работающий под управлением ОС семейства Windows. StarUML поддерживает UML 2.0 и MDA. Функционал пакета можно расширить за счет использования плагинов, так что каждый желающий может создать свой собственный модуль для StarUML на любом COM-совместимом языке (C++, Delphi, C#). На сайте проекта доступны для загрузки несколько модулей, добавляющих поддержку ER-диаграмм (Entity-Relation Diagram), некоторых профайлов UML, например SPEM (Software Process Engineering Metamodel), WAE (Web Application Extension), интеграцию с MS Word и др.

Конек StarUML - это его юзабилити. Интерфейс пакета не может похвастаться красивыми разноцветными "пластмассовыми" элементами управления, как java-программы, рассмотренные выше, но очень удобен и интуитивно понятен. Больше всего StarUML напоминает... Microsoft Visual Studio (Enterprise Architect тоже чем-то напоминал MSVS, но здесь мы видим просто шедевр имитации). Кодогенерация тоже есть. "Прямо из коробки" пакет способен выполнять кодогенерацию на языках C++, C#, Java. А если использовать шаблоны, имеющиеся на сайте StarUML, то можно добавить поддержку PHP и некоторых других языков (рис. 28).

Рисунок 28. StarUML

Кроме " Word", StarUML способен создавать документацию в виде текстовых файлов, файлов MS Excel и MS PowerPoint.

Заключение

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

• На данный момент на рынке присутствует огромное количество и полноценных средств UML-моделирования, и программ для рисования диаграмм, в том числе и UML.
• Такие продукты, как Borland Together, StarUML и Dia, могут быть загружены с сайта производителя абсолютно бесплатно.
• StarUML выглядит наиболее функциональным из бесплатных продуктов и может служить полноценной заменой коммерческим программам для UML-моделирования.
• Выбор средства UML-проектирования - вопрос сложный и неоднозначный, и решить его каждый должен для себя сам, исходя из своих потребностей, уровня знаний и т. д.

Список использованной литературы

1. ГОСТ 34.003-90. Автоматизированные системы. Термины и определения.

2. ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств.

3. ОРММ ИСЖТ 2.01–00. Требования к составу, содержанию и оформлению документов при создании ИС. – М. : ВНИИАС МПС России, 2000. – 62 с.

4. Баркер, Р. CASE*Method. Моделирование взаимосвязей между сущностями / Р. Баркер. – М., 2014. – 233 с.

5. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М. : Бином, 2014. – 560 с.

6. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2014. - 432 с.

7. Диго С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2005. – 592 с.

8.Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 2015. – 176 с.

9.Змитрович А. И, Интеллектуальные информационные системы. – Мн.: НТООО "ТетраСистемс", 2007.

10.Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). – М.: Лори, 2009.

11. Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. - М.: Издательский дом «Вильямс», 2014. - 496 с.

12. Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ - Петербург, 2014. – 576с.

13.Лешек А. Мацяшек Анализ и проектирование информационных систем с помощью UML 2.0 [пер. с англ.] - 3-е изд. - М. Вильямс 2008 - 816 с. ил.

14. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML – www.intuit.ru

15. Орлов, С.А. Технологии разработки программного обеспечения: учеб. / С.А. Орлов. – СПб. : Питер, 2014. – 464 с.

16. Петров, В.И. Информационные системы / В.Н. Петров. – СПб. : Питер, 2013. – 688 с.

17. Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2014. – 496 с.

18. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2014. - 496 с.