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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

Понятие «объект» впервые было использовано в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula (1967), Smalltalk (1970-е гг.), C++ (1980-е гг.) и языком моделирования UML (1990-е гг.). Также повлияли на него методы моделирования данных (особенно модель «сущность-связь», также известная как ER-модель), которые развивались самостоятельным путём.

Основная концепция, на которой строится ООП – это объектная модель, которая основывается на таких принципах:

• абстрагирование (abstraction);

• инкапсуляция (encapsulation);

• модульность (modularity);

• иерархия (hierarchy).

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

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

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

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

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

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

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

К основным понятиям объектно-ориентированного подхода (элементам объектной модели) относятся:

• объект;

• класс;

• атрибут;

• операция;

• полиморфизм (интерфейс);

• компонент;

• связи.

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

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

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

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

Структура и поведение схожих объектов определяют общий для них класс. Термины «экземпляр класса» и «объект» являются эквивалентными.

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

Любой объект является экземпляром (instance) класса. Определение классов и объектов — одна из самых сложных задач объектно-ориентированного проектирования.

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

Атрибут — это элемент информации, связанный с классом. Например, у класса Company (Компания) могут быть атрибуты Name (Название), Address (Адрес) и NumberOfEmployees (Число служащих).

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

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

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

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

Операции реализуют связанное с классом поведение (иначе говоря, реализуют обязанности класса — responsibilities). В широком смысле обязанности класса делятся на две категории.

Знание (определяется атрибутами класса):

• наличие информации о данных или вычисляемых величинах;

• наличие информации о связанных объектах.

Действие (определяется операциями класса):

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

• инициация действий других объектов;

• координация действий других объектов.

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

Суть полиморфизма понимается как способность класса принадлежать более чем одному типу.

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

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

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

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

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

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

• компонентом исходного кода;

• компонентом времени выполнения (run time);

• исполняемым компонентом.

Компонент обеспечивает физическую реализацию набора интерфейсов.

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

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

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

Существуют четыре возможных семантики для агрегации:

1) агрегация типа «Безраздельно обладает»;

2) агрегация типа «Обладает»;

3) агрегация типа «Включает»;

4) агрегация типа «Участник».

Мощность (multiplicity) показывает, как много объектов участвует в связи. Мощность — это число объектов одного класса, связанных с одним объектом другого класса. Понятие мощности связи в объектной модели аналогично понятиям мощности и класса принадлежности связи в модели «сущность-связь» (с точностью до расположения показателя мощности на диаграмме). Для каждой связи можно обозначить два показателя мощности — по одному на каждом конце связи.

Раздел 2. Структура и основные понятия унифицированного языка моделирования (UML)

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

Первым объектно-ориентированным языком принято считать Simula-67, разработанный Далем и Нигардом в Норвегии в 1967 году. Этот язык использовался ограниченно, тем не менее его концепция во многом способствовала появлению других языков. В начале 1980-х годов широко распространился язык Smalltalk, а в конце того же десятилетия стали активно применяться другие объектно-ориентированные языки, такие как Objective C, C++ и Eiffel.

Объектно-ориентированные языки моделирования появились в 1980-х годах. Именно тогда у разработчиков назрела необходимость учитывать новые возможности объектно-ориентированных языков программирования, так как приложения, становившиеся всё более сложными, предъявляли всё более трудные для выполнения требования. Понадобилось начать разработку новых, альтернативных подходов к анализу и проектированию. В период с 1989 по 1994 год число объектно-ориентированных методов возросло с десяти более чем до пятидесяти. Тем не менее многие пользователи затруднялись выбрать язык моделирования, который полностью отвечал бы их потребностям, что привело к так называемой «войны методов». В результате появилось новое поколение методов, среди которых особое значение приобрели метод Буча, OOSE (Object-Oriented Software Engineering), разработанный Якобсоном, и OMT (Object Modeling Technique), разработанный Рамбо. Кроме того, следует упомянуть методы Fusion, Shlaer-Mellor и Coad-Yourdon.

