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

Содержание:

Введение

Рост спроса на программные системы в наше время является следствием того, что по мере удешевления, повышения надежности и увеличения объема производства компьютеров автоматизация труда человека с помощью компьютера становится все более выгодной. Из года в год возрастает сложность и разнообразие систем, полу­чивших в международной научно-технической практике название систем, интенсивно использующих программное обеспечение (Software Intensive Systems, SIS). Для разработок SIS типичны крупномасштабные проекты: десятки или сотни разработчиков, месяцы или годы разработки, огромные денежные средства.

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

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

Целью проектирования информационных систем (ИС) является обеспечение эффективного функционирования систем, а также взаимодействия пользователей и разработчиков ИС. Именно качественное проектирование обеспечивает создание такой системы, которая способна функционировать при постоянном совершенствовании ее технических, программных, информационных составляющих и расширять спектр реализуемых управленческих функций [19., с.37].

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

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

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

Задачи курсовой работы:

- рассмотреть основные понятия и принципы построения объектных моделей;

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

- рассмотреть основы унифицированного языка моделирования UML и построения диаграмм UML;

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

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

1.1 Основные принципы построения объектной модели

Информационная система — взаимосвязанная совокупность средств, методов и персонала, используемых для сбора, хранения, обработки и выдачи информации в целях решения поставленных задач. Информационные системы необходимы в процессе приня­тия решений, они помогают анализировать проблемы и создавать новые продукты [10, с.15].

«Автоматизированная система — система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения уста­новленных функций» (ГОСТ 34.003-90) [11.].

Индустрия разработки автоматизированных информационных систем управления зародилась в 1950 -1960-х гг. и к концу века приобрела вполне законченные формы. На первом этапе основным подходом в проектировании систем был метод «снизу-вверх», когда система создавалась как набор приложений, наиболее важных в данный момент для поддержки деятельности предприятия. Следующий этап связан с тем, что системы начали проектироваться «сверху-вниз», т.е. в предположении, что одна программа должна удовлетворять потребности многих пользователей [23., с.17].

Проектирование информационной системы — это процесс создания и внедрения про­ектов комплексного решения задач предметной области по новой техно­логии. В проектирование включается детальная разработка отдельных проектных решений, их анализ, апробация и внедрение [24., с.24].

В основе проектирования информационной системы лежит моделирование некоторой предметной области. Чтобы получить адекватный предметной области проект в виде системы корректно работающих программ, необходимо иметь целостное, системное представление модели, отражающее все аспекты функционирования будущей ИС. При этом под моделью предметной области понимается некоторая система, которая имитирует структуру или функционирование исследуемой предметной области и отвечающая основному требованию — быть адекватной этой области. Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. [23, с.93].

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

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

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

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

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

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

Важным преимуществом объектного подхода является согласованность модели деятельности организации и модели проектируемой информационной системы от стадии формирования требований до стадии реализации. По объектным моделям может быть отслежено отображение реальных сущностей моделируемой предметной области в объекты и классы ИС [7., с.134].

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

Среди проблем, стимулировавших развитие ООП, можно выделить:

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

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

- облегчение проектирования ИС за счет сокращения семантического разрыва между структурой решаемой задачи и структурой программного обеспечения [8., с.163].

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

Объектный подход был создан почти 50 лет назад, значительный вклад был внесен ООП-языками программирования: Simulа (1967), Smalltаlk (1970-е гг.), C++ (1980-е гг.), с развитием языка моделирования UML (1990-е гг.). На объектный подход также оказали влияние развивавшиеся достаточно независимо методики моделирования данных, в особенности модель «сущность-связь» [24., с.96].

В центре ООП находятся понятие объекта и класса. Объект — это сущность, которой можно посылать сообщения, и которая может на них реагировать, используя свои данные. К основным понятиям объектно-ориентированного подхода (элементам объектной модели) относятся также следующие (таблица 1) [12., с.28].

