Файл: Технол_разраб_прогр_обесп_Гагарина_Кокарева.doc

1.1

Р1

Описания алгоритмов

Описание метода

Размер массива

Массив

Сортировка выбранным методом

Результат

3-5.6. Диаграммы сущность—связь

Базовыми понятиями ER-модели данных (ER — Entity-Relationship) являются сущность, атрибут и связь [55].

Первый вариант модели «сущность—связь» был предложен в 1976 г. Питером Пин-Шэн Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. Все варианты диаграмм «сущность—связь» исходят из одной идеи — рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов) и взаимосвязей между сущностями.

Поскольку нотация Баркера является наиболее распространенной, в дальнейшем будем придерживаться именно ее.

Основные понятия Е1*-диаграмм

Сущность — это класс однотипных объектов, информация о которых должна быть учтена в модели [55]. Сущность имеет наименование, выраженное существительным в единственном числе, и обозначается в виде прямоугольника с наименованием (рис. 3.31, а). Примерами сущностей могут быть такие классы объектов, как «Студент», «Сотрудник», «Товар».

Табельный номер

Фамилия

Имя

Отчество

Должность

Зарплата

Сотрудник

Табельный номер

Фамилия

Имя

Отчество

Должность

Зарплата

в

Рис 3.31. Обозначения сущности в нотации Баркера: а — без атрибутов; б — с указанием атрибутов; в — с ключевым атрибутом

Экземпляр сущности — это конкретный представитель данной сущности. Например, конкретный представитель сущности «Студент» — «Максимов». Причем сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности, для того чтобы различать экземпляры.

Атрибут сущности — это именованная характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с описательными оборотами или прилагательными). Примерами атрибутов сущности «Студент» могут быть такие атрибуты, как «Номер зачетной книжки», «Фамилия», «Имя», «Пол», «Возраст», «Средний балл» и т. п. Атрибуты изображаются в прямоугольнике, обозначающем сущность (рис. 3.31, б).

Ключ сущности — это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. При удалении любого атрибута из ключа нарушается его уникальность. Ключей у сущности может быть несколько. На диаграмме ключевые атрибуты отображаются подчеркиванием (рис. 3.31, в).

Связь — это отношение одной сущности к другой или к самой себе. Возможно по одной сущности находить другие, связанные с ней. Например, связи между сущностями могут выражаться следующими фразами — «СОТРУДНИК может иметь несколько ДЕТЕЙ», «СОТРУДНИК обязан числиться точно в одном ОТДЕЛЕ». Графически связь изображается линией, соединяющей две сущности (рис. 3.32).

Рис 3.32. Пример связи между сущностями

Каждая связь имеет одно или два наименования. Наименование обычно выражается неопределенной формой глагола: «Продавать», «Быть проданным» и т. п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.

Связь может иметь один из следующих типов — рис. 3.33.

Связь типа один-к-одному означает, что один экземпляр пер-^вой сущности связан точно с одним экземпляром второй сущно-

Один-к-одному

<

Один-ко-многим

> <

Много-ко-многим Рис. 3.33. Типы связей

сти. Такая связь чаще всего свидетельствует о том, что мы неправильно разделили одну сущность на две.

Связь типа один-ко-многим означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Это наиболее часто используемый тип связи. Пример такой связи приведен на рис. 3.32.

Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем такую связь необходимо заменить двумя связями типа один-ко-многим путем создания промежуточной сущности.

Каждая связь может иметь одну из двух модальностей связи (рис. 3.34).

Может Должен

Рис. 3.34. Модальности связей

Связь может иметь разную модальность с разных концов, как на рис. 3.32. Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на рис. 3.32 читается так:

слева направо: «Сотрудник может иметь несколько детей»;

справа налево: «Ребенок должен принадлежать точно одному сотруднику».

Пример разработки простой ЕР-диаграммы

Необходимо разработать информационную систему по заказу некоторой оптовой торговой фирмы, которая должна выполнять следующие действия:

• хранить информацию о покупателях;

• печатать накладные на отпущенные товары;

• следить за наличием товаров на складе.

Выделим все существительные в этих предложениях — это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):

• Покупатель — явный кандидат на сущность.

• Накладная — явный кандидат на сущность.

• Товар — явный кандидат на сущность

• (?) Склад — а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.

• (?)Наличие товара — это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями — «покупатели могут покупать много товаров» и «товары могут продаваться многим покупателям». Первый вариант диаграммы выглядит, как показано на рис. 3.35.

