668.Проектирование информационных систем Раздел 5 Индустриальное проектирование информационных систем Объектно-ориентированная Case-технология проектирования информационных систем.

June 10, 2018 | Author: Anonymous | Category: Каталог , Без категории
Share Embed


Short Description

Download 668.Проектирование информационных систем Раздел 5 Индустриальное проектирование инфор...

Description

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Министерство культуры Российской Федерации ФГОУ ВПО «Кемеровский государственный университет культуры и искусств» Институт информационных и библиотечных технологий Кафедра технологии автоматизированной обработки информации

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ (РАЗДЕЛ 5. ИНДУСТРИАЛЬНОЕ ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ. ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ CASE-ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ) Учебное пособие по специальности 080801 «Прикладная информатика (в информационной сфере)»

Кемерово 2009 1

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Утверждено на заседании кафедры технологии автоматизированной обработки информации 26.05.09 г., протокол № 14. Рекомендовано к изданию УМС института информационных и библиотечных технологий 29.06.09 г., протокол № 10.

Рецензенты: д-р тех. наук, профессор, заведующий кафедрой обогащения полезных ископаемых КузГТУ В. И. Удовицкий, канд. пед. наук, доцент кафедры ЮНЕСКО по новым информационным технологиям КемГУ Л. Е. Шмакова

Малышева, Е. Н Проектирование информационных систем (Раздел 5. Индустриальное проектирование информационных систем. Объектно-ориентированная Case-технология проектирования информационных систем) [Текст]: учеб. пособие / Е. Н. Малышева. – Кемерово: Кемеров. гос. ун-т культуры и искусств, 2009. – 70 с.

2

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

ВВЕДЕНИЕ Технология разработки программных систем, в основу которых положена парадигма представления окружающего мира в виде объектов, являющихся экземплярами соответствующих классов, получила название «объектно-ориентированный анализ и проектирование». Основная идея объектного подхода состоит в том, чтобы заключить данные и связанные с ними процедуры в некие структуры (объекты), объединенные механизмом наследования. Объектноориентированный подход к моделированию и проектированию программных систем наилучшим образом подходит для решения проблем, требующих детального представления объектов реального мира и динамических отношений между ними. Методология объектно-ориентированного анализа и проектирования получила широкое распространение с появлением языка объектного моделирования нового поколения – унифицированного языка моделирования UML (Unified Modeling Language), предназначенного для визуального моделирования и проектирования информационных систем (ИС). Применение современных средств моделирования позволяет реализовать такие методы системного анализа, как создание иерархии понятий, обобщение понятий, наследование свойств, многообразие моделей описания предметной области, визуализацию представлений эксперта о процессах, протекающих в рассматриваемой предметной области. При этом наличие в языке UML изобразительных средств для представления структуры и поведения модели позволяет достичь адекватного представления декларативных и процедурных знаний, а также установить между этими формами знаний семантическое соответствие. Язык UML реализован многими фирмами – производителями программного обеспечения в рамках Case-технологий. В пособии рассматривается методология объектно-ориентированного анализа и моделирования информационных систем. Сформулированы принципы технологии объектного анализа и проектирования информационных систем с использованием языка UML как универсального средства моделирования проектных решений. Рассматриваются принципы разработки концептуальных моделей и моделей динамики поведения

3

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

систем, приводится методика разработки комплекса объектноориентированных моделей на UML. Изложение теоретического материала сопровождается примерами соответствующих диаграмм, способствующих приобретению знаний и умений в области технологий автоматизированного индустриального проектирования информационных систем. Данное пособие разработано по курсу «Проектирование информационных систем» (раздел «Индустриальное проектирование информационных систем») для студентов, обучающихся по специальности 080801 «Прикладная информатика (в информационной сфере)», а также для студентов всех специальностей, связанных с обработкой информации. Учебное пособие может служить основой при изучении раздела «Индустриальное проектирование информационных систем» курса «Проектирование информационных систем». Слова благодарности автор адресует рецензентам – доктору технических наук, профессору, заведующему кафедрой обогащения полезных ископаемых Кузбасского государственного технического университета В. И. Удовицкому и кандидату педагогических наук, доценту кафедры ЮНЕСКО по новым информационным технологиям Кемеровского государственного университета Л. Е. Шмаковой.

4

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Глава 1. ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ПРИ ПРОЕКТИРОВАНИИ ИНФОРМАЦИОННЫХ СИСТЕМ 1.1. Принципы объектно-ориентированного анализа и проектирования Рассмотрение любой сложной системы требует применения техники декомпозиции – разбиения на составляющие элементы. Известны две схемы декомпозиции: алгоритмическая и объектно-ориентированная. В основе алгоритмической декомпозиции заложено разбиение по действиям – алгоритмам. Основным строительным блоком является процедура или функция, а внимание уделяется, прежде всего, вопросам передачи управления и декомпозиции алгоритмов. При изменении требований или увеличении размера приложения становится сложнее его сопровождать. Алгоритмический подход является традиционным при создании программного обеспечения. Наиболее современным подходом к разработке сложных информационных систем являются объектно-ориентированные методологии разработки информационных систем, которые стали интенсивно развиваться с конца 80-х годов. Здесь в качестве основного строительного блока выступает объект или класс. Объект – это абстракция множества предметов реального мира, обладающих одинаковыми характеристиками и законами поведения. Класс – это множество предметов реального мира, связанных общностью структуры и поведения. Элемент класса – это конкретный элемент данного множества. К важным понятиям объектно-ориентированного подхода относят инкапсуляцию, наследование и полиморфизм. Объектно-ориентированный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы самого объекта, скрыты от внешних компонентов. Сокрытие данных и методов в качестве собственных ресурсов объекта получило название инкапсуляции. Понятие полиморфизма может быть интерпретировано как способность объекта принадлежать более чем одному типу. Объектно-ориентированный подход к анализу и проектированию сложных информационных систем активно использует аппарат наследования.