Таблица 1 - Основные понятия в ООП

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

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

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

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

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

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

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

Кроме основных, имеется три дополнительных элемента:

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

- Параллелизм - свойство объектов находиться в активном, либо пассивном состоянии.

- Сохраняемость или устойчивость (persistence) - свойство объектов сохранять свое состояние и принадлежность к какому-то классу [23.19., с.185].

Для создания моделей анализа и проектирования объектно-ориентированных программных систем используют языки визуального моделирования, самым популярным из которых на сегодняшний день является язык UML. Спецификация разрабатываемого программного обеспечения при использовании UML объединяет несколько моделей: логиче­скую, использования, реализации, процессов, развертывания [9., с.133].

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

Достоинства объектно-ориентированного подхода (ООП) к проектированию ИС заключаются в следующем:

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

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

- объектная модель более естественна, так как ориентирована на человеческое восприятие мира, а не на ком­пьютерную реализацию;

- ОО-модель позволяет использовать в полной мере вырази­тельные возможности объектных и объектно-ориентированных языков программирования [23.22., с.112].

К недостаткам объектно-ориентирован­ного подхода можно отнести:

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

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

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

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

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

Решающую роль в создании универсального языка моделирования UML сыграли Гарди Буч, Айвар Джекобсон, Джеймс Рамбо и созданные ими методы моделирования различных сторон сложных систем [19., с.188].

UML (Unified Modeling Language — унифицированный язык моделирования) предназначен для визуа­лизации, специфицирования, конструирования и документирования программных систем. Первая вер­сия — UML 1.0 вышла в январе 1997 г. [16., с.201].

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

Результатом совместной работы ведущих компаний в области проектирования ИС стала спецификация UML 1.0, вышедшая в январе 1997 г. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики. Последующие релизы UML включали версии 1.3, 1.4 и 1.5 до 2003 года.

UML 1.4.2 был принят в качестве международного стандарта ISO/IEC 19501:2005. Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 г. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development — MDD. Последняя версия UML 2.4.1 опубликована в августе 2011 г. и принята в качестве международного стандарта ISO/IEC 19505-1, 19505-2 [2].

Основные свойства языка UML:

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

2) Специфицирование — построение точных, недвусмысленных и полных моделей.

3) Конструирование. UML не является языком визуального про­граммирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки програм­мирования (Java, С++, Visual Basic, даже на таблицы реля­ционной БД или устойчивые объекты объектно-ориен­тированной базы данных) [4., с.32].

4) Документирование. UML позволяет решить проблему доку­ментирования системной архитектуры и всех ее деталей, предла­гает язык для формулирования требований к системе и опреде­ления тестов, предоставляет средства для моделиро­вания работ на этапе планирования проекта и управления версиями. Сфера применения UML не ограничивается модели­рованием ПО, выразительность языка по­зволяет моделировать и другие бизнес-процессы, например, до­кументооборот, осуществлять проектирование аппаратных средств [16., с.202].

Язык UML имеет сложную иерархическую структуру, показанную на рис. 1 [19, с.189].

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

В UML имеется четыре типа сущностей (рис.1).

Язык UML

Сущности:

1. Структурные

2. Поведенческие

3. Группирующие

4. Аннотационные

Отношения:

1. Зависимостей

2. Ассоциаций

3. Обобщений

4. Реализаций

Диаграммы:

1. Классов

2. Объектов

3. Прецедентов

4. Последовательностей

5. Коопераций

6. Состояний

7. Действий

8. Компонентов

9. Развертывания

Структурные

сущности:

1. Классы

2. Интерфейсы

3. Кооперации

4.Прецеденты

5. Активные классы

6. Компоненты

7. Узлы

Поведенческие

сущности:

1. Взаимодействия

2. Автоматы

Группирующие

сущности:

1. Пакет

Аннотационные

сущности:

1. Примечания

Рис.1 Структура языка UML

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