Покупатель

Покупать

Товар

Быть проданным

Рис. 3.35. Первый вариант ЕЯ-диаграммы

Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов. Причем каждый товар может храниться на нескольких складах и быть проданным с любого склада.

Куда поместить сущности «Накладная» и «Склад» и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями «Покупатель» и «Товар»? Покупатели покупают товары, получая при этом накладные, в которые внесены данные ⁰ количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана ^выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким по

Покупатель

Получать — -і і

I

Накладная

Содержать

Выписываться на

Товар

Выписываться со

Содержаться

Храниться на

Склад

Хранить

Рис. 3.36. Промежуточный вариант ЕЯ-диаграммы

Пора подумать об атрибутах сущностей. Беседуя с сотрудниками фирмы, мы выяснили следующее:

• каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты;

• каждый товар имеет наименование, цену, а также характеризуется единицами измерения;

• каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и на определенного покупателя;

• каждый склад имеет свое наименование.

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

• Юридическое лицо — термин риторический, мы не работаем с физическими лицами. Не обращаем внимания;

• Наименование покупателя — явная характеристика покупателя;

• Адрес — явная характеристика покупателя;

• Банковские реквизиты — явная характеристика покупателя;

• Наименование товара — явная характеристика товара;

• (?)Цена товара — похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?

• Единица измерения — явная характеристика товара;

• Номер накладной — явная уникальная характеристика накладной;

• Дата накладной — явная характеристика накладной;

• (?) Список товаров в накладной — список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность;

• (?)Количество товара в накладной — это явная характеристика, но характеристика чего? Это характеристика не просто «товара», а «товара в накладной»;

• (?)Цена товара в накладной — опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше — это одно и то же?

• Сумма накладной — явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную;

• Наименование склада — явная характеристика склада.

В ходе дополнительной беседы с менеджером удалось прояснить различные понятия цен. Оказалось, что каждый товар имеет некоторую текущую цену. Это цена, по которой товар продается в данный момент. Естественно, что эта цена может меняться со временем. Цена одного и того же товара в разных накладных, выписанных в разное время, может быть различной. Таким образом, имеется две цены — цена товара в накладной и текущая цена товара.

С возникающим понятием «Список товаров в накладной» все довольно ясно. Сущности «Накладная» и «Товар» связаны друг с другом отношением типа много-ко-многим. Такая связь, как мы отмечали ранее, должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность «Список товаров в накладной». Связь ее с сущностями «Накладная» и «Товар» характеризуется следующими фразами — «каждая накладная обязана иметь несколько записей из списка товаров в накладной», «каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную», «каждый товар может включаться в несколько записей из списка товаров в накладной», «каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром». Атрибуты «Количество товара в накладной» и «Цена товара в накладной» являются атрибутами сущности «Список товаров в накладной».

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

Теперь можно внести все это в диаграмму (рис. 3.37).

Покупатель

Номер покупателя Наименование покупателя Адрес

Банковские реквизиты

Получать

Товар

Номер товара Наименование товара Единица измерения Текущая цена

Выписываться на

Содержаться в

Накладная

Номер накладной Дата накладной Сумма накладной

Содержать

Связываться с

Выписывать

Накладная

Склад

Принадлежать

Количество товара Цена товара

Номер склада Наименование склада

Связываться с

Хранить

Товар на складе

< Количество товара на складе

Храниться на

Рис. 3.37. Окончательный вариант ЕЯ-диаграммы

3.6. Анализ требований и определение спецификаций при объектном подходе

При объектном подходе к программированию модели разрабатываемой системы основываются на предметах и явлениях окружающего мира.

Модель — упрощенное представление реальности. С точки зрения программирования модель — это чертеж системы. Моделирование необходимо для решения следующих задач [4]:

1. визуализации системы;

2. определения ее структуры и поведения;

3. получения шаблона, позволяющего затем сконструировать систему;

4. документирования принимаемых решений, используя полученные модели.

Для решения этих задач при описании поведения проектируемого программного обеспечения в настоящее время используется UML (Unified Modeling Language) — унифицированный язык моделирования.

3.6.1. Некоторые теоретические сведения о UML — унифицированном языке моделирования

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

Для создания моделей анализа и проектирования объектно-ориентированных программных систем используют языки визуального моделирования, самым популярным из которых на сегодняшний день является UML.