Критическая масса новых идей начала накапливаться к середине 1990-х годов, когда Гради Буч (компания Rational Software Corporation), Джеймс Рамбо (General Electric), Ивар Якобсон (Objectory) и некоторые другие разработчики попытались объединить свои методы, которые к этому времени уже получили мировое признание как наиболее перспективные в области объектно-ориентированных методов. Они старались создать новый, унифицированный язык моделирования, при этом руководствуясь вполне определенными соображениями. Во-первых, все три метода независимо от желания разработчиков уже развивались во встречном направлении. Разумно было продолжить это движение вместе, а не по отдельности, что помогло бы в будущем устранить нежелательные различия и, как следствие, неудобства для пользователей. Во-вторых, унифицировав методы, проще было привнести стабильность на рынок инструментов объектно-ориентированного моделирования, что дало бы возможность положить в основу всех проектов единый зрелый язык, а создателям инструментальных средств позволило бы сосредоточиться на более продуктивной деятельности. Наконец, следовало полагать, что подобное сотрудничество приведет к усовершенствованию всех трех методов и обеспечит решение задач, для которых любой из них, взятый в отдельности, был не слишком пригоден.

Начав унификацию, разработчики поставили перед собой три главные цели:

1. Моделировать системы целиком, от концепции до исполняемых компонентов, с помощью объектно-ориентированных методов;

2. Решить проблему масштабируемости, которая присуща сложным, критически важным системам;

3. Создать язык моделирования, который может использоваться не только людьми, но и компьютерами.

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

Официальное создание UML началось в октябре 1994 года, после перехода Рамбо в компанию Rational Software, где на тот момент работал Буч. Первоначальной целью было объединение методов Буча и OMT. Первая пробная версия 0.8 Унифицированного метода (Unified Method), как его тогда называли, появилась в октябре 1995 года. Приблизительно в то же время в компанию Rational перешел Якобсон, и проект UML был расширен с целью включить в него OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML. В течение года создатели собирали отзывы от основных компаний-разработчиков программного обеспечения. Выяснилось, что большинство таких компаний сочло UML языком, имеющим стратегическое значение для их бизнеса.

В результате был создан так называемый «консорциум UML». Он объединил организации, которые пожелали предоставить необходимые ресурсы для работы, ориентированной на разработку полной спецификации языка. UML версии 1.0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 года он был представлен в качестве проекта стандартного языка моделирования консорциуму OMG (Object Management Group).

Пересмотренная версия UML (версия 1.1) предложена вниманию OMG в июле 1997 года. В сентябре данная версия была утверждена на заседаниях группы по анализу и проектированию и Комитета по архитектуре OMG, а 14 ноября 1997 года принята в качестве стандарта всеми участниками консорциума OMG.

На протяжении последующих лет специальная рабочая группа OMG (OMG Revision Task Force) поддерживала продвижение проекта UML. Одна за другой создавались версии 1.3, 1.4 и 1.5. За 2000–2003 годы новая, расширенная группа участников проекта создала модернизированную версию UML 2.0. Эта версия рассматривалась в течение года рабочей группой Finalization Task Force (FTF), а в начале 2005 года члены OMG утвердили официальную версию UML 2.0. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development — MDD. Последняя версия UML 2.5 опубликована в июне 2015 года.

В стандарте UML предусмотрен следующий набор диаграмм:

• Структурные (structural) модели:

диаграммы классов (class diagrams) -- для моделирования статической структуры классов системы и связей между ними;

диаграммы компонентов (component diagrams) — для моделирования иерархии компонентов (подсистем) системы;

диаграммы размещения (deployment diagrams) — для моделирования физической архитектуры системы.

• Модели поведения (behavioral):

диаграммы вариантов использования (use case diagrams) — для моделирования бизнес-процессов и функциональных требований к создаваемой системе;

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

диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) — для моделирования процесса обмена сообщениями между объектами;

диаграммы состояний (statechart diagrams) — для моделирования поведения объектов системы при переходе из одного состояния в другое;

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

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

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

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

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

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

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

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

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

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

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

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

2.2. Диаграммы взаимодействия

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

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

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

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

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

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

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

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

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

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

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

Во-вторых, это наличие фокуса управления. Фокус управления (focus of control), изображаемый высоким узким прямоугольником, показывает период времени, в течение которого объект выполняет действие – как непосредственно, так и с помощью зависимой процедуры. Верхняя грань прямоугольника выровнена по началу действия, а нижняя – по его завершению и может быть отмечена сообщением возврата. Можно показать вложенность фокуса управления, вызванную рекурсией, вызовом собственной операции либо возвратом вызова из другого объекта, наложив другой фокус управления чуть правее родительского (таким образом можно изобразить сколько угодно уровней вложения). Если нужно особенно точно показать расположение фокуса управления, можно оттенить часть прямоугольника, обозначающего период времени, в течение которого на самом деле работает метод объекта и управление не передается другому объекту. Однако следует заметить, что на практике такая конструкция выглядит довольно «утяжеленной».

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

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

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

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

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

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

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

На диаграммах классов обычно представлены следующие элементы:

⵼ классы;

⵼ интерфейсы;

⵼ зависимости, обобщения и ассоциации.

Как и другие диаграммы, они могут содержать примечания и ограничения.

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

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

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

1. Для моделирования словаря системы.

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

2. Для моделирования простых коопераций.

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

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

2.4. Диаграммы состояний

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

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

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

Диаграмма состояний (state diagram) показывает автомат, сосредотачивая внимание на потоке управления от одного состояния к другому. Изображается в виде графа с вершинами и дугами (ребрами).

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

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

Событие (event) – спецификация существенного факта, который происходит во времени и пространстве. В контексте автомата событие – это воздействие, которое вызывает переход между состояниями.

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

Деятельность (activity) специфицирует работу, происходящую внутри автомата.

Действие (action) – примитивное выполняемое вычисление, приводящее к смене состояния модели или возврату значения.

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

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

2.5. Диаграммы деятельности

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

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

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

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

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

Узел деятельности (activity node) – это организационная единица деятельности, которая представляет собой вложенную группу действий или других вложенных узлов. Более того, узлы деятельности имеют видимую подструктуру и, как правило, требуют некоторого времени на завершение. Действие можно представлять как частный случай узла деятельности. Точнее говоря, это такой узел деятельности, который не может быть подвергнут декомпозиции. Аналогичным образом узел деятельности можно рассматривать как композицию, поток управления которой состоит из других действий и узлов. Если погрузиться в детали внутреннего устройства узла деятельности, там можно обнаружить другую диаграмму деятельности. Нотация действия и узла деятельности одинакова, за исключением того, что последний может иметь дополнительные части, которые обычно поддерживаются инструментом редактирования за пределами диаграммы.

2.6. Диаграммы компонентов и диаграммы размещения

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

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

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

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

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

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

3. Для моделирования физических баз данных. Физическую базу данных можно представить как конкретную реализацию схемы, существующую на уровне битов. Схемы, по сути, описывают API (application programming interface, программный интерфейс приложения) для доступа к хранимой информации; модель же физической базы представляет способы хранения информации в таблицах реляционной базы или на страницах объектно-ориентированной базы данных. Для представления этих и иных физических баз данных можно использовать диаграммы компонентов.

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

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

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

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

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

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

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

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

2. Моделирование клиент-серверных (client/server) систем. Они представляют собой типичный пример архитектуры, в которой основное внимание уделяется четкому распределению обязанностей между интерфейсом пользователя, расположенном на клиенте, и хранимыми данными системы, размещаемыми на сервере. Клиент-серверные системы находятся на одном конце спектра распределенных систем и требуют от проектировщика принятия решений о том, как связать клиенты и серверы сетью, а также о том, как физически распределены программные компоненты между узлами. Диаграммы размещения позволяют моделировать топологию такой системы.