Поведенческие сущности делятся на два вида диаграмм: диаграммы первого вида называются взаимодействиями, второго вида - автоматами. Группирующие сущности имеют только один вид пиктограмм (пакеты), аннотационные сущности имеют один вид пиктограмм - примечания. Диаграмма в UML - это графическое представление набора элементов в виде связанного графа с вершинами (сущностями) и ребрами (отношениями) [4., с.38].

Изображение основных сущностей языка UML представлено в таблице 2 [16., с.203].

Таблица 2 - Описание сущностей языка UML

Наименование	Описание	Обозначение на диаграммах
Класс (Class)	Совокупность объектов с общими атрибута­ми, операциями, отношениями и семанти­кой. Класс реализует один или несколько интерфейсов	Имя: Свойства Операции
Интерфейс (Interlace)	Совокупность операций, которые определя­ют сервис (набор услуг), предоставляемый классом или компонентом. Интерфейс опи­сывает видимое извне поведение элемента и редко существует сам по себе	I Имя
Кооперация (Collaboration)	Определяет взаимодействие и представляет собой совокупность ролей и других элемен­тов, которые, работая совместно, произво­дят кооперативный эффект
Прецедент (Use case)	Описание последовательности выполняемых системой действий, которая производит результат, значимый для какого-то определенного актера
Актер (Actor)	Набор согласованных ролей, которые могут играть пользователи при взаимодействии с ней. На UML-диаграммах пиктограммы прецедента и актера обычно располагаются рядом
Активный класс (Active class)	Класс, объекты которого вовлечены в один или несколько процессов, или нитей (Threads), и поэтому могут инициировать управляющее воздействие. Активный класс во всем подобен обычному классу, за ис­ключением того, что его объекты представ­ляют собой элементы, деятельность которых осуществляется одновременно с деятельно­стью других элементов	Имя Свойства Операции
Взаимодействие Interaction	Поведение, суть которого заключается в об­мене сообщениями между объ­ектами в рамках конкретного контекста для достижения определенной цели	Имя операции
Автомат конечный State machine	Алгоритм поведения, определяющий после­довательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в от­вет на различные события	Имя перехода Имя состояния

В языке UML определены четыре типа отношений, описанные в таблице 3. Перечисленные элементы являются основными типами от­ношений, которые можно включать в модели UML. Существуют также их вариации, например уточнение (Refinement), трасси­ровка (Trace), включение и расширение (для зависимостей) [9., с.191].

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

Таблица 3 - Отношения в языке UML [16, с.207]

Наименование	Описание	Обозначение на диаграммах
Зависимость (Dependency)	Семантическое отношение между двумя сущно­стями, при котором изменение не­зависимой может повлиять на семантику другой, зависимой
Ассоциация (Association)	Структурное отношение, описывающее совокуп­ность связей. Разновидностью ассоциации является агрегирование (Aggregation) — между целым и его час­тями. Мощность ассоциации определяет количе­ство объектов, соединяемых с объектами на другом конце: * — неограниченное количество; 1..* — один или более; 1..10 — заданный диапазон; 7 — точное количество	1 *
Обобщение (Generalization)	Отношение «специализация/обобщение», при ко­тором объект специализированного элемента (потомок) может быть подставлен вместо объек­та обобщенного элемента (родителя или предка)
Реализация (Realization)	Встречается в двух случаях: между интерфейсами и реализующими их классами или компонентами, между прецедента­ми и реализующими их кооперациями

В терминах UML определены следующие виды диаграмм [4., с.41]:

1) Диаграмма вариантов использования (использования, прецедентов) – use case diagram;

2) Диаграмма классов – class diagram;

3) Диаграммы поведения – behavior diagrams;

1. Диаграммы взаимодействия – interaction diagrams;

- Диаграмма последовательности – sequence diagram;

- Диаграмма сотрудничества (кооперации) – collaboration diagram;

2. Диаграмма состояний (переходов) – statcchart diagram;

3. Диаграмма деятельности (действий) – activity diagram;