5

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Объектно-ориентированная модель предметной области представляет собой совокупность диаграмм, описывающих с использованием универсального языка объектного проектирования UML различные аспекты структуры и поведения информационной системы. Диаграмма в UML – это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). В некотором смысле диаграмма – это одна из проекций предметной области. В основе объектно-ориентированного анализа и проектирования информационных систем лежат следующие ключевые принципы [5, с. 171]: • принцип абстрагирования; • принцип многомодельности; • принцип иерархической организации. Создавая понятие в рамках какой-либо задачи, необходимо отвлекаться (абстрагироваться) от несущественных характеристик конкретных объектов, определяя только их существенные характеристики. Принцип абстрагирования предписывает включать в модель только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций или своего целевого назначения. Таким образом, абстрагирование сводится к формированию абстракций. Каждая абстракция фиксирует основные характеристики объекта, которые отличают его от других видов объектов и обеспечивают ясные понятийные границы. Абстракция конкретизирует внимание на внешнем представлении объекта, позволяет отделить основное в поведении объекта от его реализации. Принцип многомодельности сводится к утверждению, что никакая отдельно взятая модель не может с достаточной степенью адекватности описать различные аспекты сложной системы. Применительно к UML это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений, каждое из которых адекватно отражает некоторый аспект поведения или структуры системы. Интегрированная модель сложной системы представляется в виде совокупности диаграмм, приведенной на рисунке 1. 6

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Диаграмма прецедентов использования

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

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

Диаграмма размещения

Интегрированная модель сложной системы

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

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

Диаграмма пакетов

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

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

7

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

8

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

вуют отдельно друг от друга (как в модели деятельности организации, так и в модели программной системы), причем проектирование ведется от процессов к данным. Также следует отметить, что если в функциональном подходе модели данных и операций разрабатываются относительно независимо друг от друга и только координируются между собой, то объектноориентированный подход предполагает совместное моделирование данных и процессов, при этом модели проблемной области в репозитории постепенно уточняются. Таким образом, структурная декомпозиция информационной системы на основе объектно-ориентированного подхода отличается от функционально-ориентированного подхода лучшей способностью отражать динамическое поведение системы в зависимости от возникающих событий [7, с. 351]. Основой взаимосвязи между функционально-ориентированным и объектно-ориентированным подходами является общность ряда категорий и понятий (процесс и прецедент использования, сущность и класс и др.). Эта взаимосвязь может проявляться в различных формах. Выделяют ряд следующих преимуществ объектноориентированного подхода [10]: 1. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования не только программ, но и проектов. Системы зачастую получаются более компактными, чем их структурные эквиваленты, что означает не только уменьшение объема программного кода, но и удешевление проекта за счет использования предыдущих разработок. 2. Объектная декомпозиция уменьшает риск создания сложных информационных систем, так как она предполагает эволюционный путь развития системы на базе относительно небольших подсистем. Процесс интеграции системы растягивается на все время разработки, а не превращается в единовременное событие. 3. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования. К недостаткам объектно-ориентированного подхода относятся некоторое снижение производительности функционирования информаци-

9

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

онных систем и высокие начальные затраты. Также следует учитывать, что объектно-ориентированный подход не дает немедленной отдачи. Эффект от его применения начинает сказываться после накопления повторно используемых компонентов, отражающих типовые проектные решения в данной области. Таким образом, переход к использованию объектно-ориентированной технологии – это смена мировоззрения, а не просто изучение новых Case-средств и языков программирования. Объектная декомпозиция существенно отличается от функциональной, поэтому переход на новую технологию связан с дополнительными финансовыми затратами. В настоящее время функционально-ориентированный подход попрежнему сохраняет свою значимость и достаточно широко используется на практике. На примере языка UML хорошо видно, что его авторы заимствовали то рациональное, что можно было взять из функционального подхода: элементы функциональной декомпозиции в диаграммах прецедентов использования, диаграммах состояний, диаграммах деятельностей. Функциональный анализ может представлять собой основу для объектно-ориентированного проектирования. К примеру, элементы структур данных из диаграммы потоков данных могут являться кандидатами в классы в диаграммах классов. Другой формой проявления их взаимосвязи можно считать интеграцию объектной и реляционной технологий. В настоящее время реляционные СУБД являются основным средством реализации крупномасштабных баз данных и хранилищ данных. Реляционная технология используется достаточно долго, освоена большим количеством пользователей и разработчиков. Реляционная модель проста и имеет строгое математическое основание, существует большое разнообразие промышленных средств проектирования, реализации и эксплуатации реляционных БД. Вследствие этого реляционные БД в основном используются для хранения и поиска объектов в так называемых объектно-реляционных системах. Одним из примеров практической реализации взаимосвязи между функционально-ориентированным и объектно-ориентированным подходами является программный интерфейс между функциональноориентированным Case-средством Silverrun и объектно-ориентированным Case-средством IBM Rational Rose.

10

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

1.3. Унифицированный язык моделирования Для создания моделей анализа и проектирования объектноориентированных информационных систем используют языки визуального моделирования. Объектно-ориентированные языки моделирования появились в период с середины 70-х до конца 80-х годов, когда исследователи, поставленные перед необходимостью учитывать новые возможности объектноориентированных языков программирования и требования, предъявляемые все более сложными приложениями, вынуждены были начать разработку различных альтернативных подходов к анализу и проектированию. В настоящее время различают три поколения языков визуального моделирования. И если первое поколение образовывали 10 языков, то с 1989 по 1994 год численность второго поколения уже превысила 50 языков. Среди наиболее популярных языков второго поколения выделяют язык Буча (G. Booch), язык Рамбо (J. Rumbaugh), язык Джекобсона (I. Jacobson), язык Коада-Йордана (Coad-Yourdon), язык Шлеера-Меллора (Shlaer-Mellor) и др. Каждый язык вводил свои выразительные средства, ориентировался на собственный синтаксис и семантику, имел преимущества и недостатки. Так, среди преимуществ языка визуального моделирования, разработанного Бучем, отмечаются предоставляемые разработчику высокие выразительные возможности, которые особенно важны на этапах проектирования и конструирования модели. Язык ОМТ (Object Modeling Technique), автором которого является Джеймс Рамбо, предназначался для анализа и разработки информационных систем, ориентированных на обработку больших объемов данных. В результате возникла острая необходимость унификации языков. Идея унификации привела к появлению языков третьего поколения. Критическая масса новых идей начала формироваться к середине 90х годов, когда Грейди Буч (компания Rational Software), Айвар Джекобсон (компания Objectory) и Джеймс Рамбо (компания General Electric) предприняли попытку объединить свои методы, уже получившие мировое признание как наиболее перспективные в данной области. Разработчики поставили своей целью создать новый унифицированный язык моделирования. В качестве стандартного языка третьего поколения был принят Unified Modeling Language (UML), создававшийся в 1994–1997 годах.

