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

Содержание:

Введение

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

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

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

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

Основным источником информации для этой работы является работа известных авторов Буч Г., Рамбо Д., Якобсо И., написавших достаточное количество книг и монографий и получивших мировое признание. Также в качестве источников были взяты работы и учебники высших технических заведений, написанные преподавателями и научными работниками и рекомендованные министерством образования.

1. Объектно-ориентированные концепции

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

• Абстрагирование;
• Инкапсуляция;
• Модульность;
• Иерархия.

Абстрагирование — это выделение наиболее важных, существенных характеристик некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы с точки зрения дальнейшего рассмотрения и анализа, и игнорирование менее важных или незначительных деталей. [3, с. 164]

Абстракция концентрирует внимание на внешнем представлении объекта, позволяет отделить основное в поведении объекта от его реализации. Абстракцию можно построить, если выделить основные обязанности объекта. Например, для датчика скорости главной обязанностью будет являться отображение скорости. Однако, какую именно скорость будет отображать датчик является деталями его реализации. Таким образом, абстракция отражает суть объекта, опуская его второстепенные детали. [6, с. 188]

Инкапсуляция — физическая локализация свойств и поведения в рамках единственной абстракции (рассматриваемой как «черный ящик»), скрывающая их реализацию за общедоступным интерфейсом. [3, с. 164]

Инкапсуляция является процессом разделения элементов абстракции на секции с различной видимостью. Инкапсуляция служит для отделения интерфейса абстракции от ее реализации. Например, для регулятора скорости главной его обязанностью будет являться возможность увеличения и уменьшения скорости некоторой машины через некоторый порт. Регулировать скорость необходимо по специальному алгоритму, который выполняется этим регулятором. Предотвращение прямого доступа к порту извне и есть инкапсуляция. [6, с. 189-190]

Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне сильно сцепленных, но слабо связанных между собой подсистем (модулей). [3, с. 165]

В больших системах, состоящих из множества компонентов с сотнями классов, модульность помогает управлять сложностью. Модули в данном случае служат физическими контейнерами, в которых объявляются классы и объекты логической разработки. Важно также отметить, что определение классов и объектов выполняется в ходе логической разработки, а определение модулей – в ходе физической разработки системы. [6, с. 190]

Иерархия — это ранжированная или упорядоченная система абстракций, расположение их по уровням. Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу). Примерами иерархии классов являются простое и множественное наследование (один класс использует структурную или функциональную часть соответственно одного или нескольких других классов), а иерархии объектов — агрегация. [3, с. 165]

Двумя важными инструментами иерархической организации в объектно-ориентированных системах являются [6, с. 191]:

• Структура классов;
• Структура объектов.

Иерархическая структура классов строится с помощью наследования. Наследование определяет отношение между классами, где класс разделяет структура или поведение, определенное в другом или нескольких других классах.

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

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

2.1 Общие положения

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

К основным понятиям объектно-ориентированного ориентированного подхода относятся [3, с. 166]:

• Объект;
• Класс;
• Атрибут;
• Операция;
• Полиморфизм;
• Компонент;
• Связи.

Объект определяется как осязаемая сущность (tangible entity) предмет или явление (процесс), имеющие четко определяемое поведение. Объект может представлять собой абстракцию некоторой сущности предметной области (объект реального мира) или программной системы (архитектурный объект). Любой объект обладает состоянием (state), поведением (behavior) и индивидуальностью (identity).

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

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

Каждый объект обладает уникальной индивидуальностью. Индивидуальность — это свойства объекта, отличающие его от всех других объектов [3, с. 166].

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

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

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

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

Полиморфизм — это способность скрывать множество различных реализаций под единственным общим интерфейсом.

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

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

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

Ассоциация (association) — это семантическая связь между классами. Ассоциация отражает структурные связи между объектами различных классов.

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

Зависимость (dependency) — связь между двумя элементами модели, при которой изменения в спецификации одного элемента могут повлечь за собой изменения в другом элементе.

Обобщение (generalization) — связь «тип-подтип» реализует механизм наследования (inheritance). Большинство объектно-ориентированных языков непосредственно поддерживают концепцию наследования. Она позволяет одному классу наследовать все атрибуты, операции и связи другого [3, с. 166-176].

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

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

Объектно-ориентированную технологию зачастую выбирают основной моделью разработки информационных систем по двум причинам [2, с. 199]:

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