3. Моделирование полностью распределенных систем. На другом конце спектра распределенных систем находятся те из них, которые распределены широко или даже глобально (fully distributed) и охватывают серверы различных уровней. Нередко на таких системах устанавливаются разные версии программных компонентов, часть которых даже мигрирует с одного узла на другой. Проектирование подобной системы требует решений, которые допускают непрерывное изменение системной топологии. Диаграммы размещения можно использовать для визуализации текущей топологии и распределения компонентов системы, чтобы можно было аргументированно обсуждать влияние на нее различных изменений.

Раздел 3. Программные продукты, реализующие
объектно-ориентированный подход

Термином CASE-средства (аббревиатура от Computer Aided Software Engineering) обозначаются программные средства, которые поддерживают процессы создания и сопровождения информационных систем. Эти процессы включают (но не исчерпываются):

1. анализ и формулировку требований,
2. проектирование прикладного программного обеспечения (приложений) и баз данных,
3. тестирование генерацию кода,
4. обеспечение качества,
5. документирование,
6. конфигурационное управление и управление проектом.

Наиболее известен выпущенный фирмой Computer Associates (СА) интегральный пакет инструментальных средств, поддерживающих все этапы разработки информационных систем – AllFusion Modeling Suite. В этот пакет входит 5 продуктов:

1. AllFusion Process Modeler (прежнее наименование – BPwin).

2. AllFusion ERwin Data Modeler – инструмент создания моделей данных и генерации схем баз данных. Прежнее название – ERwin 4.1.

3. AllFusion Data Model Validator – система поиска и исправления ошибок модели данных. Прежнее название - ERwin Examiner.

4. AllFusion Model Manager – система организации коллективной работы, хранилище моделей BPwin и ERwin. Прежнее название – ModelMart 4.1.

5. AllFusion Component Modeler – инструмент создания объектных моделей. Прежнее название - Paradigm Plus.

AIIFusion Component Modeler является мощным объектно-ориентированным инструментальным средством, позволяющим эффективно генерировать код приложений.

AIIFusion Component Modeler поддерживает методологию CA Catalysis. Методология Catalysis основывается на стандарте объектного моделирования UML и специально ориентирована на технологию компонентной разработки. AIIFusion Component Modeler и Catalysis обеспечивают эффективные решения и минимальный риск при реализации крупномасштабных проектов, ориентированных на компонентную сборку.

AIIFusion Component Modeler 4.1 призван обеспечить полный технологический цикл разработки крупных ИС. С этой целью он интегрирован с целым рядом инструментальных средств СА и других фирм.

По умолчанию AIIFusion Component Modeler содержит несколько окон и инструментальных панелей:

• Workspace - навигатор модели.

• Property - окно (расположено слева внизу) отображает свойства элементов модели.

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

♦ Панель задач.

♦ Панель инструментов.

♦ Палитра инструментов (вид которой зависит от типа редактируемой диаграммы).

Каждое из окон можно переместить и скрыть (настройка видимости окон и панели инструментов производится в меню View).

Панель задач (task bar) по умолчанию расположена в левой верхней части основного окна AllFusion Component Modeler. Панель задач состоит из четырех разделов и позволяет организовать работу над проектом в соответствии с ролями разработчиков:

• Analyst (аналитик);

• Designer (дизайнер);

• Implementor (кодировщик);

• Reporting (создатель отчетов).

Для переключения на раздел панели задач следует щелкнуть по кнопке с названием раздела. Окно каждого раздела содержит список задач. Для создания новой задачи следует щелкнуть правой кнопкой мыши по окну панели задач и выбрать пункт меню Customize. Появляется диалог Task Ваг