11

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Разработчики языка UML определяют его как «общецелевой язык визуального моделирования, разработанный для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем». При создании UML разработчики ставили следующие задачи [2, с. 119]: • предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разрабатывать модели информационных систем и обмениваться ими; • предусмотреть механизмы расширяемости и специализации для развития базовых концепций; • обеспечить независимость от конкретных языков программирования и процессов разработки; • обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма); • стимулировать рост рынка объектно-ориентированных инструментальных средств; • интегрировать лучший практический опыт. В январе 1997 года выходит версия 1. 0 языка. UML 1. 0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 года он был представлен Группе по управлению объектами (Object Management Group, QMG) на конкурс по созданию стандартного языка моделирования. В июне 1998 года вышла версия UML 1. 2, а осенью 1998 – UML 1. 3. В настоящее время создана версия UML 2. 0. Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы: 1) диаграмма прецедентов использования (use-case diagram), которая отражает функциональность ИС в виде совокупности выполняющихся последовательностей транзакций; 2) диаграмма классов объектов (class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично диаграмме «сущность – связь» функционально-ориентированного подхода; 3) диаграммы состояний (statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий;

12

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

4) диаграммы взаимодействия объектов (interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования; 5) диаграммы деятельности (activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования; 6) диаграммы пакетов (package diagram), которые отображают распределение объектов по функциональным или обеспечивающим системам; 7) диаграмма компонентов (component diagram), которая отображает физические модули программного кода; диаграмма размещения (deployment diagram), которая отображает 8) распределение объектов по узлам вычислительной сети.

13

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Контрольные вопросы 1. Какие ключевые принципы лежат в основе объектноориентированного подхода? 2. Дайте общую характеристику класса. 3. Чем отличается объект от класса? 4. В чем суть принципа многомодельности? 5. Поясните принцип абстрагирования. 6. Как можно представить модель сложной системы с точки зрения UML? 7. В чем суть принципа иерархической организации? 8. Поясните понятие полиморфизма. 9. В чем заключается принципиальное отличие между функционально-ориентированным и объектно-ориентированным подходами? 10. Выделите достоинства и недостатки объектно-ориентированного подхода к проектированию информационных систем. 11. Почему функциональный анализ может представлять собой основу для объектно-ориентированного проектирования? 12. Приведите примеры взаимосвязи между функциональноориентированным и объектно-ориентированным подходами к проектированию информационных систем. 13. Какая необходимость привела к созданию языка визуального моделирования третьего поколения? 14. Поясните назначение UML. 15. Какие диаграммы включают в себя объектно-ориентированные модели в соответствии с нотациями UML?

14

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Глава 2. СТАТИЧЕСКИЕ МОДЕЛИ ОБЪЕКТНООРИЕНТИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ Статические модели обеспечивают представление структуры системы в терминах базовых строительных блоков и отношений между ними, не отражая динамику изменений системы во времени. Эти модели несут в себе не только структурные описания, но и описания операций, реализующих заданное поведение системы. Диаграммы прецедентов использования рассматриваются как главное средство для первичного моделирования системы, фиксации этих требований в форме, которая позволит проводить дальнейшую обработку. Важным средством для представления статических моделей являются диаграммы классов, вершины которых нагружены классами, а дуги – отношениями между ними. Диаграммы классов используются: при анализе – для указания ролей и обязанностей сущностей, которые обеспечивают поведение системы, при проектировании – для фиксации структуры классов, которые формируют системную архитектуру. Для больших проектов значительную роль начинают играть диаграммы пакетов, в которые объединяются классы и их взаимосвязи. 2.1. Диаграммы прецедентов использования В соответствии с методологией объектно-ориентированного анализа и проектирования первым этапом является анализ требований, который подразумевает выделение процессов и требований и их формулировку в виде прецедентов. Диаграмма прецедентов использования (use-case diagram) относится к концептуальному представлению системы, описывая ее назначение. Данная диаграмма определяет поведение системы с точки зрения пользователя. Она разрабатывается для того, чтобы сформулировать требования к поведению системы, создать ее концептуальное представление с целью его последующей детализации в форме логических и физических моделей. Рассмотрим основные понятия, используемые при построении данной диаграммы.

15

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

Рисунок 2 – Эквивалентные прецеденты использования В литературе прецеденты использования также называют вариантами использования. Актеры Актером является любая внешняя по отношению к моделируемой системе сущность, непосредственно взаимодействующая с ней и использующая ее для достижения определенных целей. Говорят, что прецеденты использования инициируются из внешней среды пользователями – актерами ИС. Актеры используются для обозначения ролей, которые могут играть элементы внешней среды при взаимодействии с системой. Несмотря на то, что на диаграммах прецедентов использования они изображаются 16

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

в виде стилизованных человеческих фигурок, действующее лицо также может быть внешней системой, которой необходима некоторая информация от данной системы. Имя актера начинается с заглавной буквы. Часто имена актеров совпадают с должностями, занимаемыми сотрудниками в организации. Например: кассир, продавец, менеджер, руководитель предприятия. Однако ключевым принципом при создании имени актера является роль, которую он играет по отношению к системе. Поэтому в качестве имени актера необходимо использовать нарицательные существительные, а не имена собственные. Выделяют три группы актеров (2): • пользователи системы; • другие системы, взаимодействующие с данной системой; • время. Время становится актером, если от него зависит запуск каких-либо событий в системе. В литературе можно встретить перевод термина «actor» как «действующее лицо» или «актор». Абстрактные актеры и прецеденты При построении диаграммы прецедентов возможно использование абстрактных прецедентов и абстрактных актеров. Абстрактным является прецедент, который не может иметь экземпляров. Такой прецедент не может быть запущен, а значит не связывается с актерами. Введение абстрактных прецедентов в модель обуславливается стремлением разработчика выделить и зафиксировать некоторую функциональность системы, используемую другими прецедентами. Как правило, абстрактные прецеденты связываются с обычными прецедентами отношением обобщения, как показано на рисунке 3. При этом абстрактный прецедент является предком.