Использование объектной модели позволяет создает обозримую и достаточно легко понимаемую схему объектно-ориентированного проекта, обладающую всеми преимуществами объектно-ориентированного метода. Основными преимуществами являются [2, с. 199]:

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

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

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

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

Особенностью объектно-ориентированных систем является то, что они состоят их абстракций разных уровней. С точки зрения программного обеспечения такой ИС это означает, что размер методов такой структуры является сравнительно небольшим, так как они составлены из методов, соответствующих более низким уровням абстракций. Многочисленность методов приводит к излишнему количеству вызовов, что приводит к значительному потреблению ресурсов и для некоторых систем вообще является неприемлемым. Такое ухудшение характеристик связано с вложенностью классов: класс, находящийся на самом конце линии наследования, может иметь множество суперклассов. Такое ощутимый удар по производительности информационной системы наносит динамическое создание и уничтожение объектов класса. [2, с. 200-201]

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

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

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

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

2.3 Методологии объектно-ориентированного подхода

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

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

• RUP (Rational Unified Process);
• RAD (Rapid Application Development);
• OpenUP.

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

В основе процесса проектирования RUP лежат 2 основных процесса [7, с. 115]:

• Поток работ;
• Жизненный цикл разрабатываемой системы.

Первый процесс представляет статический аспект проектирования, заключающийся в непосредственных рабочих процессах. Жизненный цикл системы отражает динамический аспект проектирования системы в виде итераций, циклов и стадий [7, с. 115].

Также сам процесс проектирования включает в себя два аспекта [7, с. 115]:

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

В качестве основных принципов RUP выступают [5]:

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

Жизненный цикл RUP (Рисунок 1), состоит из следующий процессов [7, с. 109]:

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

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

Рисунок 1

Методология RAD — одна из самых распространенных методологий разработки ПО в настоящее время, которая реализует спиральные модели жизненного цикла. Основными особенностями методологии являются [7, с. 102]:

• Короткий, но тщательно проработанный график работ;
• Небольшая команда инженеров;
• Цикличность разработки.

Модель ИС, созданная по технологии RAD, позволяет понимать текущий статус и прогресс и регулировать трудозатраты и вложения после каждой итерации.

Основными этапами RAD методологии являются [7, с. 103]:

• Бизнес моделирование. На этом этапе исследуются информационные потоки между бизнес-процессами.
• Моделирование данных. Информационные потоки отображаются набором объектов данных. Определяются характеристика этих объектов и связи между ними.
• Моделирование обработки. Определяются модели и процедуры преобразования объектов данных. Определение алгоритмов поиска, создания и удаления данных.
• Генерация приложений. С помощью объектно-ориентированных методов и систем программирования, а также CASE-средств создаются приложения ИС и продукты.
• Тестирование и объединение.

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

Одной из технологий, предоставляющих большую гибкость, чем RUP или RAD, является технология OpenUP. Как и RUP, OpenUP использует принципы итеративности и инкрементальности в рамках структурированного жизненного цикла. OpenUP предлагает [7, с. 113]:

• Концепцию микрошагов;
• Концепцию раннего тестирования;
• Методику гибкого моделирования;
• Упрощенный RUP процесс;
• Шаблоны различного вида.

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

3. Язык UML

3.1 Общие сведения об языке UML

