1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom
.pdfМетодические аспекты проектирования ПО |
201 |
АТМ.ехе называется спецификацией задачи и моделирует поток управления (thread of processing) — исполняемую программу.
Компоненты соединены зависимостями. Например, класс Card Reader зависит от класса ATM Screen. Это означает, что, для того чтобы класс Card Reader мог быть скомпилирован, класс ATM Screen должен уже существовать. После компиляции всех классов может быть создан исполняемый файл ATMClient.exe.
Банковская система содержит два потока управления и, та ким образом, получаются два исполняемых файла. Один из них — это клиентская часть системы, она содержит компоненты Cash Dispenser, Card Reader и ATM Screen. Второй файл — это сервер, включающий в себя компонент Account. Диаграмма компонен тов для сервера показана на рис. 2.58.
ATMServer.exe
cz;b
c=D
II
!
i
Account
^
Account
,*'^.-
Рис. 2.58. Диаграмма компонентов для сервера
Как видно из примера, в модели системы может быть нес колько диафамм компонентов, в зависимости от числа подсис тем или исполняемых файлов. Каждая подсистема является паке том компонентов.
Диаграммы компонентов применяются теми участниками проекта, кто отвечает за компиляцию и сборку системы. Они нужны там, где начинается генерация кода.
202 |
Глава 2 |
2.5.7. ДИАГРАММЫ РАЗМЕЩЕНИЯ
Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать раз мещение объектов и компонентов в распределенной системе.
Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства — в большинстве случаев, часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мэйнфреймом.
Диаграмма размещения показывает физическое расположе ние сети и местонахождение в ней различных компонентов. Ее основные элементы:
•узел (node) — вычислительный ресурс — процессор или дру гое устройство (дисковая память, контроллеры различных
Oracle Server
ATMServer.exe
«Private IS|etwork>:^^
« PrivateNWetwo r k »
ATMCIIent.exe ATMCIJent.exe
Рис. 2.59. Диаграмма размещения для банковской системы
Методические аспекты проектирования ПО |
203 |
устройств и тд.). Для узла можно задать выполняющиеся на нем процессы;
•соединение (connection) — канал взаимодействия узлов (сеть).
Например, банковская система состоит из большого количе ства подсистем, выполняемых на отдельных физических устрой ствах, или узлах. Диаграмма размещения для такой системы по казана на рис. 2.59.
Из данной диафаммы можно узнать о физическом размеще нии системы. Клиентские программы будут работать в несколь ких местах на различных сайтах. Через закрытые сети будет осу ществляться их сообщение с региональным сервером системы. На нем будет работать ПО сервера. В свою очередь, посредством локальной сети региональный сервер будет сообщаться с серве ром банковской базы данных, работающим под управлением Oracle. Наконец, с региональным сервером соединен принтер.
Диаграмма размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом, чтобы понять физическое размещение системы и расположение ее отдельных подсистем.
2.5.8. МЕХАНИЗМЫ РАСШИРЕНИЯ UML
Механизмы расширения UML предназначены для того, что бы разработчики могли адаптировать язык моделирования к сво им конкретным нуждам, не меняя при этом его метамодель. На личие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEFO, IDEF1X, IDEF3, DFD и ERM. Перечисленные языки моделирования можно оп ределить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), являет ся слабо типизированным языком. К его механизмам расшире ния относятся:
•стереотипы;
•тегированные (именованные) значения;
•ограничения.
Стереотип — это новый тип элемента модели, который опре деляется на основе уже существующего элемента. Стереотипы
204 |
Глава 2 |
расширяют нотацию модели, могут применяться к любым эле ментам модели и представляются в виде текстовой метки (см. рис. 2.52) или пиктограммы (иконки).
Стереотипы классов — это механизм, позволяющий разделять классы на категории. Например, основными стереотипами, ис пользуемыми в процессе анализа системы (см. подразд. 4.3.2), яв ляются: Boundary (граница). Entity (сущность) и Control (управ ление).
Граничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окру жающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами.
Классы-сущности (entity classes) отражают основные понятия (абстракции) предметной области и, как правило, содержат хра нимую информацию. Обычно для каждого класса-сущности соз дают таблицу в базе данных.
Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использо вания имеется один управляющий класс, контролирующий пото ки событий этого варианта использования. Управляющий класс отвечает за координацию, но сам не несет в себе никакой функ циональности — остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответствен ность другим классам, по этой причине его часто называют клас сом-менеджером.
В системе могут быть и другие управляющие классы, общие для нескольких вариантов использования. Например, класс SecurityManager (менеджер безопасности) может отвечать за контроль событий, связанных с безопасностью. Класс TransactionManager (менеджер транзакций) занимается коорди нацией сообщений, относящихся к транзакциям с базой данных. Могут быть и другие менеджеры для работы с другими элемента ми функционирования системы, такими, как разделение ресур сов, распределенная обработка данных или обработка ошибок.
Помимо упомянутых стереотипов, разработчики ПО могут создавать собственные наборы стереотипов, формируя тем са мым специализированные подмножества UML (например, для описания бизнес-процессов, Web-приложений, баз данных и
Методические аспекты проектирования ПО |
205 |
т.д.). Такие подмножества (наборы стереотипов) в стандарте язы ка UML носят название профилей языка.
Именованное значение — это пара строк «тег = значение^>, или «имя = содержимое», в которых хранится дополнительная ин формация о каком-либо элементе системы, например, время соз дания, статус разработки или тестирования, время окончания ра боты над ним и т.п.
Ограничение — это семантическое офаничение, имеющее вид текстового выражения на естественном или формальном языке (ОСЬ — Object Constraint Language), которое невозможно выра зить с помощью нотации UML.
Одних графических средств, таких как диаграмма классов или диафамма состояний, недостаточно для разработки точных и непротиворечивых моделей сложных систем. Существует необхо димость задания дополнительных Офаничений, которым долж ны удовлетворять различные компоненты или объекты модели. Традиционно подобные офаничения описывались с помощью естественного языка. Однако, как показала практика системного моделирования, такие сформулированные на естественном язы ке Офаничения страдают неоднозначностью и нечеткостью.
Для преодоления этих недостатков и придания рассуждени ям строгого характера были разработаны различные формальные языки. Однако традиционные формальные языки требуют для своего конструктивного использования знания основ математи ческой логики и теории формального вывода. С одной стороны, это делает формальные языки естественным средством для пост роения математических моделей, а, с другой стороны, сущест венно Офаничивает круг потенциальных пользователей, пос кольку разработка формальных моделей требует специальной квалификации.
Другая особенность традиционных формальных языков зак лючается в присущей им бедной семантике. Базовые элементы формальных языков имеют слишком абстрактное содержание, что затрудняет их непосредственную интерпретацию в понятиях моделей конкретных технических систем и бизнес-процессов. Поскольку процесс объектно-ориентированного анализа и про ектирования направлен на построение конструктивных моделей сложных систем, которые должны быть реализованы в форме профаммных систем и аппаратных комплексов, это является серьезным недостатком. Необходимо применение такого фор-
206 |
Глава 2 |
мального языка, базовые элементы которого адекватно отражают семантику основных конструкций объектной модели.
Именно для этих целей и был разработан язык ОСЬ. По сво ей сути он является формальным языком, более простым для изу чения, чем традиционные формальные языки. В то же время язык ОСЬ специально ориентирован на описание бизнес-про цессов и бизнес-логики, поскольку был разработан в одном из отделений корпорации IBM.
ОСЬ представляет собой формальный язык для описания ог раничений, которые могут быть использованы при определении различных компонентов языка UMb. Хотя язык ОСЬ является частью языка UMb, в общем случае он может иметь гораздо бо лее широкую область приложений, чем конструкции языка UMb. Средства языка ОСЬ позволяют специфицировать не только объ ектные ограничения, но и другие выражения логико-лингвисти ческого характера, такие, как предусловия, постусловия и Офаничивающие условия. Этот язык ничего не изменяет в фафических моделях, а только дополняет их. Это означает, что выражения языка ОСЬ никогда не могут изменить состояние системы, хотя эти выражения и могут быть использованы для спецификации самого процесса изменения этого состояния. Выражения языка ОСЬ также не могут изменять отдельные значения атрибутов и операций для объектов и их связей. Всякий раз, когда оценивает ся одно из таких выражений, на выходе получается лишь некото рое значение.
Язык ОСЬ не является языком профаммирования в обычном смысле, поскольку не позволяет записать логику выполнения профаммы или последовательность управляющих действий. Средства этого языка не предназначены для описания процессов вычисления выражений, а только лишь фиксируют необходи мость выполнения тех или иных условий применительно к от дельным компонентам моделей. Главное назначение языка ОСЬ
— гарантировать справедливость офаничений для отдельных объектов модели. В этом смысле ОСЬ можно считать языком мо делирования, который вовсе не обязан допускать строгую реали зацию в инструментальных средствах.
Язык ОСЬ может быть использован для решения следующих задач:
•описание инвариантов классов и типов в модели классов;
•описание пред- и постусловий в операциях и методах;
Методические аспекты проектирования ПО |
207 |
•описание офаничивающих условий элементов модели;
•навигация по структуре модели;
•спецификация офаничений на операции.
Описание языка OCL отличается от описаний традиционных формальных языков менее формальным характером. Базовым элементом языка OCL является выражение, которое строится по определенным правилам. При этом допускается расширение конструкций языка за счет включения в его состав дополнитель ных типов.
В модели выражение используется для записи некоторых ус ловий, которым должны удовлетворять все экземпляры соответ ствующего классификатора. В этом случае говорят, что выраже ние служит для представления некоторых инвариантных свойств соответствующих элементов модели.
2.5.9. КОЛИЧЕСТВЕННЫЙ АНАЛИЗ ДИАГРАММ UML
Методика количественной оценки и сравнения диафамм UML основана на присвоении элементам диафамм оценок, за висящих от их информационной ценности, а также от вносимой ими в диафамму дополнительной сложности. Ценность отдель ных элементов меняется в зависимости от типа диафаммы, на которой они находятся.
Количественную оценку диафаммы можно провести по сле дующей формуле:
где iS* — оценка диафаммы, 5^^у — оценки для элементов диафам мы, Si„^ — оценки для связей на диафамме, Obj — число объектов на диафамме, Г^^у — число типов объектов на диафамме, Ti^j^ — число типов связей на диафамме.
Если диафамма содержит большое число связей одного типа (например, модель предметной области), то число и тип связей можно не учитывать, и формула расчета приводится к виду:
Если на диафамме классов показаны атрибуты и операции классов, можно учесть их при расчете, при этом оценка прибав ляется к оценке соответствующего класса:
208 |
Глава 2 |
Scis = (^Ор + <Atr) 10,3*( Op |
^Atr), |
где S^is — оценка операций и атрибутов для класса, Ор — число операций у класса, Atr — число атрибутов у класса. При этом учи тываются только атрибуты и операции, отображенные на диаг рамме.
Далее приводятся оценки для различных типов элементов и связей.
Основные элементы языка UML
Тип элемента |
Оценка для элемента |
Класс |
5 |
Интерфейс |
4 |
Вариант использования |
2 |
Компонент |
4 |
Узел (node) |
3 |
Процессор |
2 |
Взаимодействие |
6 |
Пакет |
4 |
Состояние |
4 |
Примечание |
2 |
Основные типы связей языка UML |
|
Тип связи |
Оценка для связи |
Зависимость |
2 |
Ассоциация |
I |
Агрегация |
2 |
Композиция |
3 |
Обобщение |
3 |
Реализация |
2 |
Остальные типы связей должны рассматриваться как ассоци ации.
Недостатком диаграммы является как слишком низкая оцен ка (при этом диафамма недостаточно информативна), так и слишком высокая оценка (при этом диаграмма обычно слишком сложна для понимания). Далее приведены диапазоны оптималь ных оценок для основных типов диаграмм.
Методические аспекты проектирования ПО |
209 |
Диапазоны оценок для диаграммUML |
|
Тип диаграммы |
Диапазон оценок |
Классов — с атрибутами и операциями |
5-5,5 |
Классов — без атрибутов и операций |
3-3,5 |
Компонентов |
3,5-4 |
Вариантов использования |
2,5-3 |
Размещения |
2-2,5 |
Последовательности |
3-3,5 |
Кооперативная |
3,5-4 |
Пакетов |
3,5-4 |
Состояний |
2,5-3 |
2.6. ОБРАЗЦЫ
Образцы (patterns) — это одни из важнейших составных частей объектно-ориентированной технологии разработки ПО. Они широко применяются в инструментах анализа, подробно описы ваются в книгах^ и часто обсуждаются на конференциях семина рах по объектно-ориентированному проектированию. Существу ет множество фупп и курсов по их изучению. Изучение образцов помогает лучше понять объектно-ориентированный анализ и проектирование.
Объектно-ориентированное проектирование ПО — достаточ но сложный процесс, который еще больше усложняется в случае необходимости повторного использования проектных решений. Необходимо подобрать подходящие объекты, отнести их к раз личным классам, соблюдая разумную степень детализации, опре делить интерфейсы классов и иерархию наследования и устано вить существенные связи между классами. Проектное решение должно, с одной стороны, соответствовать решаемой задаче, а с другой — быть достаточно общим, чтобы удалось учесть все тре бования, которые могут возникнуть в будущем. Желательно так же избежать или, по крайней мере, свести к минимуму необходи-
^ Приемы объектно-ориентированного проектирования. Паттерны про ектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес: Пер. с англ. — СПб.: Питер, 2001.
210 |
Глава 2 |
мость перепроектирования. Опытные разработчики знают, что обеспечить «правильное», т.е. в достаточной мере гибкое и при годное для повторного использования решение, с первого раза очень трудно, если вообще возможно. Прежде чем считать цель достигнутой, они обычно пытаются опробовать найденное реше ние на нескольких задачах и каждый раз модифицируют его.
И все же опытному разработчику удается создать хороший проект системы. Прежде всего ему понятно, что не нужно решать каждую новую задачу с нуля. Вместо этого он старается повторно воспользоваться теми решениями, которые оказались удачными в прошлом. Отыскав хорошее решение один раз, он будет прибе гать к нему снова и снова. Именно благодаря накопленному опы ту проектировщик и становится экспертом в своей области. Во многих объектно-ориентированных системах можно встретить повторяющиеся проектные решения (образцы), состоящие из классов и взаимодействующих объектов. С их помощью решают ся конкретные задачи проектирования, в результате чего реше ние становится более гибким, и им можно воспользоваться пов торно. Проектировщик, знакомый с образцами, может сразу же применять их к решению новой задачи, не пытаясь каждый раз «изобретать велосипед».
В 1970-х годах Кристофер Александер, профессор архитектуры Калифорнийского университета написал несколько книг, доку ментируя образцы в гражданском строительстве и архитектуре. Разработчики ПО впоследствии заимствовали идею образцов, ос новываясь на его трудах, тем более, что к тому времени среди прог раммистов уже присутствовал растущий интерес к этим идеям.
По словам Кристофера Александера, «любой образец описы вает задачу, которая снова и снова возникает в нашей работе, а также принцип ее решения, причем таким образом, что это реше ние можно потом использовать миллион раз, ничего не изобретая заново». Хотя Александер имел в виду образцы, возникающие при проектировании зданий и городов, но его слова верны и в от ношении образцов объектно-ориентированного проектирова ния. Решения относительно ПО выражаются в терминах объек тов и интерфейсов, а не стен и дверей, но в обоих случаях образец
можно определить как общеерешение некоторой проблемной ации в заданном контексте. Образец состоит из четырех основных элементов:
• имя;