ПРОГРАММНЫЕ ПРОДУКТЫ ДЛЯ АВТОМАТИЗАЦИИ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Объект исследования – проектирование информационных систем.

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

Для достижения поставленной цели необходимо решить следующие задачи:

1. Изучить базовые понятия информационных систем.

2. Описать основные принципы проектирования информационных систем. Рассмотреть модели, используемые при проектировании информационных систем.

3. Описать основные понятия объектно-ориентированного подхода при проектировании.

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

ГЛАВА 1. ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

Информация – это сведенья о лицах, предметах, фактах, событиях, явлениях и процессах независимо от их представления.

Данные – информация, которая представлена в форме, пригодной для обработки с помощью автоматических средств, компьютера [1].

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

1.1 Этапы проектирования информационных систем

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

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

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

На этапе проектирования следует описать внутреннюю структуру продукта в виде диаграмм и текстов.

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

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

Рисунок 1. Каскадная модель процесса разработки информационной системы

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

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

1.2 Основные принципы проектирования информационных систем

Переход от технического задания к описанию информационной системы называется проектированием.

Общие принципы анализа и проектирования информационных систем состоят в следующем: [14].

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

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

3. Принцип концептуальной общности на всех этапах жизненного цикла.

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

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

6. Принцип объединения требует единого представления одного и того же элемента в разных моделях.

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

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

9. Принцип согласованности – данный принцип проектирования информационных систем предлагает согласовывать модели друг с другом.

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

11. Принцип полиморфизма – предполагает, что элементы модели могут принимать различные внешние формы или функциональность (поведение), в зависимости от обстоятельств.

1.3 Классификация моделей информационной системы

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

Классифицировать модели информационных систем можно по следующим характерным признакам:

1. Характеристика моделей информационных систем по строгости их описания делится на:

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

- Формальные модели подходят для автоматизированной обработки и их значительно больше:

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

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

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

2. Характеристика моделей информационных систем с точки зрения физической реализации делится на:

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

- Физическая модель информационной системы, которая описывает элементы системы в соответствии с физической реализацией этих элементов.

3. Характеристика моделей информационных систем с точки зрения отображения динамики процессов делится на:

- Статическую модель, с помощью которой описывается состав и структура системы;

- Динамическую модель, с помощью которой описывается поведение системы и / или отдельных его элементов.

4. Характеристика моделей информационных систем по отображаемому аспекту делится на:

- Функциональные модели информационных систем – описывают функции системы, варианты использования, объекты и субъекты, взаимодействующие с системой;

- Информационные модели – описывают состав и структуру данных (реляционных баз данных, классы и т.д.);

- Поведенческая модель информационной системы – описывает состояние системы и / или ее отдельных элементов и переходы между ними, взаимодействие элементов алгоритмов обработки информации;

- Компонентная модель информационной системы – описывает состав и структуру программного обеспечения и аппаратных средств.

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

1.4 CASE-технологии анализа и проектирования

Значительно упростить и формализовать процессы формирования требований и проектирования системы позволяет современные CASE-средства.

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

Архитектура CASE-средства состоит из 6 компонентов:

1. Репозитория данных
2. Графического редактора диаграмм
3. Верификатора диаграмм
4. Документатора проекта
5. Администратора проекта
6. Сервиса

Рисунок 2. Архитектура CASE-средств

Основными функциями технических средств, используемых CASE-инструментов являются:

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

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

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

Основной целью использования CASE-технологий заключается в максимизации автоматизации этапов анализа и проектирования информационной системы для построения формальной модели системы.

Большинство современных CASE-инструментов поддерживает методологию структурного и / или объектно-ориентированного анализа и проектирования информационных систем.

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

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

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

• наследование,
• полиморфизм,
• инкапсуляция.

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

2. Инкапсуляция – ограничение доступа – скрытие отдельных элементов реализации не влияющих на его основные характеристики в целом.

Ограничения доступа используются для:

• Реализация – механизмы абстракции внутренней реализации.

• Интерфейс – основные характеристики состояния и поведения;

Ограничивая доступ, таким образом, программист может добиться:

• Простоты внедрения объектов.

• Легкости построения поэтапной системы, независимо от конкретной реализации используемой абстракции;

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

3. Иерархия – система ранжирования абстракции.

Иерархия предполагает использование иерархии в разработке программного обеспечения.

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

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

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