Рисунок 3 – Пример абстрактного прецедента

17

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

Рисунок 4 – Пример абстрактного актера Абстрактные актеры не могут иметь экземпляров, а значит не могут инициировать прецеденты. Поэтому абстрактные актеры не связываются с прецедентами. Имена абстрактных актеров и прецедентов пишутся курсивом. На практике абстрактные актеры приводятся на диаграмме прецедентов нечасто. Еще реже применяются абстрактные прецеденты. Отношения в диаграммах прецедентов использования Язык UML определяет несколько типов отношений для описания взаимодействия различных элементов диаграммы. Основными типами используемых отношений диаграммы прецедентов являются следующие: • отношение ассоциации (association relationship); • отношение расширения (extend relationship); • отношение включения (include relationship); • отношение обобщения (generalization relationship). Отношение ассоциации – одно из фундаментальных отношений языка UML, используемое в той или иной форме при создании всех диаграмм языка. Его формальное определение выглядит следующим образом. 18

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

Рисунок 5 – Направленные и ненаправленные ассоциации Кратность ассоциации может быть указана на обоих концах отношения. Она говорит о количестве экземпляров элементов, участвующих в отношении. Рассмотрим диаграмму, приведенную на рисунке 6. Некоторый банк занимается оформлением кредитов для своих клиентов. Кратность, указанная в форме «*», означает, что каждый клиент может оформить на себя несколько кредитов. При этом их число не известно, заранее не ограничено и может быть равно 0, т. е. некоторые клиенты могут не брать кредитов вовсе. На другом конце отношения кратность

19

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

Рисунок 6 – Кратность отношения ассоциации Если кратность отношения ассоциации не указана, она по умолчанию принимается равной единице. Отношение расширения призвано зафиксировать на диаграмме прецедентов тот факт, что один из прецедентов может присоединить к своему поведению некоторое дополнительное поведение, определенное для другого прецедента. Оно всегда является направленным и образуется путем наложения стереотипа «extend» («расширяет») на отношение зависимости. Его формальное определение выглядит следующим образом. Если имеет место отношение расширения, направленное от прецедента А к прецеденту В, это означает, что свойства экземпляра прецедента В могут быть дополнены благодаря наличию свойств у расширяющего прецедента А. Отношение расширения изображается пунктирной стрелкой и направлено от прецедента, расширяющего исходный прецедент, как показано на рисунке 7.

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

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

Рисунок 8 – Отношение включения Отношение включения между двумя прецедентами указывает, что некоторое поведение одного прецедента включается в качестве составного компонента в последовательность действий другого прецедента, называемого базовым. При этом базовый прецедент может зависеть от результатов выполнения включаемого в него прецедента. В качестве примера использования отношения включения можно привести создание сайта (рисунок 9). Так, его создание возможно только после проектирования его контента, что показано путем введения преце21

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

дента «Проектирование контента сайта» в базовый прецедент использования.

Рисунок 9 – Пример использования отношения включения Отношение обобщения Отношение обобщения служит для указания того факта, что некоторый прецедент A может быть обобщен до прецедента B. В этом случае прецедент A будет являться потомком прецедента B, а B будет считаться предком или родителем прецедента A. Потомок наследует все свойства и поведение родителя и может быть дополнен новыми свойствами и особенностями поведения. На диаграмме отношение обобщения представляется сплошной стрелкой, на конце которой располагается незакрашенный треугольник. Отношение обобщения всегда является направленным, указывая на родительский элемент, как показано на рисунке 10.

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

22

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Рисунок 11 – Пример использования отношения обобщения между актерами Рассмотрим отношение обобщения между актерами на примере системы продажи товаров, разработанной для функционирования в сети Интернет (рисунок 11). Разместить заказ посредством сайта может только зарегистрированный пользователь. Пользователь, не прошедший процедуру регистрации на сайте, может лишь просматривать каталог. Чтобы отразить на диаграмме тот факт, что зарегистрированный пользователь тоже имеет возможность просматривать каталог, введено отношение обобщения между актерами «Пользователь» и «Зарегистрированный пользователь». На практике отношение обобщения между прецедентами используется реже, чем отношение обобщения между актерами. Потоки событий Поток событий – это последовательность событий, необходимых для обеспечения требуемого поведения. Поток событий описывается в терминах предметной области. Поток событий включает: • краткое описание; • предусловия; • основной поток событий; • альтернативные потоки событий;

23

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»



постусловия. Последовательно рассмотрим эти составные части. Каждый прецедент использования должен иметь связанное с ним описание того, что он будет делать. Предусловия прецедента представляют собой условия, которые должны быть, прежде чем прецедент начнет выполняться. Например, в роли предусловия могут быть указаны необходимость выполнения другого прецедента или наличие у пользователя прав, требуемых для запуска прецедента. Наличие предусловий для прецедента не является обязательным. Постусловиями называются условия, которые должны быть выполнены после завершения прецедента. Конкретные детали прецедентов использования описываются в основном и альтернативных потоках событий в форме неформальных текстовых комментариев. Основной поток событий приводит к требуемому результату наиболее коротким путем. 2.2. Диаграммы классов объектов Диаграмма классов объектов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов отражает различные взаимосвязи между отдельными сущностями предметной области, а также описывает их внутреннюю структуру и типы отношений. На диаграмме классов не указывается информация о временных аспектах функционирования системы. Класс в языке UML служит для обозначения множества объектов, которые обладают идентичной структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, разделенного на три части. В верхней части представлено имя класса объектов, в средней – его атрибуты, в нижней части – операции класса, отражающие его поведение (действия, выполняемые классом или методы) (рисунок 12). Обязательным элементом обозначения класса является его имя. На начальных этапах разработки диаграммы отдельные классы могут обозначаться прямоугольником с указанием только имени класса. По мере