Каждая задача представляет собой выполняемый скрипт, например на Visual Basic или Java. Для создания новой задачи необходимо щелкнуть по кнопке, внести в окно диалога Task Ваг имя задачи, затем щелкнуть по кнопке Browse и выбрать файл скрипта. Для включения задачи в раздел необходимо щелкнуть по Apply.

Окно Workspace имеет 3 вкладки – Models, Packages и Diagrams. Вкладка Models содержит древовидный список элементов модели, который является верхним уровнем представления модели. Вкладка Packages содержит список пакетов. Пакет является нижним уровнем модели и может включать задачи и другие модели, используемые в проекте. Вкладка Diagrams содержит список диаграмм модели.

Модель AIIFusion Component Modeler представляет собой совокупность диаграмм, описывающих различные аспекты структуры и поведения информационной системы. Для создания новой диаграммы следует перейти на вкладку Models окна Workspace Workspace и щелкнуть правой кнопкой мыши по модели, в которой создается новая диаграмма. В контекстном меню следует выбрать пункт New Diagram и затем тип диаграммы. AIIFusion Component Modeler позволяет создавать диаграммы восьми типов:

1. Activity (деятельности).

2. Class (классов).

3. Collaboration (кооперации).

4. Sequence (последовательности).

5. State (состояний).

6. UseCase (вариантов использования).

7. Component (компонентов).

8. Deployment (развертывания).

После выбора нужного типа в правой верхней части основного окна AIIFusion Component Modeler появляется окно редактора диаграмм (Diagram Editor).

AllFusion Component Modeler поддерживает генерацию кода приложения на основе диаграмм классов и создание классов на основе кода приложения, а именно прямое и обратное проектирования для четырех сред разработки:

• Java;

• Corba;

• Visual Basic;

• Visual C++.

Рассмотрим пример генерации кода на Java. Прежде всего необходимо выбрать пункт меню Tools/Java/Export. При этом возникает диалог Code Generation, в котором последовательно показывается два экрана.

На первом экране диалога Code Generation расположены два списка. В левом списке содержится перечень моделей и классов. Правый список содержит перечень классов, на основе которых будет сгенерирован код приложения. Кнопка служит для включения классов из левого списка в правый. В верхней части окна содержится поле Default code directory, задающая каталога, в который будут помещены файлы сгенерированного кода.

Щелчок по кнопке Next инициализирует процесс генерации кода. Второй экран диалога Code Generation показывает протокол генерации.

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

В AIIFusion Component Modeler реализована взаимная интеграция с AIIFusion ERwin Data Modeler. Комбинация объектного моделирования AIIFusion Component Modeler и углубленных возможностей моделирования данных в ERwin повышает производительность и сокращает время разработки информационной системы.

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

Интеграция ERwin и AIIFusion Component Modeler обеспечивает:

• возможность импорта сущностей из модели ERwin и создание соответствующих классов в модели AIIFusion Component Modeler;

• разработку приложений с использованием хранилищ моделей для обеспечения коллективной разработки;

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

• перенос информации, внесенной на этапе анализа и проектирования в модель данных, и использование ее для генерации схемы баз данных;

• автоматическую генерацию отчетов по проекту на основе информации, находящейся в хранилище проектов;

• моделирование систем с многоуровневой архитектурой в AIIFusion Component Modeler, что может бьпъ использовано для разработки корпоративных систем;

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

• переход от объектной модели к реляционной модели.

Ещё одной популярной CASE-системой является разработка IBM Rational Rose. Само название Rational Rose переводится с английского либо как "Рациональная роза", либо как "Повышение рациональности", что связано с неоднозначностью перевода слова "Rose".

Rational Rose разработана компанией Rational (ныне входит в состав IBM), которая основана в 1981 году и занимается созданием CASE-технологий. Программные продукты фирмы Rational предназначены для анализа требований к системе, разработки программного обеспечения, тестирования, управления проектами и поддержки команды разработчиков.

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

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

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

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

— диаграммы классов используются для отображения объектов системы и отношений между ними;