6. Стабильность – способность объекта существовать во времени и адресном пространстве программы, независимо от процесса его породившем.

Основными понятиями, с которыми оперирует объектно-ориентированный подход являются понятия:

• классы
• объекты

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

Объект характеризуется характеристиками конкретных значений из перечня всех возможных свойств данного объекта. Каждый объект, приняв сообщение, обязан определенным образом «среагировать» на них, выполнив определенные действия для сообщения.

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

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

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

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

Возможные операции над объектами (рис.3) [8]:

Рисунок 3. Типы операций над объектом

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

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

1. Один объект передает сообщение другому, в этом случае подразумевают, что они находятся в отношении использования (рис.4).

Рисунок 4. Типы отношений между объектами

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

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

Основные средства разработки классов (рисунок 6).

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

Рисунок 5. Соответствие объекта-абстракции классам объектам-переменным

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

Рисунок 6. Иерархия классов при различных видах наследования

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

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

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

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

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

Выводы по главе 1

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

1. Описание системы в виде объектов в большей степени соответствует содержательному смыслу предметной области.

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

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

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

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

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

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

ГЛАВА 2. ПРОГРАММНЫЕ ПРОДУКТЫ ДЛЯ АВТОМАТИЗАЦИИ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

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

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

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

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

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

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

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

Выделение существенных свойств системы (для конкретной предметной области), а также построение модели, отображающей эти свойства, возможно с использованием языка UML (Unified Modeling Language).

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

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

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

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

Основные понятия UML:

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

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

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

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

Модель – объект, отображающий наиболее значимые для конкретной задачи характеристики системы. Модели бывают разные – нематериальные и материальные, естественные и искусственные, математические и декоративные.

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

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

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

Набор диаграмм будет составлять модель системы и наиболее полно будет ее описывать.

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

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

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

• четыре типа диаграмм изображают статическую структуру приложения;

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

Широко применяются следующие виды диаграмм:

• активности;

• классов;

• прецедентов;

• последовательностей;

• объектов;

• состояний;

• взаимодействия;

• развертывания.

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

1. Rational Rose
2. Microsoft Visio
3. Sybase PowerDesigner
4. Case Complete
5. Artiso Visual Case
6. Magic Draw
7. Sparx Enterprise Architect

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

2.1 Rational Rose

Rational Rose (рисунок 7) – CASE-средство, разработанное компанией Rational Software Corporation (США). Rational Rose предназначено для автоматизации этапов анализа и проектирования информационных систем, а также выпуска проектной документации [2,3]. Основу Rational Rose составляет объектно-ориентированный анализ и язык UML.

Рисунок 7. Логотип Rational Rose

Основной вариант Rational Rose/C++ позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++ (рисунок 8).

Рисунок 8. Пример диаграмма прецедентов в среде Rational Rose

Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонентов в новых проектах.

В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов [4] (рисунок 9).

Рисунок 9. Пример диаграммы классов в среде Rational Rose

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

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

Принципиальное отличие Rational Rose от других средств заключается в объектно-ориентированном подходе. Графические модели, создаваемые с помощью этого средства, основаны на объектно-ориентированных принципах и языке UML (Unified Modeling Language). Инструменты моделирования Rational Rose позволяют разработчикам создавать целостную архитектуру процессов предприятия, сохраняя все взаимосвязи и управляющие воздействия между различными уровнями иерархии.

2.2 Microsoft Visio

Microsoft Visio — векторный графический редактор, редактор диаграмм и блок-схем для Windows. Выпускается в трёх редакциях: Standard, Professional и Pro for Office 365 (рисунок 10) [12].

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

Рисунок 10. Логотип Microsoft Visio

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

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

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

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

Рисунок 11. Типы UML диаграмм, поддерживаемых Microsoft Visio

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

На панели фигур доступно четыре типа соединителей сообщений: сообщение, ответное сообщение, сообщение самому себе и асинхронное сообщение.

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

Рисунок 12. Пример 1 диаграммы в Microsoft Visio

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

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

Рисунок 13. Пример 2 диаграммы в Microsoft Visio

2.3 Sybase PowerDesigner

Sybase PowerDesigner (рисунок 14) является комплексным инструментом для моделирования и разработки приложений и бизнес-процессов, предназначенным для применения в проектах различных масштабов, включая крупные корпоративные проекты. PowerDesigner позволяет осуществлять несколько стадий создания приложений, начиная от системного анализа и дизайна и заканчивая непосредственной генерацией кода приложения [11].