24

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

проработки отдельных компонентов диаграммы, описания классов дополняются атрибутами и методами (операциями) (рисунок 12).

Рисунок 12 – Графическое представление класса на диаграмме классов объектов Имя класса указывается в верхней части прямоугольника, записывается по центру полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать существительные, отображающие суть классов объектов. Примерами имен классов могут быть такие существительные, как «Студент», «Компания», «Руководитель», «Клиент», «Продавец», «Менеджер», «Офис» и другие, имеющие непосредственное отношение к моделируемой предметной области и функциональному назначению проектируемой системы. Класс может не иметь экземпляров или объектов. В этом случае он называется абстрактным классом, а для обозначения его имени используется наклонный шрифт (курсив). Атрибуты – это значения, характеризующие объект в его классе, перечисляются в средней части прямоугольника, изображающего класс. Примерами атрибутов объектов класса «Файл» являются имя файла, дата и время создания, размер, метод доступа; класса «Человек» – имя, возраст, вес и т. д. Среди атрибутов выделяют постоянные (константы) и переменные атрибуты. Постоянные атрибуты характеризуют объект в его классе (например, номер счета, категория, имя человека и т. п.) и имеют неизменное значение. Значения переменных атрибутов характеризуют текущее состояние объекта (например, баланс счета, возраст человека); изменяя значения этих атрибутов, мы изменяем состояние объекта. В языке UML принята определенная стандартизация записи атрибутов класса, которая подчиняется некоторым синтаксическим правилам.

25

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, типа значений атрибута: : Квантор видимости может принимать одно из трех возможных значений и отображается при помощи специальных символов: • public (общедоступный) – это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В соответствии с нотацией UML, символ «+» обозначает атрибут с областью видимости типа «общедоступный». • protected (защищенный) – атрибут с таким значением видимости доступен только самому классу и его потомкам. Нотация UML для защищенного атрибута – знак « # ». private (закрытый) – атрибут, недоступный другим классам. За• крытый атрибут обозначается знаком « – ». Вместо условных графических обозначений можно записывать соответствующие ключевые слова: public, protected, private. Квантор видимости может быть опущен. Его отсутствие означает, что видимость атрибута не указывается. Атрибуты рекомендуется делать закрытыми или защищенными. Это позволит избежать ситуации, когда значение атрибута изменяется всеми классами системы. При задании атрибутов могут быть использованы две дополнительные синтаксические конструкции – это подчеркивание строки атрибута и пояснительный текст в фигурных скобках. Подчеркивание строки атрибута означает, что соответствующий атрибут может принимать подмножество значений из некоторой области значений атрибута, определяемой его типом. Эти значения можно рассматривать как набор однотипных записей или массив, которые в совокупности характеризуют каждый объект класса. Имена атрибутов записываются со строчной буквы, а их типы – с заглавной.

26

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Операции – это функции (или преобразования), которые можно применять к объектам данного класса; они Файл реализуют связанное с классом поведение, записываются в нижней части прямоимя файла угольника, изображающего класс. дата и время создания Примерами операций для класса размер метод доступа «Файл» – создать, открыть_для_чтения, читать, переименовать, сохранить, закрыть создать (рисунок 13). открыть_для_чтения Запись операций класса в языке читать переименовать UML также стандартизована и подчиняетсохранить ся определенным синтаксическим правизакрыть лам. При этом каждой операции класса соРисунок 13 – Пример класса ответствует отдельная строка, которая со«Файл» стоит из квантора видимости операции, имени операции, типа возвращаемого операцией значения: является подразделением : Отдел

> выполняет работу > менеджер : Сотрудник

Рисунок 32 – Графическое изображение связей с различными стереотипами

48

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

49

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

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

50

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

щем состоянии. На диаграмме такой переход изображается сплошной линией со стрелкой. Ветвление Ситуация, когда последовательно выполняемая деятельность разделяется на альтернативные ветви в зависимости от значения некоторого промежуточного результата, называется ветвлением. Графически ветвление на диаграмме деятельности обозначается ромбом. В этот ромб может входить только одна стрелка от того состояния действия, после выполнения которого деятельность может быть продолжена по одной из взаимно исключающих ветвей. Принято входящую стрелку присоединять к верхней вершине символа ветвления. Для каждой из выходящих стрелок должно быть указано соответствующее условие. В качестве примера рассмотрим алгоритм нахождения корней квадратного уравнения. В общем случае после приведения уравнения второй степени к каноническому виду ax 2 + bx + c = 0 необходимо вычислить его дискриминант. В случае отрицательного дискриминанта уравнение не имеет решения на множестве действительных чисел, и дальнейшие вычисления должны быть прекращены. При неотрицательном дискриминанте уравнение имеет решение, корни которого могут быть получены на основе расчетной формулы. Графически фрагмент процедуры вычисления корней квадратного уравнения может быть представлен в виде диаграммы деятельности с тремя состояниями действия и ветвлением, как показано на рисунке 34.

Рисунок 34 – Диаграмма деятельности для алгоритма нахождения корней квадратного уравнения

51

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

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

