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

Содержание:

Введение

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

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

Объект исследования: создаваемая информационная система.

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

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

Глава 1. Проектирование информационной системы.

Важнейший ресурс современности – информация, обработка которой осуществляется с помощью информационных систем. Согласно статьи 2 Федерального закона от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации», информационная система - совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств. Разнообразие задач по обработке информации порождает разнообразие информационных систем. Они отличаются принципами построения, организацией функционирования, объемом решаемых задач.

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

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

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

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

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

Задачи, решение которых помогает осуществить методология:

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

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

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

Основные принципы, к которым относятся принципы внедрения и функционирования информационных систем удобно представить в виде таблицы (таблица 1.1).

Таблица 1.1 Принципы проектирования информационных систем

Наименование принципа	Пояснение
Идентичность	Разработка новой, совершенствование существующей или внедрение полученной (приобретённой) извне ИС являются идентичными научно-техническими проблемами, отличающимися друг от друга содержанием ряда этапов и временными параметрами.
Технологичность	Автоматизированная технология означает создание (разработку) новой технологии или модернизацию существующей (автоматизированной). При этом не должно быть простого использования автоматизированной в условиях старых традиционных технологий.
Непрерывность, поэтапность, преемственность разработки и развития	ИС постоянно развивающиеся системы. Каждое нововведение должно служить развитию основных системных принципов и улучшению достигнутых параметров.
Адаптивность	Компоненты ИС должны обладать свойствами, обеспечивающими быстрое их приспособление к изменениям внешней среды, новым средствам и т.п.
Модульный принцип построения программных и технических средств	предполагает, что указанные средства состоят из блоков (“модулей”), обеспечивающих возможность их замены или изменения с целью совершенствования ИС или её адаптации к новым условиям.
Технологическая интеграция	предполагает для всей системы применение единой технологии создания, обновления, сохранения и использования ИР. Например, однократную обработку информационных документов и их многократное, многоцелевое их использование.
Полная нормализация процессов и их мониторинг	Многоцелевое использование информации ИС требует обеспечения высокой достоверности данных в системе. Для этого на различных этапах обработки и ввода информации необходимо использовать разные формы её контроля, требования к которому можно сформировать исходя из состава решаемых задач и обрабатываемых данных. Постоянный мониторинг необходим для получения качественных и количественных характеристик функционирования ИС на основе применения встроенных или используемых в виде отдельного модуля средств статистики.
Регламентация	ИС ориентированы на функционирование в промышленном режиме, обеспечивающем массовую поточную обработку информационных документов. Эта обработка регламентируется стандартами, маршрутными и пооперационными технологиями, нормативами на ресурсные и временные показатели, развитой службой диспетчеризации.
Экономическая целесообразность	Создание ИС должно предусматривать использование проектных решений, обеспечивающих минимизацию финансовых, материальных затрат и трудовых ресурсов, а также способствующих совершенствованию обслуживания пользователей.
Типизация или максимальное использование готовых решений и средств	необходимо для сокращения стоимости, сроков разработки и внедрения ИС, а также уменьшения ошибок проектирования как системы в целом, так и отдельных её составляющих.
Стандартизация проектных решений	предполагает, что разработку, развитие ИС и их сетей следует осуществлять с ориентацией на сотрудничество и кооперацию, а также в соответствии с правилами и протоколами национальных и международных стандартов.
Принцип корпоративности	При проектировании автоматизированной системы следует предусмотреть её аппаратную, программную, лингвистическую и информационную совместимость с другими ИС. Как правило, разные организации входят в состав различных систем и сетей (республики, края, области, города, района, ведомства и т.п.), участником которых они являются или могут стать. Требования корпоративности могут входить в противоречие с требованиями или решениями, диктуемыми другими принципами, например – преемственности проектных решений.
Ориентация на первых лиц объекта автоматизации	Успешное выполнение работ по созданию ИС, её развитию и эксплуатации возможно при условии их безусловной поддержки первым лицом (директор организации) и закреплении непосредственной ответственности за их выполнение приказом по организации за руководителем на уровне не менее заместителя директора. В подразделениях организации ответственность за выполнение работ должна возлагаться на руководителей этих подразделений.

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

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

Функционально-модульный подход (структурный) к проектированию ИС основан на применении декомпозиции информационной системы на алгоритмы (функции).

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

Глава 2. Объектно-ориентированный подход к проектированию ИС.

Подходы к проектированию ИС отличаются методами декомпозиции и структурной организации элементов системы. Рассмотрим основные отличия объектно-ориентированного подхода.

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

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

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

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

к проектированию ИС.

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

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

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