Рисунок 14. Логотип PowerDesigner

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

Рисунок 15. Пример разработки диаграмм в PowerDesigner

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

Особенностями последних версий PowerDesigner являются поддержка анализа и проектирования систем с использованием стандарта UML (диаграммы бизнес-процессов, последовательности выполнения, классов и компонентов). На основе диаграммы классов PowerDesigner автоматически осуществляет генерацию и реинжиниринг кода для Java, C++, PowerBuilder, Visual Basic, C#, Visual Basic .NET и ряда других языков программирования и средств разработки.

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

2.4 Сравнение CASE-средств

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

— Проектирование системы – даёт ли инструмент достаточно функциональности для документации требований, проектирования и видов UML диаграмм. Есть ли в нём функциональность для создания зависимости между объектами разных типов, возможность отслеживать изменения. Это обязательный критерий для инструмента.

— Экспорт – инструмент должен поддерживать удобный экспорт артефактов, произведённых в нём. Должны быть доступны разные форматы экспорта – хотя бы html и doc. Шаблоны документов должны легко модифицироваться. Это тоже обязательный критерий.

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

— Минимизация рутины. Было бы неплохо, чтобы инструмент делал некоторые вещи сам – например, генерировал тест-кейсы, объектный дизайн из БД, может, куски кода.

Таблица 1 Сравнение CASE-средств

Программный продукт/ Критерии	Проектирование системы	Экспорт	Удобство пользования	Минимизация рутины
Rational Rose	+	-	+	-
Microsoft Visio	+	+	+	-
Sybase PowerDesigner	+	+	-	+

+ - отлично справляется с данным критерием

- - не достаточно проработан критерий в программном продукте

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

Выводы по главе 2

1. Диаграммы разных видов позволяют взглянуть на систему с разных точек зрения.
2. UML содержит диаграммы трех типов – для моделирования статической структуры, поведенческих аспектов и подробностей реализации приложения.
3. Существует много программных продуктов, которые помогают реализовывать визуальное проектирование и поддерживают объектно-ориентированный подход, подробно рассмотрены следующие:

• Rational Rose
• Microsoft Visio
• Sybase PowerDesigner

1. Исходя из использования программных продуктов, сравнение не выявило абсолютного лидера. Но в силу использования Microsoft Visio в других разработках, автором отдается предпочтение именно этому программному продукту.

ЗАКЛЮЧЕНИЕ

В результате проделанной работы в целом и по главам получились следующие выводы:

1. Описание системы в виде объектов в большей степени соответствует содержательному смыслу предметной области.

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

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

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

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

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

• Rational Rose
• Microsoft Visio
• Sybase PowerDesigner

7. Исходя из использования программных продуктов, сравнение не выявило абсолютного лидера. Но в силу использования Microsoft Visio в других разработках, автором отдается предпочтение именно этому программному продукту.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств.
2. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М.: Бином, 2014. – 560 с.
3. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2013. - 432 с.
4. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 2016. – 176 с.
5. Википедия. [Электронный ресурс]. – Режим доступа: ru.wikipedia.org.
6. Йордан, Э. Объектно-ориентированный анализ и проектирование систем / Э. Йордан, С. Аргила. - М.: Издательство «ЛОРИ», 2017. - 264 с.
7. Крачтен, Ф. Введение в Rational Unified Process / Ф. Кратчен. - М.: Издательский дом «Вильямс», 2015. - 240 с.
8. Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. - М.: Издательский дом «Вильямс», 2011. - 496 с.
9. Леоненков, А.В. Визуальное моделирование в среде IBM Rational Rose 2003 / А.В. Леоненков. [Электронный ресурс]. – Режим доступа: www.intuit.ru.
10. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML / А.В. Леоненков. [Электронный ресурс]. – Режим доступа: www.intuit.ru.
11. Маклаков, С.В. Создание информационных систем с AllFusion Modeling Suite / С.В. Маклаков. – М. : ДИАЛОГ-МИФИ, 2016. – 432 с.
12. Петров, В.И. Информационные системы / В.Н. Петров. – СПб. : Питер, 2012. – 688 с.
13. Фаулер, М. UML. Основы. Третье издание. / М. Фаулер. – М.: Символ-Плюс, 2016. – 192 с.
14. Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2012. – 496 с.
15. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 20142. - 496 с.