4) Диаграммы реализации – implementation diagrams;

- Диаграмма компонентов – component diagram;

- Диаграмма развертывания (размещения, топологии) – deployment diagram.

Связь между диаграммами языка UML приведена на рисунке 2 [19, с.192].

Диаграммы компонент

Диаграммы последовательностей

Диаграммы использования

Диаграммы классов

Диаграммы переходов

Блоки использования

Диаграммы сотрудничества

Рис.2 Связь между диаграммами UML

Рассмотрим наиболее часто применяемые диаграммы для построения информационных систем.

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

Диаграмма вариантов использования или прецедентов в UML (usе casе diаgram) - это графическая модель (составная часть модели прецедентов, позволяющей описать систему на концептуальном уровне), отражающая отношения между актерами и прецедентами.

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

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

Действующее лицо (аctor) — это роль, которую пользователь играет по отношению к системе. Действующие лица делятся на: пользователей системы, другие системы, время, если от него зависит запуск событий [16, с.221].

Для вариантов использования и действующих лиц в UML поддерживается несколько типов связей:

1) связь коммуникаций (аssociation rеlationship) – это связь между вариантами использования и актером (действующим лицом);

2) включение (include rеlаtionship) – применяется в случаях, когда имеется фрагмент поведения системы, которая повторяется более чем в одном варианте использования;

3) связь с расширением (еxtend rеlationship) – применяется при наличии изменений в нормальном поведении системы, вносится также в отдельный вариант использования (рис. 3) [8., с.185];

Рис. 3. Примера связей

4) связь-обобщение (gеneralization relationship) служит для указания того, что некоторый вариант использования А может быть обобщен до варианта использования В (рис. 4) [19, с.194].

Рис. 4. Пример связи-обобщения

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

2.3 Диаграмма классов (use case diagram)

Диаграмма классов (class diagram) — структурная статическая диаграмма, описывающая структуру системы, демонстрирует классы системы, их атрибуты и зависимости между классами. Диаграммы классов, которые включают активные классы, соответствуют статическо­му виду системы с точки зрения процессов [16, с.209].

Статический вид диаграммы классов рассматривает логические взаимосвязи классов между собой; аналитический вид диаграммы рассматривает общий вид и взаимосвязи классов данной системы [13.].

Графическое представление класса: прямоугольник, который может быть разделен на 3 части.

В диаграмме классов могут участвовать связи разных категорий:

1) зависимость (dependency) - связь, когда изменение в спецификации одного класса может повлиять на поведение другого, использующего первый класс. Зависимости (всегда однонаправленные) изображается в виде стрелки, проведенной пунктирной линией;

2) обобщение (generalization) - связь между родителем, специализированной разновидностью этой сущности - подклассом или потомком, изображается в виде стрелки от подкласса к суперклассу.

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

Агрегация (более тесная форма ассоциации) изображается в виде линии с ромбиком у целого класса;

4) реализация (realization) - семантическое отношение между классификаторами, при котором один классификатор определяет обязательство, а другой гарантирует его выполнение [8, с.191].

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

Пример диаграммы связи с классами, атрибутами классов, различными видами связей между классами, показан на рис. 5 [19, с.196].

Рис. 5. Элементы диаграммы классов в UML

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

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

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

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

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

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

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

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

На диаграмме объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии, называемой линией жизни (lifeline) объекта, - фрагмент жизненного цикла объекта в ходе взаимодействия в системе (рис.6) [15.].

Рис. 6. Элементы диаграммы последовательности

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

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

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

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

3.1 IBM Rational Rose

В настоящее время система Rational Rose является безусловным лидером в области объектно-ориентированного анализа и проекти­рования ИС с компонентной архитектурой.

Rational Software — компания-разработчик ПО, существовавшая до 2003 года в качестве независимой компании, но затем ее поглотила корпорация IBM. Большинство продуктов компании предназначены для моделирования, а также для разработки и поддержки программного обеспечения [1.].

