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

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

Содержание:

Введение

Объектно-ориентированная технология развивается в различных

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

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

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

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

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

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

Модель OOП имеет следующие плюсы:

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

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

Таблица 1

Структурированный подход

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

Он работает с подходом «сверху вниз».

Он работает с подходом «снизу вверх».

Программа делится на количество подмодулей или функций.

Программа организована с использованием количества классов и объектов.

Используется вызов функции.

Используется передача сообщений.

Повторное использование программного обеспечения невозможно.

Возможно повторное использование.

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

Программирование объектно-ориентированного проектирования выполняется одновременно с другими этапами.

Структурированный дизайн более подходит для офшоринга.

Он подходит для внутреннего развития.

Он показывает ясный переход от проектирования к реализации.

Не столь явный переход от проектирования к реализации.

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

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

Данные диаграммы DFD & ER.

Диаграмма классов, диаграмма последовательности, диаграмма диаграммы состояния и все варианты использования.

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

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

1.1. Элементы объектно-ориентированной системы

Рассмотрим характеристики системы OOП:

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

1.2.Особенности объектно-ориентированной системы

Объектно-ориентированная система поставляется с несколькими важными функциями.

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

Абстракция - это процесс принятия или выбора необходимого метода и атрибутов для указания объекта. Он фокусируется на существенных характеристиках объекта относительно перспективы пользователя.

Отношения - все классы в системе связаны друг с другом. Объекты не существуют изолированно, они существуют в отношениях с другими объектами.

Существует три типа объектных отношений:

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

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

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

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

1.3. Недостатки и преимущества

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

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

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

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

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

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

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

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

1.3.2. Недостаток технологии объектов

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

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

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

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

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

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

2. Разработка объектно-ориентированной системы

2.1. Жизненный цикл разработки объектно-ориентированной системы

Он состоит из трех макропроцессов:

  • Объектно-ориентированный анализ;
  • Объектно-ориентированный дизайн;
  • Объектно-ориентированная реализация;
  • Объектно-ориентированный жизненный цикл;

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

  • Объектно-ориентированный анализ;
  • Объектно-ориентированное проектирование;
  • макетирования;
  • Реализация;
  • Инкрементное тестирование;
  • Объектно-ориентированный анализ.

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

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

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

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

Он также может дать пользователям возможность прокомментировать полезность и полезность дизайна. Он может дополнительно определить прецедентов и упростить процесс использования.

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

Реализация – он использует либо компонентную разработку, либо Rapid Application Development (RAD).

Жизненный цикл программного обеспечения обычно делится на этапы, идущие от абстрактных описаний проблемы к проектам, а затем для кода и тестирования и, наконец, для развертывания. Самые ранние этапы этого процесса - анализ и проектирование. Фаза анализа также часто называется «приобретением требований».

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

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

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

2.2. Виды разработки объектно-ориентированных систем

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

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

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

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

3. Унифицированный язык моделирования (UML)

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

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

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

Некоторые из известных ранних объектно-ориентированных методологий были вдохновлены такими гуру, как Грэди Буч, Джеймс Румбо, Ивар Якобсон , Роберт Мартин , Питер Коуд , Салли Шлаер, Стивен Меллор и Ребекка Вирфс-Брок.

В 1994 году Three Amigos of Rational Software начали совместную работу по разработке унифицированного языка моделирования (UML). Позже, вместе с Филиппом Крухтеном и Уокер Ройсом (старший сын Уинстона Ройса ), они провели успешную миссию по объединению своих методологий, методов OMT , OOSE и Booch с различными знаниями и опытом других лидеров отрасли в Rational Unified Process (RUP), всеобъемлющее итеративное и инкрементное руководство по процессам и рамки для изучения лучших практик в области разработки программного обеспечения и управления проектами. С тех пор UML стала, вероятно, самой популярной методологией и эталонной моделью для объектно-ориентированного анализа и проектирования.

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

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

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

UML состоит из:

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

На объектах выполняются следующие операции:

  • Конструктор / Деструктор - Создание новых экземпляров класса и удаление существующих экземпляров класса. Например, добавление нового сотрудника.
  • Запрос - доступ к состоянию без изменения значения не имеет побочных эффектов. Например, поиск адреса конкретного сотрудника.
  • Обновление - изменяет значение одного или нескольких атрибутов и влияет на состояние объекта. Например, изменение адреса сотрудника.

UML используется для следующих целей:

  • Моделирование бизнес-процесса;
  • Описание архитектуры системы;
  • Отображение структуры приложения;
  • Захват системного поведения;
  • Моделирование структуры данных;
  • Построение подробных спецификаций системы;
  • Эскиз идей;
  • Создание кода программы;
  • Статические модели.

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

Они используются для определения имен классов, атрибутов, методов, подписи и пакетов.

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

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

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

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

3.1. Проектирование UML

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

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

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

UML не является одним из методов разработки, но он был разработан для совместимости с ведущими объектно-ориентированными методами разработки программного обеспечения своего времени, например OMT, Booch method, Objectory и особенно RUP, изначально предназначенных для использовать, когда работа началась в Rational Software.

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

UML-диаграммы представляют два разных вида системной модели:

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

Модели UML можно обменять между инструментами UML с помощью формата XML Metadata Interchange (XMI).

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

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

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

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

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

3.2. Инструмент проектирования UML PowerDesigner

SAP PowerDesigner - это инструмент моделирования корпоративного взаимодействия, созданный Sybase, в настоящее время принадлежащий SAP. PowerDesigner работает под Microsoft Windows как приложение и работает под Eclipse через плагин. 

