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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

1.1 Понятие объектно-ориентированного подхода

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

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

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

1.2 Основные элементы объектной модели

Центральным и основным понятием объектной модели являются объекты.

Под объектом понимают осязаемую реальность – предмет, или явление реального мира, у которого можно четко выделить его свойства и поведение. Объект может находится в определенном состоянии, характеризоваться определенными свойствами. На основе структуры и поведения схожих объектов определяют класс. Термины «экземпляр класса» и «объект» в данном случае являются синонимами.

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

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

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

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

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

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

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

1.3 Достоинства и недостатки объектно-ориентированного подхода к проектированию

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

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

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

Не смотря на большое количество достоинств, объкетно-ориентированный подход не лишен и ряда недостатков, среди которых стоит выделить:

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

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

Глава 2. Методология объектного проектирования на языке UML

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

Для создания объектной модели какой-либо информационной системы чаще всего используется язык UML (Unified Modeling Language).

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

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

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

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

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

2.2 Диаграмма вариантов использования (use case diagram)

Построение объектно-ориентированной модели на языке UML чаще всего начинают с составления диаграммы прецедентов (или вариантов использования).

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

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

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

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

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

2.3 Диаграммы деятельности (activity diagram)

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

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

Рисунок 2. Пример диаграммы деятельности

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

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

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

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

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

Помимо имени и типа каждый атрибут характеризуется видимостью (visibility). Эта характеристика показывает, виден ли (т.е. доступен ли) атрибут для других классов. В UML имеется 3 типа видимости атрибутов классов:

• Открытый (public) – атрибут виден для любого другого класса (объекта);
• Защищенный (protected) – атрибут виден для потомков данного класса;
• Закрытый (private) – атрибут не виден внешними классами (объектами) и может использоваться только объектом, его содержащим.

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

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

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

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

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

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

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

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

Пример диаграммы классов приведен на рисунке 3.

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

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

Диаграмму состояний часто рассматривают в контексте конечного автомата. Тогда можем сказать, что диаграмма состояний (Statechart diagram) показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию.

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

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

Для поиска состояний класса можно просматривать атрибуты этого класса. Хорошим индикатором состояний является такой атрибут класса как «статус».

Диаграмма состояний изображается в виде графа с вершинами и ребрами.

Пример диаграммы класса приведен на рисунке 4.

Рисунок 4. Пример диаграммы состояний

2.6 Диаграммы взаимодействия (interaction diagrams)

Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов.

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

Существуют два вида диаграмм взаимодействия:

– диаграммы последовательности (sequence diagrams);

– кооперативные диаграммы (collaboration diagrams).

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

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

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

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

Пример диаграммы деятельности приведен на рисунке 5.

Рисунок 5. Пример диаграммы взаимодействия

2.7 Диаграмма пакетов (package diagram)

Пакет (package) — общецелевой механизм для организации различных элементов модели в группы.

Подпакет (subpackage) — пакет, который является составной частью другого пакета.

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

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

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

В дальнейшем можно вкладывать пакеты друг в друга.

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

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

Глава 3. Средства реализации объектно-ориентированного моделирования информационных систем

3.1 IBM Rational Rose

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

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

Базовым продуктом является IBM Rational Rose Enterprise Edition, который обладает наиболее полным набором возможностей.

Среди особенности Rational Rose стоит отдельно выделить:

• хорошая интеграция с Microsft visual Studio, которая заключается в возможностях прямой генерации программного кода на основе диаграмм (и нaоборот);
• возможность непосредственной работы с исполняемыми модулями и библиотеками (представленных в форматах EXE, DLL, TLB, OCX);
• поддержка технологии доступа к данным ADO (одной из самых популярных среди разработчиков для операционной системы Windows), а также элементов технологии DCOM;
• полная поддержка языка программирования Java: двусторонняя генерация как программного кода на основе диаграмм, так и диаграмм на основе кодов из файлов формата *.jar.

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

Рисунок 7. Общий вид рабочего интерфейса CASE-средства IBM Rational Rose

3.2 Sparx Systems Enterprise Architect

Программный продукт Enterprise Architect имеет версии для двух операционных систем: Windows и Linux и предназначен для создания объектных моделей в стандарте UML, с возможностью многопользовательской работы над одним проектом. Кроме того, программа имеет множество полезных функций: генерация документов, отчетов в формате HTML и программного кода на различных языках программирования, как C++, Java, PHP, Visual Basic, VB.Net, Delphi или C#.

Кроме того, среди возможностей Enterprise Architect стоит выделить:

• моделирование баз данных, включающее генерацию DDL-скриптов для создания базы данных и обратное моделирование на основе готовой базы данных через драйвер ODBC;
• загружаемые UML-профили (например, SPEM), позволяющие создавать узкоспециализированные модели;
• поддержка паттернов проектирования;
• генерация документации в форматах HTML и RTF;
• хорошая поддержка многопользовательской работы: разделение прав доступа, создание глоссария и т.д.;
• возможность автоматизировать рутинные функции путем создания и внедрения макросов.

Enterprise Architect распространяют в трех версиях, которые различаются функционалом и, соответственно, ценой:

• EA Desktop Edition;
• EA Professional Edition;
• EA Corporate Edition.

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

Вторая версия – это полнофункциональная среда для создания объектных моделей, которая, в отличие от первой, нацелена не на индивидуальное, а на групповое использование. Поддерживает совместный доступ, генерацию кода и DDL-скриптов, извлечение схем баз данных из СУБД Oracle, Microsft SQL Server и Microsoft Access.

Третья версия предназначена для больших компаний, в ней помимо основного функционала добавлена авторизация пользователей, разделение пользоватлей по группам с указанием уровня доступа, а также возможность соединения с MySQL, SQL Server, PostgreSQL, Sybase Adaptive Server Anywhere и Oracle9i.

Скриншот интерфейса Enterprise Architect приведен на рисунке 2.

Рисунок 2. Скриншот интерфейса Enterprise Architect

3.3 StarUml

StarUML - удобный UML-редактор с открытым исходным кодом.

StarUML дает возможность редактировать и создавать "с нуля" UML-проекты, совместимые со спецификациями MDA (Model-Driven Architecture). Она поддерживает генерацию кода в языки Java, PHP, С++ и C#, работает с фреймворками, умеет использовать паттерны и полностью соответствует стандарту UML 2.0. Каждый элемент в рабочей модели редактируется в отдельном инспекторе. Также пользователям предлагаются клавиши быстрого создания связей.

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

У редактора есть версии для всех современных операционных систем. Его интерфейс адаптирован по экраны высокого разрешения и выполнен в приятных темных тонах. StarUML позволяет импортировать проекты, созданные в Rational Rose, содержит инструмент публикации в HTML, предлагает разработчикам открытые API и поддержку ERD. Документацию для созданных проектов можно экспортировать в DOC, TXT, PPT, XLS и, с недавних пор, в PDF.

Скриншот интерфейса StarUML приведен на рисунке 3.

Рисунок 3 – Скриншот интерфейса StarUML

3.4 Microsoft Visio

Программный продукт для построения UML-диаграмм от компании Mictosoft. Следует сразу отметить, что эта программа из пакета Microsoft Office предназначена исключительно для рисоваия диаграмма. Хотя Visio и имеет некоторые дополнительные возможности, предназначен он исключительно для рисования диаграмм.

Тем не менее, в части изображения диаграмм у Visio нет равных (по крайней мере, среди рассмотренных программ).

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

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

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

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

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

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

Внешне Visio похожа на другие программы семейства Microsoft Office.

Скриншот интерфейса Visio приведен на рисунке 4.

Рисунок 4 – Скриншот интерфейса Microsft Visio

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

1. ГОСТ 2.105 – 95. Общие требования к текстовым документам.
2. ГОСТ 7.32 – 2001. Отчет по научно-исследовательской работе. Структура и правила оформления.
3. ГОСТ 7.82-2001. Библиографическое описание электронных ресурсов.
4. ГОСТ Р 6.30-97. Унифицированная система организационно-распорядительной документации требования к оформлению документов.
5. ГОСТ Р 7.0.5-2008. Библиографическая запись. Библиографическое описание.
6. Автоматизированные информационные технологии в экономике: Учебник/Под ред. проф. Г.А. Титоренко. – М.: Компьютер, ЮИНИТИ, 2006. – 329 c.
7. Буч, Г. Язык UML для пользователя: Пер. с англ. [Текст]/ Г. Буч, Д. Рамбо, А. Джекобсон. – М.: ДМК, 2014. − 432 с., ил. (Серия "для программистов").
8. Боггс, У. UML и Rational Rose: Пер. с англ. [Текст] / У. Боггс, М. Боггс. – М.: Издательство "Лори", 2011. - 581 с.
9. Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. – СПб.: Питер, 2002.- 432 с., ил.
10. Каюмова А.В. Визуальное моделирование систем в StarUML: Учебное пособие/ А.В. Каюмова. Казань. – Казанский федеральный университет, 2013. – 104с
11. Ларман, К. применение UML и шаблонов проектирования: Пер. с англ. [Текст]/ К. Ларман – М.: Издательский дом "Вильямс", 2011. – 496 с., ил.

ПРИЛОЖЕНИЕ