Разрабатываемая этой фирмой методология, основанная на исполь­зовании унифицированного языка UМL, поддержана целым спектром инструментальных средств визуального моделирования, совместной разработки приложений (поддерживаются е языки программирования C++, Java, Visuаl Bаsic, SmallTаlk и др., а также популярные среды разработки — MS Visuаl Studiо, Delphi, PowerBuilder), средства автоматизированного тести­рования и документирования, охватывающих жизненный цикл со­здания программного обеспечения.

В компании была разработана методология разработки программного обеспечения Ratiоnal Unifiеd Prоcess(RUP), где даются рекомендации по всем этапам разработки: от моделирования бизнес-процессов до тестирования и сдачи в эксплуатацию готовой программы [17., с.158].

Работа продукта Rational Rose основана на универсальном языке моделирования UML, благода­ря которому Rational Rose способен решать практически любые задачи в проектировании ИС: от анализа бизнес-процессов до генерации кодов на определен­ном языке программирования.

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

Rational Rose функционирует на различных платформах: IBM РС (в среде Windows), Sun SPARС stаtions (UNIX, Sоlaris, SunOS), Hеwlett-Packard (HP UX), IBM RS/6000 (AIX).

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

В составе Rational Rose можно выделить 6 основных структурных компонент:

1) репозиторий - объектно-ориентированная база данных,

2) графический интерфейс пользователя,

3) средства просмотра проекта (browser) - обеспечивают "навигацию" по проекту, в том числе, перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д.,

4) средства контроля проекта - дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания,

5) средства сбора статистики,

6) генератор документов - формирует тексты выходных документов на основе содержащейся в рeпозитории информации [19, с.289].

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

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

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

Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов [22., с.144].

Интерфейс программы Rational Rose и пример построения диаграммы классов показан в приложении 1.

Компания Rational Software признана технологическим лидером за вклад в разработку UML благодаря усилиям трех основных разработчиков этого языка - Гради Буча (Grade Booch), Ивара Якобсона (Ivar Jacobson) и Джима Рамбо (Jim Rumbaugh).

Rational Rose является лидирующим инструментом визуального моделирования, поскольку он имеет все необходимые возможности: поддержку языка UML, многоязыковую поддержку итерационной разработки, полную поддержку командной разработки, компонентно-базированную разработку с поддержкой ведущих архитектур, легкость применения, оптимизированную интеграцию и многое другое [1.].

3.2 Sparx Systems Enterprise Architect 

Программное средство Еnterprise Architect (ЕА) от фирмы Sparx Systems – достаточно мощное программное обеспечение, предназначенное для работы с UМL. Это приложение разработано для модернизации систем, создания и управления бизнес-проектами, построения действующих моделей бизнес планов и проч. В настоящее время ЕА поддерживает огромное количество языков программирования, таких как ActionScript, Java, C, C++, C# and VB .NET, Python, PHP, Visual Basic 6, XSD и WSDL. Использовать функционал программы можно в самых разных сферах – бухгалтерской, web-разработке, медицине, электротехнике, исследовательских и научных работах. Программу можно использовать не только как средство анализа и моделирования бизнес-процессов с помощью UML-диаграмм, но и для обучения, что подтверждается популярностью ЕА во многих иностранных колледжах.

В Еnterprise Architect хорошо продумано взаимодействие диаграмм с программным кодом, имеется встроенная автоматическая генерация кода, с гибкой настройкой параметров, а также имеется набор инструментов для более детального редактирования кода прямо в окне приложения [22., с.158].

К особенностям программного средства можно отнести следующее:

1) поддержка языка UML построена в целом на базе RUР, при создании нового проекта автоматически создается дерево моделей и представлений по RUР. Можно создавать модели прецедентов, логические, поведенческие модели (диаграммы состояний и последовательностей), модели данных, компонентов и диаграммы развертывания. В этом плане Еnterprise Architect не заменим для аналитиков, архитекторов, разработчиков.