- архитектуры компьютеров;

- объектно-ориентированных операционных систем;

- объектно-ориентированных языков программирования;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Особенности подхода

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

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

Диаграмма (Diagram) — это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 3. Реализация подхода.

UML — язык для спецификации, визуализации, конструирования и документирования сложных информационно-насыщенных объектных систем. В настоящее время зарегистрирован как международный стандарт ISO/IEC 19501:2005 «Information technology - Open Distributed Processing - Unified Modeling Language (UML)».

Инструментальные средства, поддерживающие методологию UML, — Rational Rose (Rational Software), Paradigm Plus (CA/Platinum), ARIS (IDS Sheer AG), Together Designer (Borland) и др.

Rational Rose.

Система Rational Rose позволяет строить восемь типов диаграмм UML: диаграммы прецедентов, диаграммы классов, диаграммы последовательностей, диаграммы кооперации, диаграммы состояний, диаграммы действий, компонентные диаграммы, диаграммы развертывания. Основным типом диаграмм, своеобразным ядром моделирования в UML являются диаграммы классов. Кроме UML, предусмотрено использование и других методов (Booch, OMT).

Rational Rose - среда моделирования, которая поддерживает генерацию кода из моделей, написанных на языке Ada, ANSI C++, C++, CORBA, Java/J2EE, Visual C++ и Visual Basic.

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

Рисунок 3.1 Интерфейс Rational Rose

Rational Rose обеспечивает следующие возможности моделирования бизнес процессов:

• Поддержка объектного моделирования. Применение принципов объектного моделирования и языка UML позволяет приблизить модели процессов к требованиям бизнеса и упрощает вид моделей.
• Структурное представление элементов. Модели процессов и их элементы могут быть представлены в виде графической структуры, наглядно отображающий их состав и взаимосвязи.
• Интеграция моделей. За счет применения единого языка UML, Rational Rose позволяет объединить модели бизнес процесса, модели приложений и модели данных.
• Интеграция с программными продуктами. Для расширения возможностей моделирования и анализа бизнес процессов в Rational Rose реализована возможность интеграции с другими программными продуктами, например, Microsoft Visual Studio.
• Открытая архитектура. Она позволяет дополнять существующий инструментарий программы новыми функциями и возможностями.
• Обратное проектирование. Эта возможность позволяет на основе имеющегося программного кода построить понятийную модель. Для целей моделирования бизнес процессов данная возможность может быть полезна, если моделируемый процесс автоматизирован.

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

Преимуществами Rational Rose являются:

• Поддержка командной работы. В этом CASE средстве реализована простая поддержка всех участников проекта. Пользователи могут работать со своими собственными уникальными моделями и в своем собственном окружении без смены рабочего места, при этом сохраняется взаимосвязь с общими моделями.
• Управление моделями. Все создаваемые модели могут быть легко изменены. Изменения в одной модели автоматически отражаются во взаимосвязанных моделях. Для управления моделями применяется система контроля версий и управления конфигурацией. Это позволяет легко проводить изменения в любых моделях бизнес процессов.
• Контроль ошибок. Rational Rose обеспечивает отслеживание ошибок, возникающих при моделировании. Это позволяет исправить ошибки с учетом их наследования и передачи на очередной уровень моделирования.
• Документирование моделей. Пользователи могут создавать необходимые им отчеты и документы по моделям процессов. Документы формируются под потребности пользователя и могут настраиваться для применения к разным моделям.
• Управление конфигурацией. Пользователи могут настраивать конфигурацию интерфейса и части приложений под свои потребности. В Rational Rose применяется графический пользовательский интерфейс (GUI), за счет которого можно настроить необходимое окружение для комфортной работы. [14]

AllFusion Component Modeler (ранее Paradigm Plus)

Программный продукт компании Computer Associates AllFusion Component Modeler (ранее Paradigm Plus) CASE-средство для проектирования, визуализации и поддержки качественных информационных систем. Обеспечивая расширенную поддержку совместного проектирования и многократного использования компонентов модели, Component Modeler существенно увеличивает производительность команды разработчиков. Component Modeler упрощает создание стратегически важных, многозвенных приложений масштаба предприятия, способных адаптироваться к меняющимся потребностям бизнеса. Система Paradigm Plus ориентирована на методологию OOCL (Object Oriented Change and Learning) и компонентную технологию проектирования и разработки. Она поддерживает диаграммы различных методов (UML, CLIPP, TeamFusion, OMT, Booch, OOCL, Martin/Odell, Shlaer/Mellor, Coad/Yourdon).

Достоинствах данного продукта:

• полноценная поддержка UML версии 1.3
• механизм Model Xpert Engine интерактивно проверяющий строимую модель на предмет соответствия всем каноном языка UML
• прямое и обратное генерирование кода.

Пример пользовательского интерфейса показан на рисунке 3.2

Рисунок 3.2 Интерфейс Paradigm Plus

ARIS.

Система ARIS обеспечивает четыре различных «взгляда» на моделирование и анализ: Процессы, Функции (с Целями), Данные, Организация. Для каждого «взгляда» поддерживаются три уровня анализа (требования, спецификации, внедрение). Каждый из уровней анализа состоит из своего комплекта моделей различных типов, в том числе диаграмм UML, диаграмм SAP/R3 и др. Каждый объект моделей ARIS имеет множество атрибутов, которые позволяют контролировать процесс разработки моделей, определять условия для выполнения функционально-стоимостного анализа, имитационного моделирования, взаимодействия с workflow-системами и т. д. 

В соответствии с методологией ARIS каждый процесс может быть рассмотрен в пяти аспектах:

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

Информационный аспект - отображает состав данных и информации, задействованной в процессе;

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

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

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

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

В рамках каждого из аспектов модель процесса может детализироваться по уровням. Уровни зависят от «близости» модели к формальным языкам программирования и создания информационных систем.

ARIS разделяет модели на три уровня детализации:

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

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

Уровень описания реализации. Этот уровень является самым близким к информационным системам. Модели этого уровня содержат описание аппаратных и программных компонентов.

Указанные выше аспекты и уровни моделирования в методологии ARIS представляют в виде следующей схемы.

Рисунок 3.3 Аспекты и уровни моделирования в методологии ARIS

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

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

Девятая версия бизнес платформы ARIS включает в себя следующие компоненты:

• ARIS Architect & Designer. Этот компонент предназначен для статического моделирования процессов. Для моделирования применяются различные методы и нотации. Компонент включает в себя более 150 видов диаграмм, которые обеспечивают анализ и моделирование процессов во всех аспектах методологии ARIS.
• ARIS Business Strategy. Компонент является расширением для ARIS Architect & Designer. Он обеспечивает разработку и управление бизнес стратегией организации. За счет этого компонента можно смоделировать и провести анализ ценности процессов организации.
• ARIS Connect. Это средство, позволяющее вести коллективную работу над моделями. В данном компоненте реализована возможность удаленной работы с применением мобильных устройств. Работа строится по принципу социальной сети.
• ARIS Enterprise Architecture. Этот компонент также является расширением для ARIS Architect & Designer. Он позволяет проводить анализ и гармонизировать документацию предприятия с ИТ архитектурой.
• ARIS for ArchiMate. Является расширением для ARIS Design Server. Этот компонент позволяет создавать модели ИТ архитектуры с использованием стандартов ArchiMate и TOGAF.
• ARIS for DMS. Является расширением для ARIS Architect & Designer. Позволяет получить доступ и обмениваться данными между хранилищем (репозиторием) ARIS и системами управления документацией.
• ARIS for SAP Solutions. Данный компонент является расширением ARIS Architect & Designer и позволяет синхронизировать модели бизнес процессов со средой SAP R3.
• ARIS IT Inventory. Расширение для ARIS Architect & Designer, которое позволяет проводить инвентаризацию приложений, технологий и проектов.
• ARIS MashZone. Этот компонент позволяет создавать интерактивные контрольные панели для работы с различными видами данных.
• ARIS Process Governance. Расширение для ARIS Architect & Designer. С помощью него можно установить политики, роли и ответственность за управление бизнес процессами и включить эти политики в модели.
• ARIS Process Performance Manager. Этот компонент используется для мониторинга и анализа показателей процессов, таких как производительность, стоимость, качество.
• ARIS Publisher. Расширение для ARIS Architect & Designer. Оно позволяет обеспечить простой доступ сотрудникам к информации о процессах и ИТ архитектуре.
• ARIS Risk & Compliance Manager. Этот компонент применяется для управления рисками и включения системы управления рисками в модель процессов.
• ARIS Simulation. Применяется для динамического моделирования процессов. С помощью этого компонента можно осуществлять реинжиниринг, оптимизацию и анализ бизнес процессов, а также проводить ресурсное планирование. Компонент является расширением для ARIS Architect & Designer.
• ARIS UML Designer. С помощью этого компонента модели ARIS могут быть представлены в виде стандарта UML , что обеспечивает совместимость бизнес моделей и ИТ моделей.
• ARIS Viewer. Компонент, который позволяет просматривать всю информацию ARIS репозитория в ARIS Publisher, получать доступ к информации в ARIS IT Inventory и управлять задачами ARIS Process Governance через web -интерфейс.

