И В ЧEРВEНЧУК ИНФОРМАЦИОННЫE СИСТEМЫ И ПРОЦEССЫ МОДEЛИРОВАНИE И УПРАВЛEНИE 2

Механизмы расширения. UML - это стандартный язык для разработки "чертежей" программного обеспечения, но ни один замкнутый язык не в состоянии охватить нюансы всех возможных моделей в различных предметных областях. Поэтому UML является открытым языком, то есть допускает контролируемые расширения. Механизмы расширения UML включают:
- стереотипы;
- помеченные значения;
- ограничения.
Стереотип (Stereotype) расширяет словарь UML, позволяя на основе существующих блоков языка создавать новые, специфичные для решения конкретной проблемы. Например, работая с такими языками программирования, как Java или C++, часто приходится моделировать исключения (Exceptions) - они являются обыкновенными классами, хотя и рассматриваются особым образом. Обычно требуется, чтобы исключения можно было возбуждать и перехватывать, и ничего больше. Если пометить исключения соответствующим стереотипом, то с ними можно будет обращаться как с обычными строительными блоками языка; на рис. 1.19 это продемонстрировано на примере класса Overflow.

Рис. 1.19. Механизмы расширения

Помеченное значение (Tagged value) расширяет свойства строительных блоков UML, позволяя включать новую информацию в спецификацию элемента. Скажем, если вы работаете над "коробочным" продуктом и выпускаете много его версий, то зачастую необходимо отслеживать версию и автора какой-нибудь важной абстракции. Ни версия, ни автор не являются первичными концепциями UML, но их можно добавить к любому блоку, такому, например, как класс, задавая для него новые помеченные значения. На рис. 1.19 показано, как это можно сделать, на примере класса EventQueue.
Ограничения (Constraints) расширяют семантику строительных блоков UML, позволяя определять новые или изменять существующие правила. Вы можете, например, ограничить класс EventQueue так, чтобы все события добавлялись в очередь по порядку. На рис. 1.19 показано, как можно определить ограничение, которое явно постулирует это правило для операции add.
Совместно эти три механизма расширения языка позволяют модифицировать UML в соответствии с потребностями вашего проекта. Кроме того, они дают возможность адаптировать UML к новым технологиям разработки программного обеспечения, например к вероятному появлению более мощных языков распределенного программирования. С помощью механизмов расширения можно создавать новые строительные блоки, модифицировать существующие и даже изменять их семантику. Не забывайте, однако, о чувстве меры: за расширениями важно не потерять главную цель UML - возможность обмена информацией.

1.4. Архитектура программной системы