— диаграммы компонентов показывают отношения классов с физическими компонентами системы;

— диаграммы размещения применяют для визуализации проекта распределенных систем.

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

Существенным достоинством Rose является то, что он позволяет генерировать «скелетный код» для большого количества различных языков таких, как C++, Java, Visual Basic и PowerBuilder. Также в Rose реализована возможность для выполнения обратного проектирования кода и таким образом воссоздания модели уже существующих систем. Полезно иметь модели Rose для уже существующих приложений. Если было сделано изменение в модели, Rose позволяет модифицировать код для его реализации. Напротив, если был изменен код, то можно автоматически обновить определенным образом и модель. Благодаря такой возможности можно поддерживать соответствие между моделью и кодом, уменьшая риск устаревания модели.

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

Основными элементами интерфейса Rose являются:

— браузер (browser) предназначен для удобной навигации по модели;

— окно документации (documentation window) служит для работы с документацией элементов модели;

— панели инструментов (toolbars) служит для обеспечения быстрого доступа к наиболее часто используемым командам;

— окно диаграммы (diagram window) служит для просмотра и редактирования диаграмм UML;

— журнал (log) предназначен для просмотра отчетов о результатах выполнения различных команд и ошибок.

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

Браузер позволяет выполнять следующие операции:

— добавлять элементы к модели;

— просматривать структуру модели и ее элементы;

— просматривать отношения, которые связывают элементы модели;

— перемещать элементы модели и переименовывать их;

— добавлять к диаграмме элементы модели;

— создавать и открывать диаграммы;

— связывать элемент с документом, хранящимся в файле на локальном ресурсе, или создавать веб-ссылку на внешний ресурс;

— группировать элементы модели в пакеты;

— просматривать и редактировать спецификацию элемента модели.

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

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

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

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

Модель Rose поддерживает четыре представления (views) модели UML:

— представление Вариантов использования (прецедентов) – включает в себя всех действующих лиц, все варианты использования и их диаграммы для разрабатываемой системы. Может также включать диаграммы Последовательности и Кооперативные диаграммы. отвечает на вопрос: какие функции будет выполнять проектируемая система в интересах пользователя;

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

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

— представление Размещения – отражает физическое размещение системы на технических средствах заказчика (может существенно отличаться от логической архитектуры системы).

Каждое из перечисленных представлений выполняет определенную задачу и предназначено для различных групп заинтересованных лиц. Все перечисленные представления отображаются в браузере.

ЗАКЛЮЧЕНИЕ

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

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

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

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

1. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. 2-е изд.: Пер. с англ. Мухин Н. – М.: ДМК Пресс, 2006. – 496 с.: ил.
2. Буч, Гради, Максимчук, Роберт Α., Энгл, Майкл У, Янг, Бобби Дж., Коналлен, Джим, Хьюстон, Келли А. Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд.: Пер. с англ. – М.: ООО "И.Д. Вильямс", 2008. – 720 с.: ил.
3. Вайсфельд М. Объектно-ориентированное мышление. — СПб.: Питер, 2014. — 304 с.: ил. — (Серия «Библиотека программиста»).
4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2006. — 544 с: ил.
5. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. – М.: ДИАЛОГ-МИФИ,2003. – 432 с.
6. Олейник П.П. Корпоративные информационные системы: Учебник для вузов. Стандарт третьего поколения. — СПб.: Питер, 2012. — 176 с.: ил.
7. Основные концепции и механизмы объектно-ориентированного программирования. – СПб.: БХВ-Петербург, 2005. – 640 с.: ил.
8. Проектирование информационных систем. / Под общ. ред. Д.В. Чистова. — М.: Издательство Юрайт, 2019. — 258 с.
9. Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии: Практикум. – М.: Горячая линия-Телеком, 2005. – 160 с: ил.
10. Эванс, Эрик. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем.: Пер. с англ. – М.: ООО "И.Д. Вильямс", 2011. – 448 с.: ил.