Унифицированный язык моделирования UML (Unified Modelling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. [3, с. 177] В настоящее время для объектно-ориентированного моделирования проблемной области UML фактически является стандартом по объектно-ориентированным технологиям.

Словарь UML включает три вида строительных блоков:

• Сущности;
• Связи;
• Диаграммы.

Сущности (things) — это абстракции, которые являются основными элементами модели, связи (relationships) соединяют их между собой, а диаграммы (diagrams) группируют представляющие интерес наборы сущностей. [1, с. 32]

Основным инструментом представления модели UML являются диаграммы. Диаграмма UML — это нагруженный связный граф, вершины которого нагружаются элементами модели, а ребра – отношениями между элементами.

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

Теоретически диаграмма может включать в себя любую комбинацию сущностей и связей. На практике, однако, используется лишь небольшое число общих комбинаций, состоящих из пяти наиболее часто применяемых представлений архитектуры программных систем. По этой причине UML включает 13 видов диаграмм. [1, с. 40]. Однако, на практике чаще всего используют меньше. Наиболее широкое распространение получили:

• Диаграмма классов;
• Диаграмма компонентов;
• Диаграмма вариантов использования;
• Диаграмма взаимодействия;
• Диаграмма состояний;
• Диаграмма деятельности;
• Диаграмма размещения;
• Диаграмма пакетов.

Диаграмма классов (class diagram) показывает набор классов, интерфейсов и коопераций, а также их связи. Диаграммы этого вида чаще всего используются для моделирования объектно-ориентированных систем. Предназначены для статического представления системы. Диаграммы классов, включающие активные классы, представляют статическое представление процессов системы.
Пример диаграммы классов представлена на Рисунке 2. На диаграммах классов обычно представлены следующие элементы:

• Классы;
• Интерфейсы;
• Зависимости.

Для группировки классов, обладающих некоторой общностью, применяются пакеты. Пакет — общий механизм для организации элементов модели в группы. Пакет может включать другие элементы. Каждый элемент модели может входить только в один пакет. Пакет является средством организации модели в процессе разработки, повышения ее управляемости и читаемости, а также единицей управления конфигурацией. Если между любыми двумя классами, находящимися в разных пакетах, существует некоторая зависимость, то имеет место зависимость и между этими двумя пакетами. Таким образом, диаграмма пакетов (Рисунок 3) представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. [5]

Рисунок 2

Рисунок 3

Диаграммы вариантов использования — это один из видов диаграмм UML, предназначенных для моделирования динамических аспектов систем. Диаграммы вариантов использования — основной вид диаграмм при моделировании поведения системы, подсистемы или класса. Каждая из них показывает набор вариантов использования и действующих лиц в их взаимодействии. [1, с. 253]

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

Действующее лицо (actor) — это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. [5] Пример диаграммы использования представлен на Рисунке 4.

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

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

Информационное (informative) сообщение — сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния.

Сообщение-запрос (interrogative) — сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.

Императивное (imperative) сообщение — сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.

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

Рисунок 4

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

Пример диаграммы последовательности изображен на Рисунке 5, пример диаграммы коммуникации изображен на Рисунке 6.

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

Диаграммы деятельности — это один из видов диаграмм, применяемых в UML для моделирования динамических аспектов систем. По сути, диаграмма деятельности представляет собой блок-схему, которая показывает, как поток управления переходит от одной деятельности к другой. В отличие от традиционной блок-схемы диаграмма деятельности показывает параллелизм так же хорошо, как и ветвление потока управления. Диаграмма деятельности показывает поток управления – от одной деятельности к другой. Деятельность (activity) — это выполняющийся в данный момент неатомарный набор действий внутри машины состояний (автомата). Выполнение некоторой деятельности в конечном счете раскрывается в виде выполнения отдельных действий (actions), каждое из которых может изменить состояние системы или передавать сообщения. Действия заключаются в вызове другой операции, посылке сигнала, создании или уничтожении объекта либо в выполнении простых вычислений (например, вычислении выражения). Диаграмма деятельности представляет собой набор узлов и дуг. Пример диаграммы деятельности представлен на Рисунке 7. [1, с. 283-284]

Рисунок 6

Рисунок 5

Рисунок 7

Диаграммы размещения — это один из видов диаграмм, используемых при моделировании физических аспектов объектно-ориентированной системы. Такая диаграмма представляет конфигурацию узлов, где производится обработка информации, и показывает, какие артефакты размещены на каждом узле. Этот тип диаграмм хорошо подходит для того, чтобы показать размещение объектов и компонентов в распределенной системе. Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства — в большинстве случаев, часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мэйнфреймом. [1, с. 427-428] Пример диаграммы размещения представлен на Рисунке 8.

Рисунок 8

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

3.2 Использование UML в объектно-ориентированном подходе

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

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

Нотация UML поддерживает концепции требований, анализа и проектирования, разграничивая виды деятельности для каждого этапа проектирования. [4, с. 80]

На этапе моделирования требований разрабатывается модель типа «черный ящик», в которой определяются функциональные требования к системе в терминах действующих лиц и последовательности действий (транзакций). Например, в рассматриваемой системе действующими лицами будут являться оператор установки или модуль ПО, осуществляющий сетевой обмен. Для оператора установки можно выделить, например, следующие транзакции:

• Включение установки;
• Задание программы синтеза;
• Начало синтеза.

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

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

Построение статической модели предметной области — это структурное представление информационных аспектов системы. Задаются классы, их атрибуты и отношения между ними. Концептуальная статическая модель предметной области описывает в виде диаграммы классов основные физические классы, участвующие в моделировании предметной области. [4, с. 81] В рассматриваемой части системы это могут быть:

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

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

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

• Таблица алгоритма синтеза;
• Таблица аварийных значений;
• Таблица журнала процесса.

Выявленные ранее транзакции уточняются с целью показать взаимодействие между участвующими в них объектами. Для этого применяются диаграммы кооперации или последовательности. Диаграмма последовательности представляет собой взаимодействующие «линии жизни» для каждого объекта. Сигналы и сообщения будут перенесены при реализации модели в программном коде в раздел описания методов соответствующих классов. [4, с. 82] На Рисунке 9 представлен фрагмент диаграммы для рассматриваемой системы:

Рисунок 9

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

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

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

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

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

4. Обзор программных продуктов

В настоящее время существует большое количество универсальных инструментальных программных средств, реализующих как графическую поддержку языка UML, так и средства автоматизированного перевода проектов в программный код (CASE-средства проектирования). Различные фирмы предлагают свои средства поддержки UML, специализированные для конкретных языков программирования. Наиболее известными продуктами являются IBM Rational Rose, Sparx Systems Enterprise Architect, Microsoft Visio, и другие.

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

В данной работе кратко будут рассмотрены IBM Rational Rose и Sparx Systems Enterprise Architect.

4.1 Rational Rose

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

Rational Rose позволяет проектировать варианты использования и их диаграммы для визуализации возможностей системы. С помощью этого инструмента можно легко создавать диаграммы языка UML, описанные раннее в предыдущих главах. Доступны для проектирования: диаграммы Взаимодействия, диаграммы Классов, диаграммы Компонентов и диаграммы Размещения. [Боггс Rose, с. 22]

Также, а числе основных возможностей продукта:

• прямое и обратное проектирование на языках: ADA, Java, С, C++, Basic;
• поддержка технологий COM, DDL, XML;
• возможность генерации схем БД Oracle и SQL.

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

4.2 Sparx Systems Enterprise Architect

Sparx Systems Enterprise Architect — это программа для UML-моделирования и проектирования нового поколения. является неплохим средством для UML-моделирования, с возможностью многопользовательской работы и дружественным интерфейсом.

Возможности Enterprise Architect весьма многочисленны. Вот некоторые из них [8]:

• Поддержка полного цикла моделирования для бизнес и IT систем, системного проектирования, проектирования встроенных систем;
• Поддержка UML 2.5;
• Утилиты для управления проектом;
• Поддержка ActionScript, Ada, C/C++, C#, Java, Delphi, Verilog, PHP, VHDL, Python, System C, VB.Net, Visual Basic;
• Поддержка моделирования БД, генерация DDL с поддержкой различных систем управления базами данных;
• Поддержка паттернов проектирования;
• Генерация документации в форматах HTML;
• Многопользовательская работа, утилиты для менеджера проекта, тестирование, глоссарий, другие ресурсы;
• Автоматизация интерфейса, поддержка макросов.

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

Заключение

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

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

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

1. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. 2-е изд.: Пер. с англ. Мухин Н. – М.: ДМК Пресс, 2006. – 496 с.
2. Буч Г. Объектно-ориентированное проектирование с примерами применения. M.: Конкорд 1992. – 519 с.
3. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд. перераб. и доп. – М. Финансы и статистика, 2006. – 544 с.
4. Есилевский В. С., Нетеса П. С., Климова М. В. Применение методологии объектно-ориентированного проектирования с использованием языка UML. РИ. – 2006., №2. – с. 79-84
5. Култыгин О. П. Методы и средства проектирования информационных систем и технологий. Московский финансово-промышленный университет «Университет», 2016
6. Орлов С.А., Цилькер Б. Я. Технологии разработки программного обеспечения: Учебник для вузов. 4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с.
7. Чистов Д. В. Проектирование информационных систем: учебник и практикум для СПО. – М. Издательство Юрайт, 2019. – 258 с.
8. Sparx Systems Enterprise Architect official website. URL: https://sparxsystems.com/products/ea/index.html (Дата обращения: 21.12.2019)