Подробную информацию по составу компонент ARIS и их возможностях можно посмотреть на сайте компании разработчика SOFTWARE AG.

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

Среди множества преимуществ этой платформы можно выделить существенные для целей моделирования бизнес процессов:

• Хорошо развитый графический интерфейс. Пользователи могут создавать модели, используя систему графических символов. Есть возможность использовать web – интерфейс. Полноэкранный режим и система навигации позволяет представлять данные в удобном виде. Интерфейс можно конфигурировать под потребности пользователей.
• Поддержка мощного хранилища данных (репозитория). Хранилище данных ARIS содержит большое число элементов и описаний. При этом обеспечивается совместная работа пользователей с объектами хранилища данных.
• Интеграция с другими программными продуктами. ARIS позволяет импортировать модели процессов в программные продукты, поддерживающие стандартные интерфейсы, например, такие как X ML, XMI, WSDL, XSD, XPDL, CADM (DoDAF), BPEL, BPML Export , Visio, txt и Excel.
• Детализация моделей. В ARIS есть возможность детализировать модели и их компоненты, используя различные аспекты.
• Динамическое моделирование. За счет дополнительных средств можно осуществить дискретное выполнение действий процесса. ARIS предоставляет графические средства для контроля и анализа действий в моделях процессов.
• Генерация отчетов. Существует возможность пользоваться установленным набором отчетов, а также настраивать отчеты под потребности пользователей. Отчеты могут формироваться в общедоступных форматах, таких как MS WORD/EXCEL, Adobe PDF, HTML. В отчетах могут быть представлены и графические модели. Они представляются в доступных форматах, таких как WMF, GIF, JPG, и BMP.
• Поддержка многопользовательской работы. ARIS позволяет работать над моделями бизнес процессов разному количеству пользователей - от одного, до нескольких сотен человек. Пользователи могут находиться в разных географических регионах. [10]

Пример пользовательского интерфейса показан на рисунке 3.4

Рисунок 3.4 Интерфейс ARIS

Together Designer.

Система Together Designer Community Edition — средство создания диаграмм UML 2.0. Позволяет строить диаграммы прецедентов (диаграммы сценариев взаимодействия пользователя с продуктом с точки зрения пользователя); диаграммы последовательностей, описывающие порядок передачи сообщений от одних объектов к другим; диаграммы кооперации, описывающие взаимодействие объектов друг с другом, диаграммы деятельности, описывающие потоки работ и изменение состояний объектов, диаграммы развертывания. При необходимости может создаваться логическая модель данных, содержащая диаграммы «сущность-связь», на ее основе генерируется физическая модель данных для конкретной СУБД, выбранной для реализации проекта.

Пример пользовательского интерфейса показан на рисунке 3.5

Рисунок 3.5 Интерфейс Together Designer

Заключение

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

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

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

Список литературы

1. Буч Г., Рамбо Д., Джекобсон А. Язык UML: Руководство пользователя: Пер. с англ. – М.: ДМК, 2000. – 432 с.
2. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем: Учебник.-М.: Финансы и статистика, 2002.-512 с.
3. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М.: Бином, 2001. – 560 с.
4. Терра-Лексикон: Иллюстрированный энциклопедический словарь. – М.: ТЕРРА, 1998. - 672 с.
5. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2002. - 496 с.
6. Гранд, М. Шаблоны проектирования в Java / М. Гранд. - М.: Новое знание, 2004. - 559 с.
7. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000. – 352 с.
8. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. Серия «Реинжиниринг бизнеса». – М.: СИНТЕГ, 2000, 212 с.
9. Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. - М.: Весть-Метатехнология, 2001
10. Кватрани Т. Rational Rose 2000  и UML. Визуальное моделирование: Пер. с англ. – М.: ДМК Пресс, 2001. – 176 с.
11. Ларман К. Применение UML и шаблонов проектирования. Введение в объектно – ориентированный анализ и проектирование :Пер. с англ. – М.: Издательский дом «Вильямс», 2001. -496 с.
12. Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001 – 304 с.
13. С.Д.Паронджанов, Компания Аргуссофт  Методология создания корпоративных ИС. - http://www.neic.nsk.su/rus/tech/cit/kbd96/43.htm (Дата обращения 11.01.2018).
14.  Вики IBM Academic Initiative on Campus in Russia and CIS - https://www.ibm.com/developerworks/community/wikis/home/wiki/Wbcd69e09400c_4f72_9665_66f116225986?lang=ru (Дата обращения 11.01.2018).