Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 IBMRationalRose

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

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

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

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

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

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

C:\Users\Mixa\YandexDisk\Скриншоты\2017-02-17_16-07-55.png

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

3.2 SparxSystemsEnterpriseArchitect

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

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

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

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

  • EA Desktop Edition;
  • EA Professional Edition;
  • EA CorporateEdition.

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

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

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

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

http://www.intuit.ru/EDI/21_12_14_1/1419110295-31391/tutorial/356/objects/7/files/07_05sm.gif

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

3.3 StarUml

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

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

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

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

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

C:\Users\Mixa\YandexDisk\Скриншоты\2017-02-17_16-45-16.png

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

3.4 MicrosoftVisio

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

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

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

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

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

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

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

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

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

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

C:\Users\Mixa\YandexDisk\Скриншоты\2017-02-17_16-20-34.png

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

ЗАКЛЮЧЕНИЕ

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

Были исследованы основные элементы, которые составляют объектно-ориентированную модель, а также особенности их выделения и взаимодействия друг с другом. Для реализации объектно-ориентированного подхода был разработан специальный язык – 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. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2015. – 352 с.
  11. Каюмова А.В. Визуальное моделирование систем в StarUML: Учебное пособие/ А.В. Каюмова. Казань. – Казанский федеральный университет, 2013. – 104с.
  12. Кендалл Скотт, UML. Основные концепции. – М.: Вильямс, 2013. – 323 с.
  13. Кратчен Ф. Введение в RationalUnifiedProcess. 2-е изд.: Пер. с англ. – М.: Вильямс, 2012. – 244 с.
  14. Ларман, К. применение UML и шаблонов проектирования: Пер. с англ. / К. Ларман – М.: Издательский дом "Вильямс", 2011. – 496 с., ил.