52

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Контрольные вопросы 1. Поясните назначение динамических моделей объектноориентированных систем. 2. Для чего применяются диаграммы состояний? 3. Определите основные понятия, используемые в диаграмме состояний. 4. Как графически представляется состояние на диаграмме состояний? 5. Поясните общий синтаксис представления действия при описании состояния. 6. Какие значения определены для метки действия в UML? 7. Какие события определены на диаграммах состояний? 8. Какими атрибутами описывается переход состояний? 9. Как задаются составные состояния в диаграммах состояний? 10. Что общего в диаграммах последовательностей и кооперативных диаграммах? Чем они отличаются друг от друга? 11. Для чего служит линия жизни, определяемая в диаграммах последовательностей? 12. Как отображается порядок передачи сообщений в диаграммах последовательностей? 13. Что такое фокус управления? 14. Что такое кооперация? 15. Выделите основные элементы кооперативной диаграммы. 16. Каким образом на кооперативной диаграмме отражается последовательность взаимодействий? 17. Поясните общий синтаксис определения объекта в кооперативных диаграммах. 18. Какой объект в кооперативной диаграмме является составным? 19. Приведите примеры составных объектов кооперативных диаграмм. 20. Какие стереотипы может иметь связь на кооперативной диаграмме? 21. Охарактеризуйте средства и возможности диаграммы деятельности. 22. Как графически изображается состояние действия на диаграммах деятельности? 23. Каким образом на диаграмме деятельности отображается ветвление? 24. Как в диаграммах деятельности представлено протекание параллельных процессов? 25. Какие состояния действия можно выделить при нахождении корней квадратного уравнения? 53

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Глава 4. МОДЕЛИ РЕАЛИЗАЦИИ ОБЪЕКТНООРИЕНТИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ Статические и динамические модели описывают логическую организацию системы. Модели реализации обеспечивают представление системы в физическом мире, рассматривая вопросы упаковки логических элементов в компоненты и размещения компонентов в аппаратных узлах. 4.1. Диаграммы компонентов В отличие от ранее рассмотренных диаграмм, диаграммы компонентов (component diagram) описывают особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых могут выступать исходный, бинарный и исполняемый коды. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними. Диаграммы компонентов разрабатываются для следующих целей: • визуализации общей структуры исходного кода программной системы; • спецификации исполнимого варианта программной системы; • обеспечения многократного использования отдельных фрагментов программного кода; • представления концептуальной и физической схем баз данных. Разработка диаграмм компонентов предполагает использование информации как о логическом представлении модели системы, так и об особенностях ее физической реализации. До начала разработки необходимо принять решения о выборе вычислительных платформ и операционных систем, на которых предполагается реализовывать систему, а также о выборе конкретных баз данных и языков программирования. Для представления физических сущностей в языке UML применяется специальный термин – компонент. Компонент реализует некоторый 54

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

Рисунок 36 – Графическое изображение компонента Изображение этого символа может незначительно варьироваться в зависимости от характера ассоциируемой с компонентом информации. На рисунке 37 представлены некоторые из общепринятых обозначений компонентов. Эти дополнительные обозначения не специфицированы в языке UML, однако их применение упрощает понимание диаграммы компонентов, существенно повышая наглядность ее физического представления.

Рисунок 37 – Графические изображения компонентов В качестве простых имен принято использовать имена исполняемых файлов (с указанием расширения ехе), имена динамических библиотек (расширение dll), имена web-страниц (расширение html), имена текстовых файлов (расширения txt или doc) или файлов справки (hlp), имена файлов баз данных (DB) или имена файлов с исходными текстами программ (расширения h, cpp для языка C++, расширение java для языка Java), скрипты (pi, asp) и др. 55

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

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

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

По способу связи компонента с интерфейсом различают: • экспортируемый интерфейс – интерфейс, который реализует компонент и предлагает его как услугу клиентам; • импортируемый интерфейс – интерфейс, который компонент использует как услугу другого компонента. Для указания связи компонента и интерфейса рисуют стрелку от компонента-клиента к импортируемому интерфейсу (рисунок 39).

Рисунок 39 – Графическое изображение отношения зависимости между компонентом и интерфейсом Наличие такой стрелки означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и другой компонент, который реализует этот интерфейс. Так, например, изображенный ниже фрагмент диаграммы компонентов представляет информацию о том, что компонент с именем «main. exe» зависит от импортируемого интерфейса IDialog, который, в свою очередь, реализуется компонентом с именем «image. java». Для второго компонента этот же интерфейс является экспортируемым. Другим случаем отношения зависимости на диаграмме компонентов является отношение между различными видами компонентов (рисунок 40). Наличие подобной зависимости означает, что внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента.

57

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Рисунок 40 – Графическое изображение отношения зависимости между компонентами На диаграмме компонентов могут быть представлены отношения зависимости между компонентами и реализованными в них классами (рисунок 41). Эта информация имеет важное значение для обеспечения согласования логического и физического представлений модели системы. При этом изменения в структуре описаний классов могут привести к изменению компонента.

Рисунок 41 – Графическое изображение зависимости между компонентом и классами 58

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Следует отметить, что диаграмма компонентов, как правило, разрабатывается совместно с диаграммой размещения, на которой представляется информация о физическом размещении компонентов программной системы по ее отдельным узлам. 4.2. Диаграммы размещения Диаграмма размещения (deployment diagram) – вторая из двух разновидностей диаграмм реализации UML, моделирующих физические аспекты объектно-ориентированных систем. Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов. При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. То есть компоненты, которые не используются на этапе исполнения, на диаграмме размещения не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов, на диаграмме размещения они не указываются. Диаграмма размещения содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма размещения является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. При разработке диаграммы размещения ставятся следующие цели: • определить распределение компонентов системы по ее физическим узлам; • показать физические связи между всеми узлами реализации системы на этапе ее исполнения; • выявить «узкие места» системы и реконфигурировать ее топологию для достижения требуемой производительности. Разработка диаграммы размещения начинается с идентификации всех аппаратных, механических и других типов устройств, которые необходимы для выполнения системой всех ее функций. Дальнейшее по-

59

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

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

Рисунок 43 – Фрагмент диаграммы размещения с соединением между узлами

60

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Кроме соединений, на диаграмме размещения могут присутствовать отношения зависимости между узлом и развернутыми на нем компонентами (рисунок 44).

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

61

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Контрольные вопросы 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.

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

62

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