PowerDesigner поддерживает моделирование архитектуры, основанной на модели. PowerDesigner хранит модели с использованием различных расширений файлов, таких как .bpm , .cdm и .pdm. Внутренняя файловая структура может быть либо XML, либо сжатым двоичным файлом. PowerDesigner также может хранить модели в репозитории базы данных.

PowerDesigner включает поддержку:

  • Моделирование бизнес-процессов;
  • Генерация кода (Java , C # , VB .NET, Hibernate, EJB3, NHibernate, JSF, WinForm (.NET и .NET CF), PowerBuilder , ...);
  • Моделирование данных (работает с большинством основных систем СУБД);
  • Моделирование хранилищ данных ( WarehouseArchitect );
  • Плагин Eclipse;
  • Моделирование объектов (диаграммы UML 2.0);
  • Генерация отчетов;
  • Поддерживает Simul8 для добавления функций моделирования в модуль BPM для улучшения бизнес-процессов.

Репозиторий относится к хранилищу моделей (предприятие, информация, данные).

3.3. Инструмент проектирования UML Rational Software Modeler

Rational Software Modeler, сделанная IBM Rational Software разделения, является инструментом UML 2.0 на основе визуального моделирования и проектирования.

Rational Software Modeler основан на программной среде с открытым исходным кодом Eclipse и используется для визуального моделирования и разработки на основе моделей с UML для создания приложений и веб-сервисов.

IBM прекратила маркетинг Rational Software Modeler в 2010 году и завершила его поддержку в 2015 году. Значительная часть такой же функциональности теперь доступна через Rational Software Architect.

Возможности основного выпуска Rational Software Modeler включают в себя:

  • Поддержка UML версии 2.1;
  • Поддержка преобразований модели к модели;
  • Управление моделью для параллельной разработки и рефакторинга архитектуры, например, разделение, объединение, сравнение и моделирование моделей и фрагментов модели;
  • Поддержка применения шаблонов проектирования;
  • Он интегрирован с другими инструментами IBM Rational Software, такими как управление конфигурацией ClearCase и обработка исключений ClearQuest (отчеты об ошибках и запросы на изменение).

RSM спроектирован как плагин, который находится поверх платформы разработки Eclipse с открытым исходным кодом. RSM можно установить либо поверх существующей установки Eclipse v3.2, либо как новый экземпляр Eclipse v3.2.

Поскольку RSM основан на Eclipse, он может использовать сторонние плагины Eclipse, а также плагины специально для инструментов Rational.

3.4. Инструмент проектирования UML Microsoft Visio 

Продукт был впервые представлен в 1992 году, выпущен компанией Shapeware Corporation. Он был приобретен Microsoft в 2000 году.

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

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

22 сентября 2015 года был выпущен Visio 2016 вместе с Microsoft Office 2016. Было добавлено несколько новых функций, таких как одноступенчатая связь с данными Excel, защита прав на информацию (IRM) для файлов Visio, модернизированные формы для офисного макета, подробные формы для планов сайта, обновленные формы для планов этажей, современные формы для дома планы, IEEE-совместимые формы для электрических диаграмм, новый набор стартовых диаграмм и новые темы для интерфейса Visio. 

Моделирование базы данных в Visio вращается вокруг диаграммы модели базы данных (DMD). 

Заключение

Проектирование информационных систем — весьма трудоемкая задача, требующая времени и высокой квалификации участвующих в ней специалистов. За время существования программной инженерии появилось несколько подходов к проектированию ИС, каждый из которых обладает своими преимуществами и недостатками. 
В соответствии с различными представлениями об организации методики проектирования ИС принято делить на объектные и функциональные (структурные).
Объектно-ориентированные технологии развивались в различных областях вычислительной техники как средство решения проблем, связанных со сложностью создаваемых систем. В основе объектно-ориентированного проектирования лежит представление о том, что программную систему необходимо проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определенного класса, классы образуют иерархию. 
Существует множество технологий и инструментальных средств, с помощью которых можно реализовать оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. Наибольшую популярность в создании проектов ИС, основанных на объектно-ориентированном подходе, получило моделирование с помощью UML.
Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных средств, организационно-экономических, технических систем и других систем различной природы.
С помощью UML можно разработать модель создаваемой системы, которая отображает не только ее концептуальные элементы, такие как функции системы, бизнесc-процессы, конкретные детали системы: классы языков программирования, схемы, БД, повторно используемые компоненты ПО.
UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов, среди которых популярны диаграммы вариантов использования, диаграммы классов, диаграммы компонентов, диаграммы размещения и проч.

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

  1. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. М., "МетаТехнология", 1993.
  2. Inside OLE 2-(2e) by Kraig Brockschmidt (Reviewed May 1995)
  3. «Открытые системы», 1998 № 01
  4. CASE-технологии. Современные методы и средства проектирования информационных систем М.: Финансы и статистика, 1998. - 176 с.
  5. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM Vol. 13, No. 6, June 1970, pp. 377-387. Copyright ” 1970, Association for Computing Machinery, Inc.
  6. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. - М.:ДМК, 2000. -432с.
  7. Липаев В.В., Филинов Е.Н. Мобильность программ и данных в открытых информационных системах. - М.: Научная книга, -1997. -368с.
  8. Боггс У.,Боггс М. UML и Rational Rose,Пер. с англ. -М.: Издательство "ЛОРИ", 2000. -580с.
  9. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. -М. Финансы и статистика, 2000. -352с