И. Соммервилл - Инженерия программного обеспечения (1133538), страница 41
Текст из файла (страница 41)
Каждая метка имеет атрибуты имя, пиктограмма и тенг. Подобно всем графическим моделям, модели "сущность-СВЯЗЬ-атрибуг" недостаточно детализированы, поэтому они обычно дополняются более подробным описанием объектов, свлзей и атрибугов, включенных в модель. Эти описания собираются в словари данных или репознтории.
Словари данных необкодимы при рюработке моделей системы и могут использоваться для управления информацией, содержащейся во всех моделях системы. Упрощенно словарь данных — зто просго алфавитный список имен, которые включены в различные модели системы. Вместе с именем словарь должен содержать описание именован. ного объекта, а если имя соответствует сложному объещу, может быть представлено описание построения этого объекта. Другая информация, например дата создания или фамилия раэра; ботчика, может приводиться в зависимосги от типа разрабатываемой модели, Перечислим преимущества использованил словаря данных.
1. Существует механизм управления именами. При разработке большой системной модели, вероятно, придется изобретать имена для сущностей н связей. Эти имена должны быть уникальными. Програима словаря данных может проверять уникальность имен и сообщать об их дублировании. 2. Словарь может служить хранилищем организационной информации, которая мо. жег связать анализ, проектирование, реализацию и модернизацию системы. Вся информация о системных объектах и сущностях находится в однои месте.
Все илгена, используемые в системе (имена сущностей, типов, связей, атрибутов и системных сервисов), должны быть введены в словарь дэннык. Программные средства слова- 160 Часть П. Требования ря должны обеспечить создание новых записей, их хранение и запросы к словарю. Такое программное обеспечение может быль интегрировано с другиии программными средст. вами. Большинство САБЕшредств, которые применяются для моделирования систем, мо~уг поддерживать словари данных. В примере словаря данных, приведенном в табл. 7.2, представлены имена, взятые из модели данных системы проектирования (см. рис.
7.7). Это упрощенный пример, где опущены некоторые имена и сокращена соответствующая информация. Таблица 7.2. Пример словаря данпых Имя Описание Тип Дата Отношение 1:Х между сущностями типа Узел или Связь и сущностями типа Метка' Содержит информацию об узлах и связях. Метки представляются пиктограммами и соответствую- щим текстом Отношение 1:1 между сущностями, представлен- ныии узлами.
Связи имеют тип и имя Каждая метка имеет имя, которое должно быть уникальным Каждый узел имеет имя, которое должно быть уни- кальнымм. Имя может содержать до 64 символов Связь 5.10.1998 имеет метки Метка Сущность 8.12.1998 Связь Связь 8.12.1998 Атрибут 8.12.1998 Атрнбуг 5.11.1998 имя (метка) нмя (узел) 7.4. Объектные модели Отнтеение йлт- ото етеунивение от отноитнне один «онноеин'. Аналогично "отношение ПУ" (сн.
до ет е теленке) — "отношение единя одному . - Принс ред. Объектно. ориентированный подход широко используется при разработке программного обеспечения, особенно для разработки интерактивных систем, В этом случае системные требования формируются иа основе объектной модели, а программирование выполняется с помощью объектно. ориентированных языков, таких, как )ага или С++. Объектные модели, разработанные для формирования требований, мо~ут нспользо.
ваться как для представления данных„так и для процессов их обработки. В этом отношении они объединяют модели потоков данных и семантические модели данных. Они также полезны для хиассификации системных сущностей и моПт представлять сущности, со. стоящие из других сущностей. Для некоторых классов систем объектные модели -естественный способ отображения реально существующих объектов, которые находятся под управлением системы. Например, для систем, обрабатывающих информацию относительно конкретных объектов (таких, как автомобили, самолеты, книги и т.д.), которые имеют четко определенные атриб)ты. Более абстрактные высокоуровневые сущности, например библиотеки, медицинские регистрирующие системы или текстовые редакторы, труднее моделировать в виде классов объектов, поскольку они имеют достаточно сложный интерфейс, состоящий из независимых атрибугов и методов.
Объектные модели, разработанные во время анализа требований. несомненно, упро. шают переход к объектно-ориентированному проектированию и программированию. Однако конечные пользователи часто считают объектные модели неестественными и трудными для понимания. Часто они предпочитают функциональные представления процес- 7. Модели систем 161 сов обработки данных. Поэтому полезно дополнить их моделями потоков данных, чтобы показать сквозную обработку данных в системе. Класс объектов — это абстракция множества объектов, которые определяются общими атрибутами (как в семантической модели данных) и сервисами или операциями, которые обеспечиваются каждым объектом. Объекты — это исполняемые сущности с атрибутами и сервисами класса объектов.
Объекты представляют собой реализацию класса, на основе одного класса можно создать много различных объектов. Обычно при разработке объектных моделей основное внимание сосредоточено на классах объектов и их отношениях. Модели систем, разрабатываемые при формировании требований, должны отображать реальные сущности, принадлежащие кзассам объектов. Классы не должны содержать информацию об отдельных системных объектах. Можно разработать различные типы объектных моделей, показывающие, как кзассы связаны друг с другом, как объекты агрегируются из других объектов, как объекты взаимодействуют с другими объектами и т.д. Зги модели расширяют понимание разрабатываемой системы.
Идентификация объектов и классов объектов считается наиболее сложной задачей в про. цессе объектно-ориентированной разработки систем. Определение объектов — это основа для анализа и проектирования системы. Методы определения объектов описаны в главе 12. Здесь рассматриваются лишь некоторые объектные модели, полезные для анализа систем. Рис 7.8. Уисзгь иералкии кллшм бал бийиоэичиэй аюнемм Различные методы объектно. ориентированного анализа были предложены в 1990-х годах Бучем (Воос)ь [54)), Кодом и Джордоном (Соаб апг) гопгбоп, [74]), а также Рамбо 162 ь1асть 11. Требовании (КпгоЬац8Ь, (302]).
Этн методы имели много общего, поэтому три главных разработчика — Буч, Рамбо и Якобсон ()асоЬзоп) — решили интегрировать их для разработки унифи. цироаанного метода (304). В результате разработанный ими унифицированный язык моделирования (()шйед Моде)(пб Еапбцабе — () М(.) стал фактическим стандартом для моде. лирования объектов.
()М(. предлагает нотации для различных типов системных моделей. Вы уже видели модели вариантов использования и диаграммы последовательностей в главе 5, а также диаграммы состояний ранее в этой главе. В ОМ(. класс объектов представлен вертикально ориентированным прямоугольником с тремя секциями (рис. 7.8). 1. В верхней секции располагается имя класса. 2. Атрибуты класса находлтся а средней секции. 8. Операции, связанные с классом, приводятся в нижней секции прямоугольника. Поскольку полностью описать 1.1М1.
в данной книге нет возможности, здесь на объектных моделях будет показано, как классифицируются объекты, как наследуются атрибуты и операции от лругих объектов, а также будут приведены модели агрегирования и простые поведенческие модели. 7.4.1. Модели наследования Важным этапом объекпго.ориентированного моделирования является определение каассов объектов, которые затем систематизируются. Это подразумевает создание схемы классификации, которая показывает, как классы объектов связаны друг с другом посредством общих атрибутов и сервисов. Схема классификации организована в виде иерархии наследования, на вершине которой представлены наиболее общИе классы объектов.
Более специализированные объекты наследуют нх атрибугы и сервисы. Эти объекты могут иисть собственные атрибуты и сервисы. На рис. 7.8 показана часть упрощенной иерархии классов для модели библиотечной системы. Эта иерархия дает информацию о библиотечных элементах. Библиотека содержит различные типы элементов: книги, музыкальные записи, фильмы, журналы, газеты и т.д. На рис. 7.8 наиболее общий элемент расположен на вершине иерархического дерева и имеет агрибугы и сервисы, общие для всех библиотечных элементов. Они наследуются классами Печатное издание и Элемент записи, имеющими собственные атрибуты, которые затем наследуются элементами более низкого уровня. На рнс.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