2) Возможности генерации кодов и создания скриптoв моделей могут пригодиться командам, которые используют методологию МDD (mоdel drivеn devеlopment), по сути EA нацелен именно на подобные команды.

3) В последних версиях Еnterprise Architect появились возможности по управлению требованиями и изменениями (issuе, defеct), которые можно привязывать непосредственно к элементам модели. Аналитики могут вести требования непосредственно в моделях EA.

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

5) В EA есть возможность отслеживать изменения моделей, выполняемые участниками.

К недостаткам моделирования с помощью ЕА можно отнести отсутствие автоматической возможности переключаться между логическим и физическим уровнем данных, отлично реализованном, к примеру, в ERWin. Настройка физических аспектов элементов базы данных не такая гибкая, как в более специализированных инструментах [18.].

Интерфейс программы Еnterprise Architect и пример построения диаграммы вариантов использования показан в приложении 2.

3.3 Соmponent Modeler семейства продуктов AllFusion

Соmponent Modeler — базовый ком­понент комплекта AllFusiоn Mоdeling Suitе компании Computеr Associatеs. Комплект также включает в себя: Process Modeler (ранее ВPwin), который объединяет моделирование бизнес-процессов, по­токов данных и рабочей деятельности в одном простом в использо­вании инструменте; ЕRwin Data Modeler (ранее ЕRwin), применя­емый для моделирования баз данных, и Dаta Mоdel Validаtor (ранее ЕRwin Еxaminer) для улучшения согласованности и качества моделей данных. Сomponent Modeler и ERwin Data Modeler работают совместно, что дает возможность разработчикам и аналитикам баз данных приводить информацию в реляционных базах данных к виду, пригодному для использования объектно-ориентированными при­ложениями [17., с.161].

AllFusion Component Modeler - программное средство комплекта AllFusiоn Mоdeling Suitе, поддерживающем UML. Кроме поддержки UML программный продукт осуществляет:

- поддержку Microsoft .NET;

- интеграцию с продуктом компании Chipware RTM Workshop (менеджмент требований);

- Model Xfer, инструмент для обмена элементами модели;

- поддержку многопользовательского доступа.

Для целей хранения элементов моделей используется MSDE - одна из версий MS SQL Server. В состав продукта включен Xpеrt Enginе - функция, позволяющая в реальном времени проверять строимые модели на соответствие канонам UML.

В AllFusion Component Modeler встроен специальный редактор профилей (Prоfile editоr), который позволяет настроить определенное количество профилей (набор стереотипов, именованных значений и ограничений) языка UМL.

Тесная связь AllFusion Component Modeler с AllFusion ERwin Data Modeler позволяет трансформировать UML-модели в модели данных. Эта интеграция является двунаправленной [5.].

Интерфейс программного средства AllFusion Component Modeler показан в приложении 3.

К достоинствам данного программного средства относится:

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

- прямое и обратное проектирование: поддер­живается синхронизация проектирования и реализации приложения при любом количестве изменений исходного кода и итераций про­ектирования;

- гибкость переноса информации: сочетание XML (как источника данных) и шаблонов XSL обеспечивает гибкость перенесения информации как в Component Modeler, так и из него;

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

- Сomponent Мodeler обеспечивает всплыва­ющие окна с подсказками сигнатуры UML для каждого изменения или создания объекта [17, с.162].

К недостаткам использования Сomponent Мodeler можно отнести то, что он не поддерживает автоматическую генерацию кодов для скриптовых языков.

3.4 Microsoft Visual Modeler

Мicrosoft Visual Мodeler (МSVM) — это ин­струмент визуального моделирования, разработанный Rаtional Sоftware совместно с Micrоsoft Cоrporation, который обеспечивает базируемое на UML моделирование для проектирования приложений на основе компонентов. Модели, созданные с использованием MSVM, могут автоматически выполнять генерацию объектного кода для проектов, реализуемых в средах разработки Visual Basic 6.0 и Visual C++.

