Файл: Инфрам.pdf

222 тат или нет записывает результат в файл
13. Студент завершает работу
14. система завершает работу
Для большей наглядности используют диаграммы вариантов ис- пользования. При этом используются обозначения, которые приведены на рис. 5.22. ((а) – актер, б) – вариант использования, в) – связь).
Рис. 5.22. Диаграмма варианта использования
Для приведенного описания прецедентов диаграмма может выгля- деть, как показано на рис. 5.23.
Рис. 5.23. Диаграмма использования для прецедента П1
Естественно, все варианты использования сразу определить, как правило, не удается: новые варианты постоянно фиксируются по ходу разработки системы и даже в процессе эксплуатации. Но чем больше вариантов выявлено в процессе уточнения спецификаций, тем лучше, так как при этом получают более точную модель предметной области, что уменьшает вероятность ее пересмотра при добавлении функций.
5.3.3. Концептуальная модель предметной области
Концептуальная модель (англ. conceptual model) – это определённое множество понятий и связей между ними, являющихся смысловой структурой рассматриваемой предметной области. На диаграммы такой модели будут смотреть, их будут обдумывать, но с самой моделью ни- чего делать не будут. Это не означает, что модель не нужна – это озна- чает, что модель используется только для управления мыслительным

223 процессом, для понимания. Поэтому такие модели называются концеп- туальными [15]. Такой тип использования моделей один из самых важ- ных, например, потому что так используются модели, которые получа- ются в результате анализа предметной области. Концептуальные модели довольно стабильны: если не меняется предметная область, то нет нуж- ды менять и модель. Главное требования к модели предметной области
– концептуальная целостность (consistency).
Первый шаг к построению концептуальной модели – составление глоссария. Каждый проект влечет за собой массу терминов и определе- ний. Как отмечается в [10], во многих проектах возникает соблазн опус- тить создание глоссария, поскольку он не кажется чем-то значительным и важным. Но глоссарий выполняет две функции, которые не столь оче- видны в начале работы над проектом: он помогает новым людям в проекте быстрее разобраться с ключе- выми терминами, сокращениями и акронимами, используемыми в проекте, тем самым ускоряя их погружение в проект; если в проекте нет глоссария, то участникам проекта придется изу- чать значения терминов путем постепенного их осознания. Это не очень надежный и последовательный способ изучения языка, харак- терного для среды работы заказчика. Глоссарий представляет собой общий репозитарий правильных определений используемых терми- нов.
Центральное место в объектно-ориентированном подходе к проек- тированию ПС занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов определяет типы объектов сис- темы и различного рода статические связи, которые существуют между ними. Класс в языке UML служит для обозначения множества объектов, которые имеют одинаковую структуру, поведение и отношения с объек- тами из других классов. На диаграмме класс изображается в виде пря- моугольника, который дополнительно может быть разделен горизон- тальными линиями на две или три секции (рис. 5.24). В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (ме- тоды). Иногда добавляется четвертая секция, которая содержит описа- ние исключительных ситуаций. Чтобы отличить класс от других эле- ментов языка UML, секции атрибутов и операций выделяют горизон- тальными линиями, даже если они пустые (см. рис. 5.24).
Рис. 5.24. Варианты изображения классов
Обязательный элемент – имя класса. Имя класса должно быть уни- кальным в пределах диаграммы или совокупности диаграмм классов пакета. Оно указывается в первой верхней секции прямоугольника, за-