Для визуализации, специфицирования, конструирования и документирования программных систем необходимо рассматривать их с различных точек зрения. Все, кто имеет отношение к проекту, - конечные пользователи, аналитики, разработчики, системные интеграторы, тестировщики, технические писатели и менеджеры проектов - преследуют собственные интересы, и каждый смотрит на создаваемую систему по-разному в различные моменты ее жизни. Системная архитектура является, пожалуй, наиболее важным артефактом, который используется для управления всевозможными точками зрения и тем самым способствует итеративной и инкрементной разработке системы на всем протяжении ее жизненного цикла.
Архитектура - это совокупность существенных решений касательно:
- организации программной системы;
- выбора структурных элементов, составляющих систему, и их интерфейсов;
- поведения этих элементов, специфицированного в кооперациях с другими элементами;
- составления из этих структурных и поведенческих элементов все более и более крупных подсистем;
- архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, их интерфейсы, кооперации и способ их объединения.
Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты, но и использование, функциональность, производительность, гибкость, возможности повторного применения, полноту, экономические и технологические ограничения и компромиссы, а также эстетические вопросы [1, c 47].
Как показано на рис. 1.20, архитектура программной системы наиболее оптимально может быть описана с помощью пяти взаимосвязанных видов или представлений, каждый из которых является одной из возможных проекций организации и структуры системы и заостряет внимание на определенном аспекте ее функционирования.
Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестировщиками. Этот вид специфицирует не истинную организацию программной системы, а те движущие силы, от которых зависит формирование системной архитектуры. В языке UML статические аспекты этого вида передаются диаграммами прецедентов, а динамические - диаграммами взаимодействия, состояний и действий.
Вид с точки зрения проектирования (Design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Этот вид поддерживает прежде всего функциональные требования, предъявляемые к системе, то есть те услуги, которые она должна предоставлять конечным пользователям. С помощью языка UML статические аспекты этого вида можно передавать диаграммами классов и объектов, а динамические - диаграммами взаимодействия, состояний и действий.
Вид с точки зрения процессов (Process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы. В UML его статические и динамические аспекты визуализируются теми же диаграммами, что и для вида с точки зрения проектирования, но особое внимание при этом уделяется активным классам, которые представляют соответствующие нити и процессы.
Вид с точки зрения реализации (Implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой. В языке UML статические аспекты этого вида передают с помощью диаграмм компонентов, а динамические - с помощью диаграмм взаимодействия, состояний и действий.

Рис. 1.20. Моделирование системной архитектуры

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

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

Контрольные вопросы

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

Упражнения

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

2. КЛАССЫ

Классы - это самые важные строительные блоки любой объектно-ориентированной системы. Они представляют собой описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов.
Классы используются для составления словаря разрабатываемой системы (cм, например, [2, c. 65]). Это могут быть абстракции, являющиеся частью предметной области, либо классы, на которые опирается реализация. С их помощью описывают программные, аппаратные или чисто концептуальные сущности.
Хорошо структурированные классы характеризуются четкими границами и помогают формировать сбалансированное распределение обязанностей в системе.
Введение
Моделирование системы предполагает идентификацию сущностей, важных с той или иной точки зрения. Эти сущности составляют словарь моделируемой системы. Например, если вы строите дом, то для вас как домовладельца будут иметь значение стены, двери, окна, встроенные шкафы и освещение. Каждая из названных сущностей отличается от других и характеризуется собственным набором свойств. У стен есть высота и ширина, они твердые и сплошные. У дверей также есть высота и ширина, они тоже сплошные, но, кроме того, снабжены особым механизмом, позволяющим им открываться в одну сторону. Окна похожи на двери, поскольку представляют собой проемы в стенах, но в остальном свойства указанных сущностей различаются. Окна обычно (хотя и не всегда) проектируют так, чтобы через них можно было смотреть, но не проходить.
Стены, двери и окна редко существуют сами по себе, поэтому необходимо решить, как они будут стыковаться друг с другом. Какие сущности вы выберете и какие отношения между ними решите установить, очевидно, определяется в зависимости от того, как вы собираетесь использовать комнаты в доме, как будете перемещаться между ними, а также от общего стиля и обстановки, которые входят в ваш замысел.
Строителей, обслуживающий персонал и жильцов интересуют разные вещи. Водопроводчики обратят внимание на трубы, краны и вентиляционные отверстия. Вас как домовладельца это особенно не касается, если не считать случаев, когда указанные элементы пересекаются с теми, которые попадают в ваше поле зрения, - вас волнует, например, где труба вмонтирована в пол и в каком месте крыши открывается вентиляция.
В языке UML все сущности подобного рода моделируются как классы. Класс -это абстракция сущностей, являющихся частью вашего словаря. Класс представляет не индивидуальный объект, а целую их совокупность. Так, умозрительно вы можете считать, что "стена" - это класс объектов с некоторыми общими свойствами, такими как высота, длина, толщина, несущая это стена или нет, и т.д. При этом конкретные стены будут рассматриваться как отдельные экземпляры класса "стена", одним из которых является, например, "стена в юго-западной части моего кабинета".
Многие языки программирования непосредственно поддерживают концепцию классов. И это замечательно, поскольку в таком случае создаваемые вами абстракции могут быть непосредственно отображены в конструкциях языка программирования, даже если речь идет об абстракциях непрограммных сущностей типа "покупатель", "торговля" или "разговор".
Графическое изображение класса в UML показано на рис. 4.1, Такое обозначение позволяет визуализировать абстракцию независимо от конкретного языка программирования и подчеркнуть ее наиболее важные характеристики: имя, атрибуты и операции.

2.1. Термины и понятия

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

Рис. 2.2. Простые и составные имена

Имя класса может состоять из любого числа букв, цифр и ряда знаков препинания (за исключением таких, например, как двоеточие, которое применяется для отделения имени класса от имени объемлющего пакета). Имя может занимать несколько строк. На практике для именования класса используют одно или несколько коротких существительных, взятых из словаря моделируемой системы. Обычно каждое слово в имени класса пишется с заглавной буквы, например: Customer (Клиент), Wall (Стена), TemperatureSensor (ДатчикТемпературы).
Атрибуты.
Атрибут - это именованное свойство класса, включающее описание множества значений, которые могут принимать экземпляры этого свойства. Класс может иметь любое число атрибутов или не иметь их вовсе. Атрибут представляет некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Например, у любой стены есть высота, ширина и толщина; при моделировании клиентов можно задавать фамилию, адрес, номер телефона и дату рождения. Таким образом, атрибут является абстракцией данных объекта или его состояния. В каждый момент времени любой атрибут объекта, принадлежащего данному классу, обладает вполне определенным значением. Атрибуты представлены в разделе, который расположен под именем класса; при этом указываются только их имена (см. рис. 2.3).
Имя атрибута, как и имя класса, может быть произвольной текстовой строкой. На практике для именования атрибута используют одно или несколько коротких существительных, соответствующих некоторому свойству объемлющего класса. Каждое слово в имени атрибута, кроме самого первого, обычно пишется с заглавной буквы, например name или loadBearing.
При описании атрибута можно явным образом указывать его класс и начальное значение, принимаемое по умолчанию, как продемонстрировано на рис. 2.4.

Операции
Операцией называется реализация услуги, которую можно запросить у любого объекта класса для воздействия на поведение. Иными словами, операция - это абстракция того, что позволено делать с объектом. У всех объектов класса имеется общий набор операций. Класс может содержать любое число операций или не содержать их вовсе. Например, для всех объектов класса Rectangle (Прямоугольник) из библиотеки для работы с окнами, содержащейся в пакете awt языка Java,определены операции перемещения, изменения размера и опроса значений свойств. Часто (хотя не всегда) обращение к операции объекта изменяет его состояние или его данные. Операции класса изображаются в разделе, расположенном ниже раздела с атрибутами. При этом можно ограничиться только именами, как показано на рис. 2.5. Более детальная спецификация выполнения операции осуществляется с помощью примечаний и диаграмм деятельности.
Имя операции, как и имя класса, может быть произвольной текстовой строкой. На практике для именования операций используют короткий глагол или глагольный оборот, соответствующий определенному поведению объемлющего класса. Каждое слово в имени операции, кроме самого первого, обычно пишут с заглавной буквы, например move или isEmpty.
Операцию можно описать более подробно, указав ее сигнатуру, в которую входят имена и типы всех параметров, их значения, принятые по умолчанию, а применительно к функциям - тип возвращаемого значения, как показано на рис. 2.6.

Организация атрибутов и операций

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

Рис. 2.7. Использование стереотипов для описания свойств класса

Обязанности
Обязанности (Responsibilities) класса - это своего рода контракт, которому он должен подчиняться. Определяя класс, вы постулируете, что все его объекты имеет однотипное состояние и ведут себя одинаково. Выражаясь абстрактно, соответствующие атрибуты и операции как раз и являются теми свойствами, посредством которых выполняются обязанности класса. Например, класс Wall (Стена) отвечает за информацию о высоте, ширине и толщине. Класс Менеджер доступа, который встречается в информационных системах с ограничением доступа к данным, отвечает за соответствие прав определенных пользователей производимому ими запросу - имеются ли у них права доступа к запрашиваемым данным или нет. Класс TemperatureSensor (ДатчикТемпературы) отвечает за измерение температуры и подачу сигнала тревоги в случае превышения заданного уровня.
Моделирование классов лучше всего начинать с определения обязанностей сущностей, которые входят в словарь системы. На этом этапе особенно полезны будут такие методики, как применение CRC-карточек и анализ прецедентов. В принципе число обязанностей класса может быть произвольным, но на практике хорошо структурированный класс имеет по меньшей мере одну обязанность; с другой стороны, их не должно быть и слишком много. При уточнении модели обязанности класса преобразуются в совокупность атрибутов и операций, которые должны наилучшим образом обеспечить их выполнение.
Графически обязанности изображают в особом разделе в нижней части пиктограммы класса (см. рис. 2.8).

Рис. 2.8. Обязанности

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

Другие свойства
При создании абстракций вам чаще всего придется иметь дело с атрибутами, операциями и обязанностями. Для большинства моделей этого вполне достаточно, чтобы описать важнейшие черты семантики классов. Но иногда приходится визуализировать или специфицировать и другие особенности, как то: видимость отдельных атрибутов и операций, специфические для конкретного языка программирования свойства операции (например, является ли она полиморфной или константной) или даже исключения, которые объекты класса могут возбуждать или обрабатывать. Эти и многие другие особенности тоже можно выразить в UML, но в таком случае требуется обращение к более развитым возможностям языка.
Занимаясь построением моделей, вы довольно быстро обнаружите, что почти все создаваемые абстракции являются разновидностью классов. Иногда бывает необходимо отделить реализацию класса от его спецификации, что в UML может быть выражено с помощью интерфейсов.
Переходя к разработке более сложных моделей, вы всякий раз будете сталкиваться с теми же классами (которые представляют, например, параллельные процессы и потоки или физические сущности, в частности апплеты, компоненты JavaBeans и СОМ+, файлы, Web-страницы, аппаратные средства). Поскольку подобные классы очень распространены и представляют важные архитектурные абстракции, в UML имеются такие элементы, как активные классы, компоненты и узлы.
Наконец, классы редко существуют сами по себе. При построении моделей следует обращать внимание на группы взаимодействующих между собой классов. В языке UML такие сообщества принято называть кооперациями и изображать на диаграммах классов.

2.2. Типичные приемы моделирования. Словарь системы

С помощью классов обычно моделируют абстракции, извлеченные из решаемой задачи или технологии, применяемой для ее решения. Такие абстракции являются составной частью словаря вашей системы, то есть представляют сущности, важные для пользователей и разработчиков.
Для пользователей не составляет труда идентифицировать большую часть абстракций, поскольку они созданы на основе тех сущностей, которые уже использовались для описания системы. Чтобы помочь пользователям выявить эти абстракции, лучше всего прибегнуть к таким методам, как использование CRC-карточек и анализ прецедентов. Для разработчиков же абстракции являются обычно просто элементами технологии, которая была задействована при решении задачи.
Моделирование словаря системы включает в себя следующие этапы:
1.Определите, какие элементы пользователи и разработчики применяют для описания задачи или ее решения. Для отыскания правильных абстракций используйте CRC-карточки и анализ прецедентов.
2.Выявите для каждой абстракции соответствующее ей множество обязанностей. Проследите, чтобы каждый класс был четко определен, а распределение обязанностей между ними хорошо сбалансировано.
3. Разработайте атрибуты и операции, необходимые для выполнения классами своих обязанностей.

Рис. 2.9. Моделирование словаря системы

На рис. 2.9 показан набор классов для системы розничной торговли: Customer (Клиент), Order (Заказ) и Product (Товар). Представлено несколько соотнесенных с ними абстракций, взятых из словаря проблемной области: Shipment (Отгрузка), Invoice (Накладная) и Warehouse (Склад). Одна абстракция, а именно Transaction (Транзакция), применяемая к заказам и отгрузкам, связана с технологией решения задачи.
По мере того как вы будете строить все более сложные модели, обнаружится, что многие классы естественным образом объединяются в концептуально и семантически родственные группы. В языке UML для моделирования таких групп классов используются пакеты.
Как правило, модели не бывают статичными. Напротив, большинство абстракций из словаря системы динамически взаимодействует друг с другом. В UML существует несколько способов моделирования такого динамического поведения.

Распределение обязанностей в системе

Если в ваш проект входит нечто большее, нежели пара несложных классов, предстоит позаботиться о сбалансированном распределении обязанностей. Это значит, что надо избегать слишком больших или, наоборот, чересчур маленьких классов. Каждый класс должен хорошо делать что-то одно. Если ваши абстрактные классы слишком велики, то модель будет трудно модифицировать и повторно использовать. Если же они слишком малы, то придется иметь дело с таким большим количеством абстракций, что ни понять, ни управлять ими будет невозможно. Язык UML способен помочь в визуализации и специфицировании баланса обязанностей.
Моделирование распределения обязанностей в системе включает в себя следующие этапы:
1. Идентифицируйте совокупность классов, совместно отвечающих за некоторое поведение.
2. Определите обязанности каждого класса.
3. Взгляните на полученные классы как на единое целое и разбейте те из них, у которых слишком много обязанностей, на меньшие - и наоборот, крошечные классы с элементарными обязанностями объедините в более крупные.
4. Перераспределите обязанности так, чтобы каждая абстракция стала в разумной степени автономной.
5. Рассмотрите, как классы кооперируются друг с другом, и перераспределите обязанности с таким расчетом, чтобы ни один класс в рамках кооперации не делал слишком много или слишком мало.
В качестве примера на рис. 2.10 показано распределение обязанностей между классами Model (Модель), View (Вид) и Controller (Контроллер) из совокупности классов языка Smalltalk. Как видите, их совместная работа организована так, что ни одному из классов не приходится делать слишком мало или слишком много.

2.3. Непрограммные сущности

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

Рис. 2.10. Моделирование распределения обязанностей в системе

Моделирование непрограммных сущностей производится следующим образом:
1. Смоделируйте сущности, абстрагируемые в виде классов.
2. Если вы хотите отличить эти сущности от предопределенных строительных блоков UML, создайте с помощью стереотипов новый строительный блок, опишите его семантику и сопоставьте с ним ясный визуальный образ.
3.Если моделируемый элемент является аппаратным средством с собственным программным обеспечением, рассмотрите возможность смоделировать его в виде узла, которая позволила бы в дальнейшем расширить его структуру.
Примечание UML предназначен в первую очередь для моделирования программных систем, однако в сочетании с текстовым языком моделирования аппаратных средств, таким как VHDL, его вполне допустимо использовать и для моделирования аппаратных систем.
Как видно из рис. 2.11, абстрагирование людей (AccountsReceivableAgent - АгентПоДебиторскойЗадолженности) и аппаратуры (Robot) в виде классов вполне естественно, поскольку они представляют собой множества объектов с общей структурой и поведением. Сущности, внешние по отношению к системе, часто моделируются как актеры.

Рис. 2.11. Моделирование непрограммных сущностей

2.4. Примитивные типы

Другой крайностью являются сущности, взятые непосредственно из языка программирования, используемого при решении задачи. Обычно к таким абстракциям относят примитивные типы, например целые, символы, строки и даже перечислимые типы, которые вы создаете сами.
Моделирование примитивных типов производится следующим образом:
1. Смоделируйте сущность, абстрагируемую вами в виде типа или перечисления. Она изображается с помощью нотации класса с подходящим стереотипом.
2.Если требуется задать связанный с типом диапазон значений, воспользуйтесь ограничениями.
Рис. 4.12 показывает, что такие сущности можно моделировать в UML как типы или перечисления, которые изображаются точно так же, как классы, но с явно указанным стереотипом. Сущности, подобные целым числам (представленные классом Int), моделируются как типы, а с помощью ограничений вы можете явно указать диапазон принимаемых значений. Перечислимые типы (скажем, Boolean и Status) допустимо моделировать как перечисления, причем их конкретные значения становятся атрибутами.
Примечание Такие языки, как Си C++, позволяют определить эквивалентные целые значения для перечислений. Подобное моделирование возможно и в UML, если указать для атрибута, обозначающего перечисление, константное начальное значение по умолчанию.

Рис. 4.12. Моделирование примитивных типов

2.5. Рекомендации к моделированию классов

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

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

Контрольные вопросы

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

Упражнения

1. Смоделируйте класс "Студент", специфицируйте свойства его атрибутов.
2. Смоделируйте класс "Статистическая выборка", включающий массив исходных данных и вычисляющий, минимальное, максимальное, среднее значение и среднеквадратичное отклонение. Специфицируйте конструкторы и операции, укажите область видимости операций.
3. С использованием класса "Статистическая выборка" из упражнения 3 определите класс "Упорядоченная выборка", позволяющий получить упорядоченный массив элементов. Специфицируйте конструкторы и операции, укажите область видимости операций.
4. Информационная система хранит сведения о сотрудниках небольшого предприятия. Сотрудники могут работать на различных должностях. Часть информации должна быть общедоступна, часть доступна только пользователям с полномочиями. Редактирование данных так же предполагает наличие специальных прав. Для построения модели данной системы введите классы и распределите обязанности между ними.
5. По выполнению упражнения 4 определите атрибуты и операции введенных классов, результаты отобразите на диаграмме классов UML.
6. Информационная система торгового предприятия производит учет товаров, клиентов, фиксирует произведенные продажи. Для построения модели данной системы введите классы и распределите обязанности между ними.
7. По выполнению упражнения 6 определите атрибуты и операции введенных классов, результаты отобразите на диаграмме классов UML.

3. ПРИМЕРЫ МОДЕЛИРОВАНИЯ

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

Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме диаграммы прецедентов (вариантов использования), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования.
В качестве среды моделирования будем использовать систему Rational Rose [3] фирмы Rational Software, являющейся признанным лидером в разработке систем моделирования программного обепспечения.

3.1. Диаграмма прецедентов

Диаграмма прецедентов является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером.
В данной модели актером является пользователь электронной базы данных музыки, а набором действий - редактирование данных и поиск. Между сущностью "Пользователь" и "Редактирование", "Пользователь" и "Поиск исполнителя", а также "Пользователь" и "Поиск альбома", определены отношения ассоциации. Между сущностью "Редактирование" и сущностями "Создание новой записи", "Удаление записи", "Изменение записи" определены отношения включения (include). Между сущностью "Поиск альбома" и сущностями "по названию", "по стилю" также проставлены отношения включения. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. Диаграмма прецедентов приводится на рис. 3.1.

Рис 3.1. Диаграмма прецедентов (Use Case Diagram)

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

Как уже говорилось, диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. Диаграмма классов может содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. На этой диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.
В нашем случае основным является класс "Исполнитель" с атрибутами: "Название", "Дата рождения", "Страна проживания", "Награды", "Фото". С помощью отношения ассоциации он связан с классом "Альбом", с помощью реализации - с классом "Поиск исполнителя", имеющим стереотип "interface", и с классом "Тип Стиля", имеющим стереотип "enum". Классы "Исполнитель" и "Альбом" связаны с классом "Электронная таблица", не имеющим атрибутов, с помощью отношений обобщения. Диаграмма классов для разрабатываемой нами системы приводится на рис. 3.1.

Рис 3.2 Диаграмма классов (Class Diagram)
На основе диаграммы классов модно создать профиль базы данных (диаграмма реляционных таблиц системы). При этом следует иметь ввиду, что объектно-ориентированная модель системы и профиль баз данных далеко не одно и то же. Реляционная модель не поддерживает наследования, имеет типы данных, соответствующие используемой СУБД, для обеспечения связей между таблицами используются специальные кодовые поля.
Подробно о преобразовании объектно-ориентированной модели в реляционную можно прочитать в [6], мы остановимся на основных моментах:
1) основные классы, содержащие данные, предназначенные для хранения, преобразуются в таблицы;
2) при наличии ассоциаций типа "один-к-одному" хотя бы с одной стороны нужно добавить дополнительное кодовое поле где указать код (ключ) второй записи для обеспечения связи данных;
2) при наличии ассоциаций типа "один-ко-многим" со стороны подчиненных записей (со стороны "многие") необходимо ввести дополнительное поле, где указать код (ключ) записи которой они подчиняются (со стороны "один");
3) при наличии ассоциаций типа "многие-ко-многим" необходимо ввести дополнительную таблицу связей, содержащую минимум два поля: код одного участника и код второго участника, таким образом ассоциация типа "многие-ко-многим" преобразуется в две ассоциации типа "один-ко-многим" через таблицу связи;
4) при наличии обобщения необходимо дополнить исходную таблицу, полями соответствующими атрибутам суперкласса (тогда суперкласс не вводить как таблицу), или ввести таблицу суперкласса (с полями соответствующими его атрибутам) а в таблице, соответствующей исходному классу добавить поле, соответствующее коду (ключу) записи суперкласса.
Если реляционная модель была построена на базе хорошо продуманной объектно-ориентрованной модели, полученная реляционная модель обычно не содержит аномалий обновления и удаления информации и удовлетворяет условиям нормализации. Однако полезно проверить полученную реляционную модель на соответствие нормальным формам (см., например, [5, c. 89].
На рис. 3.3. приводится диаграмма профиля данных для разрабатываемой нами информационной системы "музыка на CD".

Рис 3.3. Профиль базы данных

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

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

Рис 3.4. Диаграмма последовательностей (Sequence Diagram)

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

3.4. Реализация информационной системы

Для реализации модели справочно-информационной системы музыки на CD была выбрана одна из самых популярных систем программирования Borland Delphi .
Delphi - это среда быстрой разработки, в которой в качестве языка программирования используется строго типизированный объектно-ориентированный язык Object Pascal, В основе работы Delphi лежит технология визуального проектирования и событийного программирования, суть которой заключается в том, что среда разработки берет на себя большую часть рутинной работы, оставляя программисту работу по конструированию диалоговых окон и функций обработки событий.
Для поддержки процесса программирования из среды моделирования обычно используются специальные программные средства.
Фирмой Ensemble Systems разработана программа-мост Rose Delphi Link (RDL), связывающая Rational Rose и Delphi. Основные функции RDL - это генерация кода и обратное проектирование. Генерируемый RDL код не содержит реализацию функциональности. Генерируются только декларативные элементы: определения классов, интерфейсов, записей, типов и т.д. Основная идея обратного проектирования состоит в том, что все изменения, сделанные на уровне программного кода в Delphi отображаются в объектной модели, построенной в Rational Rose, и наоборот, при изменении классов, методов и т.д. в объектной модели Rational Rose, соответственно, корректируется программный код.

Рис. 3.5 Диаграмма классов, выполненная с помощью Rose Delphi Link

Мощность и гибкость Delphi при работе с базами данных, возможность связи с Rational Rose и отсутствие специальных требований к ресурсам компьютера, позволяют эффективно использовать Delphi для разработки приложения справочно-информационной системы музыки на CD.Приложение состоит из одной формы, на которой находятся следующие основные компоненты: DBGrid, DBEdit, DBNavigator, Table, DataSource и Query.

Рис. 3.6. Внешний вид диалогового окна

Слева на форме отображаются характеристики исполнителя, такие как, "Исполнитель", "Дата рождения", "Страна проживания", "Награды", "Фото".

<< Пред. стр. 2 (из 3) След. >>

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