ПРИЛОЖЕНИЕ Терминология языка UML Агрегация – отношение «часть – целое». Актер – любая внешняя по отношению к моделируемой системе сущность, непосредственно взаимодействующая с ней и использующая ее для достижения определенных целей. Актер абстрактный – актер, который не может иметь экземпляров. Актер – роль, которую пользователь играет по отношению к системе. Ассоциация бинарная – ассоциация между двумя классами. Взаимодействие – поведение, заключающееся в обмене набором сообщений между набором объектов. Вызов – атрибут перехода состояний, определяющий имя события, которое вызывает переход состояний. Действие – атрибут перехода состояний, информационно описывающий сущность действия, которое должно выполняться при переходе состояний. Деятельность – состояние, в котором проявляется некоторое поведение. Диаграмма – графическое представление набора элементов, обычно в виде связного графа, в вершинах которого находятся предметы, а дуги представляют отношения. Диаграмма взаимодействия (interaction diagram) – диаграмма, включающая в себя набор объектов и их отношений, а также посылаемые между объектами сообщения; отображает динамическое взаимодействие объектов в рамках одного прецедента использования. Диаграмма деятельности (activity diagram) – диаграмма, которая отображает потоки работ во взаимосвязанных прецедентах использования. Диаграмма классов объектов (class diagram) – диаграмма, которая отображает структуру совокупности взаимосвязанных классов объектов. Диаграмма компонентов (component diagram) – диаграмма, отображающая физические модули программного кода. Диаграмма кооперативная (collaboration diagram) – диаграмма взаимодействия, отображающая структурную организацию объектов, посылающих и принимающих сообщения. Диаграмма пакетов (package diagram) – диаграмма, отображающая распределение объектов по функциональным или обеспечивающим системам. Диаграмма последовательности (sequence diagram) – диаграмма взаимодействия, выделяющая временную последовательность передачи сообщений.

63

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Диаграмма прецедентов использования (use-case diagram) – диаграмма, отражающая функциональность ИС в виде совокупности выполняющихся последовательностей транзакций. Диаграмма размещения (deployment diagram) – диаграмма, отображающая распределение объектов по узлам вычислительной сети. Диаграмма состояний (statechart diagram) – диаграмма, отображающая динамику состояний объектов одного класса и связанных с ними событий. Инкапсуляция – процесс отделения друг от друга отдельных элементов объекта, определяющих его устройство и поведение. Класс – множество объектов, связанных общностью структуры и поведения. Любой объект является экземпляром класса. Класс абстрактный – класс, объект которого не может быть создан непосредственно. Кооперация – множество взаимодействующих с определенной целью объектов в общем контексте моделируемой системы. Линия жизни объекта – линия на диаграмме последовательности, которая отражает существование объекта в течение некоторого периода времени. Назначение – атрибут перехода состояний, описывающий состояние объекта, в которое перейдет объект после перехода состояния. Наследование – построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Нотация (языка моделирования) – совокупность графических объектов, которые используются в моделях. Объект – это абстракция множества предметов реального мира, обладающих одинаковыми характеристиками и законами поведения. Объект активный – объект, инициирующий деятельность по управлению другими объектами. Объект пассивный – объект, который не может инициировать деятельность по управлению другими объектами; может оперировать данными, посылать сигналы в процессе выполнения запросов. Объектная декомпозиция – описание структуры системы в терминах объектов и связей между ними, а поведения системы – в терминах обмена сообщениями между объектами. Операция (метод) – определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию. Отношение – семантическая связь между объектами. Пакет – множество взаимосвязанных классов объектов.

64

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

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

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Список литературы Бабич, А. В. UML: Первое знакомство [Текст] / А. В. Бабич. – М.: Бином. Лаборатория знаний, 2008. – 176 с. 2. Вендров, A. M. Проектирование программного обеспечения экономических информационных систем [Текст]: учебник / A. M. Вендров. – М.: Финансы и статистика, 2006. – 544 с. 3. Ларман, К. Применение UML 2. 0 и шаблонов проектирования. Введение в объектно-ориентированный анализ и проектирование [Текст]: учебник / К. Ларман. – СПб.: Вильямс, 2008. – 736с. 4. Лешек, А. Анализ и проектирование информационных систем с помощью UML 2. 0 [Текст] / А. Лешек, Мацяшек. – СПб.: Вильямс, 2008. – 816 с. 5. Орлов, С. А. Технологии разработки программного обеспечения [Текст] / С. А. Орлов. – СПб.: Питер, 2004. – 527 с. 6. Путилин, А. Б. Компонентное моделирование и программирование на языке UML: практическое руководство по проектированию информационно-измерительных систем [Текст] / А. Б. Путилин. – М.: НТ Пресс, 2005. – 664 с. 7. Смирнова, Г. Н. Проектирование экономических информационных систем [Текст] / Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов. – М.: Финансы и статистика, 2001. – 512 с. 8. Трофимов, С. А. CASE-технологии: Практическая работа в Rational Rose [Текст] / С. А. Трофимов. – М.: Бином-Пресс, 2002. – 288 с. 9. Фаулер, М. UML. Основы: краткое руководство по стандартному языку объектного моделирования [Текст] / М. Фаулер. – М., 2008. – 192 с. 10. Якобсон, А. Унифицированный процесс разработки программного обеспечения [Текст] / А. Якобсон, Г. Буч, Дж. Рамбо. – СПб.: Питер, – 2002. – 496 с. 1.

66

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Предметный указатель А Актеры .......................................... 16 абстрактные.............................. 16 В Ветвление ..................................... 51 Д Деятельность ................................ 50 Диаграммы...................................... 6 взаимодействия объектов ....... 42 деятельности ............................ 49 классов объектов...................... 24 кооперативные ......................... 45 компонентов ............................. 54 прецедентов использования ... 15 размещения............................... 59 пакетов ...................................... 34 состояний.................................. 38 И Инкапсуляция................................. 5 Интерфейс..................................... 56 импортируемый ....................... 57 экспортируемый....................... 57 К Класс ......................................... 5, 24 абстрактный.............................. 25 атрибуты ................................... 25 имя............................................. 25 операции ................................... 27 Компонент .................................... 54 Кооперация ................................... 45 Л Линия жизни................................. 43 Н Наследование ................................. 5