224 писывается по центру секции полужирным шрифтом и должно начи- наться с заглавной буквы. В качестве имени рекомендуется использо- вать одно или несколько существительных без пробелов. Кроме того, в этой секции могут находиться ссылки на стандартные шаблоны или аб- страктные классы, от которых образован данный класс и от которых он наследует свойства и методы.
Во второй секции прямоугольника записываются атрибуты класса или свойства. Стандартная запись атрибута в языке UML выглядит сле- дующим образом:
< квантор видимости > < имя атрибута > [кратность]:
< тип атрибута > = < исходное значение > {строка-свойств}
Квантор видимости может быть опущен – это означает, что види- мость атрибута не указывается либо же должна принимать одно из трех возможных значений: общедоступный (public) – обозначается «+»; защищенный (protected) – обозначается «#»; закрытый (private) – обозначается «–».
Имя атрибута – единственный обязательный элемент – строка тек- ста, которая используется в качестве идентификатора атрибута и явля- ется уникальной в пределах данного класса.
Кратность атрибута показывает количество конкретных атрибутов данного типа, входящих в состав класса, и обозначается следующим образом:
[нижняя_граница1 .. верхняя_граница1, нижняя_граница2 .. верх- няя_граница2, .. нижняя_ границаk .. верхняя_границаk], где нижняя_граница и верхняя_граница являются положительными целыми числами, каждая пара которых служит для обозначения отдель- ного замкнутого интервала целых чисел. В качестве верхней границы может использоваться специальный символ «*», который означает про- извольное положительное целое число, т.е. неограниченное сверху зна- чение кратности соответствующего атрибута. Если указывается единст- венный знак «*», то это означает, что кратность атрибута может быть произвольным положительным целым числом или нулем. Если крат- ность атрибута не указана, то по умолчанию она равна нулю.
Тип атрибута указывается строкой текста, имеющей осмысленное значение в пределах пакета или модели, к которым относится рассмат- риваемый класс. Можно определить тип атрибута в зависимости от язы- ка программирования, который будет использоваться при реализации данной модели.
Исходное значение служит для задания некоторого начального зна- чения для соответствующего атрибута в момент создания отдельного экземпляра класса.
В третьей секции класса прямоугольника, обозначающего некоторый класс, указывается операция (или операции) класса. Часто понятия опе- рация и метод класса отождествляют. Однако эти понятия в UML раз- личаются. Операция – это сервис. Который может быть запрошен у лю- бого объекта класса для реализации поведения, а метод – реализация

225 операции [6]. Каждой неабстрактной операции класса должен быть со- поставлен метод, который содержит исполняемый алгоритм в виде тела класса.
Для именования операции рекомендуется использовать глаголы, со- ответствующие ожидаемому поведению объектов данного класса. Опи- сание операции имеет следующий вид:
< квантор видимости > < имя операции > (список параметров):
< выражение типа возвращаемого значения >{строка свойств}
Квантор видимости принимает такие же значения, как и в случае ат- рибутов класса, и может быть опущен. Вместо условных графических обозначений можно записывать соответствующее ключевое слово (pub- lic, protected, private).
Имя операции (обязательный элемент) – это строка текста, которая используется как идентификатор операции и которая должна быть уни- кальной в пределах данного класса.
Список параметров представляет собой перечень формальных пара- метров, разделенных запятыми. Каждый параметр представляется в сле- дующем виде:
< направление > < имя параметра > : < выражение типа> =
< значение параметра по умолчанию > .
Направление может принимать одно из следующих значений: in – входной параметр, который не может быть модифицирован; out – выходной параметр, который может быть модифицирован для передачи информации вызывающему коду; inout – входной параметр, который может быть модифицирован для передачи информации вызывающему коду.
Выражение типа зависит от конкретного языка программирования и описывает тип возвращаемого значения для соответствующего фор- мального параметра. Значение по умолчанию в общем случае представ- ляет собой выражение для значения формального параметра.
Выражение типа возвращаемого значения также зависимо от языка реализации спецификаций типа или типов значений параметров, кото- рые возвращаются объектом после выполнения соответствующей опе- рации. Операция может не возвращать никакого значения.
Строка свойств служит для определения значений свойств опера- ции. Она может отсутствовать, если никакие свойства не специфициро- ваны. Операция, которая не может изменять наблюдаемое состояние класса, обозначается строкой-свойством {запрос} (query). Наблюдае- мым состоянием объекта является состояние, которое можно опреде- лить посредством связанных с ним запросов. Ряд свойств операции предназначены для поддержки семантики параллелизма операций. К ним относятся: sequential (последовательная), guarded (защищенная) и concurrent (параллельная). Эти свойства существенны только в присут- ствии активных объектов, процессов или потоков. Если какая-либо опе- рация в некотором классе не выполняется, она может быть помечена как
абстрактная {abstract}.