МSVM — наиболее простой в освоении инстру­мент из семейства Rational Rose, мирового лидера среди инструмен­тов визуального моделирования.

Мicrosoft Visual Мodeler поддерживает архитектуру Windows-рас­пределенных интернет-приложений (Windоws DNА), которая дает возможность разработчикам уровня предприятий строить многоуровневые масштабируемые бизнес-приложения для любой распределенной сети.

Windows DNА, Visual Studiо и Microsoft Visual Mоdeler обеспечивают необходимую правильную комбинацию инфраструктуры и инстру­ментов проектирования для создания нового поколения n-уровневых, создаваемых на основе компонентов приложений. МSVM упрощает построение многоуровневых сложных бизнес- приложений, основанных на Windows DNА, позволяя разработчикам в графическом виде наглядно представлять организацию их прило­жений [21.].

Новые возможности Microsoft Visual Мodeler включают интегра­цию с Мicrosoft Visuаl SourceSаfe - системой контроля версий; интег­рацию с Microsoft Visual Manager (VCM) и улучшенную поддержку Microsoft Repository для разработок на основе Visual Basic. Расшире­ния Visual Modeler для поддержки групповой разработки включают возможность опубликования моделей в репозитории через VCM; в дальнейшем возможен просмотр моделей и их совместное исполь­зование членами группы разработчиков. Компоненты могут быть импортированы из репозитория через VCM посредством техники drag-and-drop. Точно так же интерфейсные компоненты COM могут быть импортированы из Windows Explorer.

Visual Modeler поддерживает Унифицированный Язык Моделирования (UML), раз­работанный таким образом, что даже разработчики, не имеющие опыта в визуальном моделировании, легко его осваивают и успешно создают модели [17, с.162].

Недостатками данной системы является ограниченность возможностей проектирования только для приложений Windows, для генерации кода языков Visual Basic и Visual C++, отсутствие кроссплатформенной поддержки.

Интерфейс программного средства Microsoft Visual Мodeler показан в приложении 4.

Помимо рассмотренных выше программных средств UML-моделирования, к числу популярных средств визуального моделирования, поддерживающих стандарты UML и объектно-ориентированный подход, можно отнести Paradigm Plus (программный про­дукт фирмы PLATINUM Technology), Oracle Designer (Oracle), SELECT (SELECT Software), Together Control Center (Borland), TAU G2 от Telelogic бесплатно распространяемые программы Dia, StarUml.

Заключение

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

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

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

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

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

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

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

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

- существенно повышает уровень унификации разработки и пригодность для повторного использования;

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

- объектная модель естественна, поскольку ориентирована на человеческое восприятие мира.

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

На данный момент на рынке ПО присутствует огромное количество и полноценных средств UML-моделирования, и программ для рисования диаграмм, в том числе и UML. Наиболее популярными являются средства: Rational Rose, Enterprise Architect, AllFusion Component Modeler, Microsoft Visual Мodeler, Paradigm Plus, Oracle Designer, Together Control Center.

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

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