Спецификация разрабатываемого программного обеспечения при использовании UML объединяет несколько моделей: логическую, использования, реализации, процессов, развертывания [1].

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

Логическая модель описывает ключевые понятия моделируемого программного обеспечения (классы, интерфейсы и т. п.), ^т- е. средства, обеспечивающие его функциональность.

Модель реализации определяет реальную организацию про-, граммных модулей в среде разработки.

Модель процессов отображает организацию вычислений и позволяет оценить производительность, масштабируемость и надежность программного обеспечения.

И наконец, модель развертывания показывает, каким образом программные компоненты размещаются на конкретном оборудовании.

Все вместе указанные модели, каждая из которых характеризует определенную сторону проектируемого продукта, составляют относительно полную модель разрабатываемого программного обеспечения.

Всего иМЬ предлагает девять дополняющих друг друга диаграмм, входящих в различные модели:

• диаграммы вариантов использования;

• диаграммы классов;

• диаграммы пакетов;

• диаграммы последовательностей действий;

• диаграммы кооперации;

• диаграммы деятельностей;

• диаграммы состояний объектов;

• диаграммы компонентов;

• диаграммы размещения.

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

3-6-2, Определение прецедентов (вариантов использования)

Разработку спецификаций программного обеспечения начинают с анализа требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого программного обеспечения и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями.

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

В зависимости от цели выполнения конкретной задачи различают следующие варианты использования [1]:

• основные, обеспечивают выполнение функций проектируемой системы;

• вспомогательные, обеспечивают выполнение настроек системы и ее обслуживание;

• дополнительные, служат для удобства пользователя (реализуются в том случае, если не требуют серьезных затрат каких-либо ресурсов ни при разработке, ни при эксплуатации).

Пример 3.3. Анализ функциональных требований и пользователей системы тестирования (модуль обучающей системы).

Система тестирования прежде всего требуется следующим заинтересованным лицам:

• обучаемому (студенту);

• составителю тестов (преподавателю);

• преподавателю, принимающему экзамен;

• сотруднику деканата, осуществляющему контроль за успеваемостью;

• администратору сети и баз данных учебного учреждения. На начальном этапе создания системы мы можем ограничиться только двумя важными для нас ролями действующих лиц:

• студент (тестируемый);

• администратор (он же преподаватель, он же составитель тестов).

Соответственно основные прецеденты (варианты использования) для нашей системы следующие: Прецедент для студента:

• П1 — пройти тестирование.

Прецеденты для администратора:

• П2 — создать/изменить тест;

• ПЗ — просмотреть результаты тестирования;

• П4 — добавить/изменить пользователей и др.

Вариант использования можно описать кратко или подробно. Краткая форма описания содержит название варианта использования, его цель, действующих лиц, тип варианта использования (основной, второстепенный или дополнительный) и его краткое описание [1].

Краткое описание варианта использования для данного примера:

Подробное описание варианта использования Прохождение теста

в

Приведем диаграмму прецедентов для вышеописанного примера (рис. 3.39).

Естественно, все варианты использования определить, как правило, не удается: новые варианты фиксируют постоянно, даже в процессе эксплуатации. Но чем больше вариантов выявлено в процессе уточнения спецификаций, тем лучше, так как при этом получают более точную модель предметной области, что уменьшает вероятность ее пересмотра при добавлении функций.

3-6-3. Построение концептуальной модели предметной области

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

Центральное место в объектно-ориентированном подходе к проектированию программного обеспечения занимает разработка логической модели системы в виде диаграммы классов (class diagram) [1, 48].

UML предлагает использовать три уровня диаграмм классов в зависимости от степени их детализации:

• концептуальный уровень, на котором диаграммы классов отображают связи между основными понятиями предметной области;

• уровень спецификаций, на котором диаграммы классов отображают связи объектов этих классов;

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

Каждую из перечисленных моделей используют на конкретном этапе разработки программного обеспечения:

• концептуальную модель — на этапе анализа;

• диаграммы классов уровня спецификации — на этапе проектирования;

• диаграммы классов уровня реализации — на этапе реализации.

Диаграмма классов может отражать различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. Диаграммы классов обычно содержат следующие сущности:

• классы;

• интерфейсы;

• кооперации;

• отношения зависимости, обобщения и ассоциации.

Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы, поэтому диаграмму классов принято считать графическим представлением таких взаимосвязей логической модели системы, которые не зависят от времени [48].

Класс

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

Имя Класса

Имя Класса