226
Классы – наиболее важные строительные блоки любой объектно- ориентированной системы. Однако они представляют лишь одну разно- видность более общих строительных блоков UML – классификаторов.
Классификатор – это механизм, описывающий структурные и поведен- ческие свойства. UML предоставляет множество других немаловажных для моделирования классификаторов [6]: интерфейс – набор операций, используемых для спецификации сер- виса класса или компонента; тип данных – тип, значение которого неизменны. Примеры: прими- тивные встроенные типы (числа, строки и др.), типы перечислений и др.; ассоциация – описание набора ссылок, каждая из которых соединяет ряд объектов; сигнал – спецификация асинхронного сообщения, передаваемого между экземплярами объектов; компонент – модульная часть системы, скрывающая свою реализа- цию за набором внешних интерфейсов; узел – физический элемент, существующий во время исполнения и представляющий вычислительный ресурс, который обычно наделен некоторой памятью и частично вычислительными возможностями; вариант использования – описание последовательности действий, осуществляемых системой и порождающих значимый результат для определенного действующего лица; подсистема – компонент, представляющий одну из главных частей системы.
Графически UML представляет эти виды классификаторов, как пока- зано на рис. 5.25.
Рис. 5.25. Классификаторы UML
Язык UML предлагает использовать три уровня диаграмм классов в зависимости от степени их детализации:

227 концептуальный уровень, на котором диаграммы классов отобража- ют связи между основными понятиями предметной области. Эти по- нятия будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. На самом деле концепту- альная модель может иметь весьма слабое отношение к реализую- щему ее программному обеспечению, поэтому ее можно рассматри- вать как независимую от средств реализации (языка программирова- ния); уровень спецификаций, на котором диаграммы классов отображают связи объектов этих классов, но рассматриваются только интерфей- сы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне); уровень реализации, на котором диаграммы классов непосредствен- но показывают поля и операции конкретных классов.
Каждую из перечисленных моделей используют на конкретном этапе разработки программных систем: концептуальную модель на – этапе анализа; диаграммы классов уровня спецификации – на этапе проектирова- ния; диаграммы классов уровня реализации – на этапе реализации.
Диаграмма классов может отражать различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы от- ношений. Диаграммы классов обычно содержат следующие сущности: классы; интерфейсы; кооперации; отношения зависимости, обобщения и ассоциации.
В UML способы соединения сущностей друг с другом, логические либо физические, моделируются связями (рис. 5.26). В объектно- ориентированном моделировании существует три типа наиболее важ- ных связей: зависимости, обобщения и ассоциации [6].
1. Зависимость представляет собой связь использования. Это связь, которая устанавливает, что одна сущность, например класс Window
(Окно), использует информацию и сервис (операцию или услугу), пре- доставляемые другой сущностью, например классом Event (Событие), но необязательно – наоборот. Зависимость изображается пунктирной линией со стрелкой, направленной на зависимую сущность. Чаще всего зависимость используется для того, чтобы показать, что один класс ис- пользует операции другого класса.
2. Ассоциация – это структурная связь между экземплярами. Она по- казывает, что объекты одной сущности соединяются с объектами дру- гой. Ассоциация изображается сплошной линией. Допустимо, чтобы оба конца ассоциации соединяли один и тот же класс – иными словами один объект класса может связываться с другим объектом того же клас- са. Обычно ассоциация бинарна, т.е. связывает два класса, но бывают и
n-арные ассоциации. Класс, участвующий в ассоциации, выполняет