1. Rational Software [Электронный ресурс]. – Режим доступа: https://ru.wikipedia.org/wiki/Rational_Software
2. UML [Электронный ресурс]. – Режим доступа: https://ru.wikipedia.org/wiki/UML
3. Абдикеев Н. М. Управление знаниями корпорации и реинжиниринг бизнеса: Учебник / Н.М. Абдикеев, А.Д. Киселев; Под науч. ред. Н.М. Абдикеева - М.: ИНФРА-М, 2013 - 382с.
4. Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. 2-е изд. / Пер. с англ.; Под общей редакцией проф. С. Орлова — СПб.: Питер, 2006. — 736 с.
5. Введение в UML с помощью AllFusion Component Modeler [Электронный ресурс]. – Режим доступа: http://www.interface.ru/home.asp?artId=42
6. Вдовенко Л. А. Информационная система предприятия: Учеб. пособие / Л.А. Вдовенко. - М.: Вузовский учебник: ИНФРА-М, 2010. - 237 с.
7. Вдовин, В. М. Теория систем и системный анализ [Электронный ресурс] : Учебник для бакалавров / В. М. Вдовин, Л. Е. Суркова, В. А. Валентинов. - 3-е изд. - М.: Издательско-торговая корпорация «Дашков и К°», 2013. - 644 с.
8. Вендрoв А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2008. — 544 с.
9. Гагарина Л. Г. Технология разработки программного обеспечения: Учеб. пос. / Л.Г.Гагарина, Е.В.Кокорева, Б.Д.Виснадул; Под ред. проф. Л.Г.Гагариной - М.: ИД ФОРУМ: НИЦ Инфра-М, 2013. - 400 с.
10. Гвоздева В. А. Основы построения автоматизированных информационных систем: Учебник / В.А. Гвоздева, И.Ю. Лаврентьева. - М.: ИД ФОРУМ: НИЦ Инфра-М, 2013. - 320 с.
11. ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения (утв. Постановлением Госстандарта СССР от 27.12.1990 N 3399)
12. Грэхем, И. Объектно-ориентированные методы. Принципы и практика / Иан Грэхем. — 3-е изд. — М.: «Вильямс», 2009. — 880 с.
13. Диаграмма классов [Электронный ресурс]. – Режим доступа: https://ru.wikipedia.org/wiki/Диаграмма_классов
14. Диаграмма прецедентов [Электронный ресурс]. – Режим доступа: https://ru.wikipedia.org/wiki/Диаграмма_прецедентов
15. Диаграммы взаимодействия: крупным планом [Электронный ресурс]. – Режим доступа: http://www.intuit.ru/ studies/courses/1007/229/lecture/5960
16. Емельянова Н. З. Проектирование информационных систем: Учебное пособие / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. - М.: Форум: НИЦ ИНФРА-М, 2014. - 432 с.: ил.; 60x90 1/16. - (Профессиональное образование). (переплет) ISBN 978-5-91134-274-6, 500 экз.
17. Заботина Н. Н. Проектирование информационных систем: Учебное пособие / Н.Н. Заботина. - М.: НИЦ ИНФРА-М, 2014. - 331 с.
18. Инструменты проектирования: Enterprise Architect [Электронный ресурс]. – Режим доступа: http://devprom.ru/news/Инструменты-проектирования-Enterprise-Architect
19. Мартынов В.В., Никулина Н.О., Филосова Е.И. Проектирование информационных систем. Учебное пособие по курсу «Проектирование информационных систем» /Уфимск. гос. авиац. техн. ун-т; В.В. Мартынов, Н.О. Никулина, Е.И. Филосова – Уфа: УГАТУ, 2008. – 381 с.
20. Назаров С. В. Архитектура и проектирование программных систем: Монография / С.В. Назаров. - М.: НИЦ Инфра-М, 2013. - 351 с.
21. Обзор CASE-средств для построения диаграмм UML [Электронный ресурс]. – Режим доступа: http://www.intuit.ru/studies/courses/1007/229/lecture/5963?page=3
22. Пирогов, В. Ю. Информационные системы и базы данных: организация и проектирование: учеб. пособие / В. Ю. Пирогов. — СПб.: БХВ-Петербург, 2009. — 528 с.
23. Проектирование информационных систем : курс лекций : учеб пособие для студентов вузов, обучающихся по специальностям в области информ. технологий / В. И. Грекул, Г. Н. Денишенко, Н. Л. Коровкина. — М.: Интернет-Ун-т Информ технологий, 2007. — 304 с.
24. Ясенев, В.Н. Информационные системы и технологии в экономике: учеб. пособие для студентов вузов, обучающихся по специальностям экономики и управления (080100) / В.Н. Ясенев. — 3-е изд., перераб. и доп. - М.: ЮНИТИ-ДАНА, 2012.- 560 с.