О Объект .......................................5, 46 активный ...................................47 пассивный .................................46 составной ..................................47 Объектно-ориентированный подход..............................................8 Отношение в диаграммах прецедентов использования ассоциации................................19 включения .................................21 обобщения.................................22 расширения ...............................20 Отношение в диаграммах классов объектов агрегации...................................31 ассоциации................................28 зависимости ..............................30 композиции ...............................32 обобщения.................................32 П Пакет..............................................34 Переход состояний.......................40 атрибуты....................................40 вызов..........................................40 действие ....................................40 назначение ................................40 условие перехода......................40 Поток событий..............................23 Полиморфизм .................................5 Предусловия .................................24 Прецеденты использования ........16 абстрактные ..............................17

67

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Постусловия ................................. 24 Принцип абстрагирования......................... 6 иерархической организации ..... 7 многомодельности ..................... 6 Р Разделение .................................... 52 С Слияние......................................... 52 Состояние ..................................... 38 начальное.................................. 39 конечное.................................... 39

составное...................................41 Сообщение ....................................49 Соединения ...................................60 У Узел................................................60 Ф Фокус управления ........................45 Функциональноориентированный подход..............8 Case-средство................................10 UML ...............................................11

Указатель иллюстраций Интегрированная модель сложной системы в нотации UML............................. 7 Эквивалентные прецеденты использования ....................................................... 16 Пример абстрактного прецедента ........................................................................ 17 Пример абстрактного актера ................................................................................ 18 Направленные и ненаправленные ассоциации ................................................... 19 Кратность отношения ассоциации....................................................................... 20 Пример использования отношения расширения ................................................ 20 Отношение включения.......................................................................................... 21 Пример использования отношения включения .................................................. 22 Пример использования отношения обобщения между прецедентами ............ 22 Пример использования отношения обобщения между актерами..................... 23 Графическое представление класса на диаграмме классов объектов .............. 25 Пример класса «Файл».......................................................................................... 27 Графическое изображение отношения бинарной ассоциации между классами...................................................................................................... 29 Ассоциация, направленная от класса «Законодательство» к классу «Гражданин» .......................................................................................................... 30 Графическое изображение отношения зависимости на диаграмме классов ... 30 Графическое представление отношения агрегации на диаграмме классов..... 31 Отношения агрегации между ПК и его элементами .......................................... 31

68

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

Графическое представление отношения композиции на диаграмме классов........32 Пример использования отношения композиции с указанием кратности ........ 32 Графическое представление отношения обобщения на диаграмме классов... 33 Пример использования отношения обобщения на диаграмме классов ........... 33 Графическое представление пакета ..................................................................... 35 Графическое представление отношения вложенности пакетов друг в друга на диаграмме пакетов............................................................................................ 36 Графическое изображение состояния на диаграмме состояний....................... 39 Графическое изображение начального и конечного состояний ....................... 40 Составное состояние с двумя вложенными в него последовательными подсостояниями ..................................................................................................... 41 Графическое изображение составного состояния с вложенными параллельными подсостояниями ......................................................................... 42 Графическое представление элементов диаграммы последовательности....... 44 Примеры записи объектов на кооперативных диаграммах............................... 46 Графическое изображение составного объекта на кооперативной диаграмме ............................................................................................................... 47 Графическое изображение связей с различными стереотипами ...................... 48 Графическое изображение состояния действия ................................................. 50 Диаграмма деятельности для алгоритма нахождения корней квадратного уравнения.......................................................................................... 51 Изображение разделения и слияния параллельных потоков на диаграмме деятельности........................................................................................................... 52 Графическое изображение компонента............................................................... 55 Графические изображения компонентов ............................................................ 55 Графическое изображение интерфейса на диаграмме компонентов ............... 56 Графическое изображение отношения зависимости между компонентом и интерфейсом........................................................................................................ 57 Графическое изображение отношения зависимости между компонентами ... 58 Графическое изображение зависимости между компонентом и классами ..... 58 Графическое изображение узла на диаграмме размещения.............................. 60 Фрагмент диаграммы размещения с соединением между узлами ................... 60 Диаграмма размещения с отношениями зависимости между узлом и развернутыми на нем компонентами ............................................................... 61

69

Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»

СОДЕРЖАНИЕ Введение......................................................................................................................3 Глава 1. Основы объектно-ориентированного подхода при проектировании информационных систем ......................................................5 1.1. Принципы объектно-ориентированного анализа и проектирования.............5 1.2. Сопоставление и взаимосвязь функционально-ориентированного и объектно-ориентированного подходов.................................................................8 1.3. Унифицированный язык моделирования .......................................................11 Контрольные вопросы .............................................................................................14 Глава 2. Статические модели объектно-ориентированных информационных систем....................................................................................................15 2.1. Диаграммы прецедентов использования ........................................................15 2.2. Диаграммы классов объектов ..........................................................................24 2.3. Диаграммы пакетов...........................................................................................34 Контрольные вопросы .............................................................................................37 Глава 3. Динамические модели объектно-ориентированных информационных систем.........................................................................................38 3.1. Диаграммы состояний ......................................................................................38 3.2. Диаграммы взаимодействия объектов ............................................................42 3.3. Диаграммы деятельностей ...............................................................................49 Контрольные вопросы .............................................................................................53 Глава 4. Модели реализации объектно-ориентированных информационных систем....................................................................................................54 4.1. Диаграммы компонентов..................................................................................54 4.2. Диаграммы размещения ...................................................................................59 Контрольные вопросы .............................................................................................62 Приложение. .............................................................................................................63 Терминология языка UML ...............................................................................63 Список литературы ...........................................................................................66 Предметный указатель......................................................................................67 Указатель иллюстраций....................................................................................68

Подписано к печати 8.10.2009. Бумага офсетная. Гарнитура «Таймс». Отпечатано на ризографе. Уч.-изд. л. 2,6. Тираж 300 экз. Заказ № 416. ___________________________________________________________ Издательство КемГУКИ: 650029, г. Кемерово, ул. Ворошилова, 19. Тел. 73-45-83. E-mail: [email protected]

70

View more...

Comments

Copyright � 2017 UPDOC Inc.