Лабораторная работа №1. Методические рекомендации по выполнению лабораторной работы 2 Персональный компьютер ibm pc 3 Последовательность выполнения работы
 Скачать 183.86 Kb.
|
1 2 4.6 Операции В третьей сверху секции прямоугольника записываются операции или методы класса. Операция представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строка‑свойство данной операции: ‹квантор видимости›‹имя операции›(список параметров): ‹выражение типа возвращаемого значения›{строка‑свойство} Имя операции представляет собой строку текста, которая используется в качестве идентификатора соответствующей операции и поэтому должна быть уникальной в пределах данного класса. Имя атрибута является единственным обязательным элементом синтаксического обозначения операции. Список параметров является перечнем разделенных запятой формальных параметров, каждый из которых может быть представлен в следующем виде: ‹вид параметра›‹имя параметра›:‹выражение типа›=‹значение параметра по умолчанию›. Здесь вид параметра – есть одно из ключевых слов in, out или inout со значением in по умолчанию, в случае если вид параметра не указывается. Имя параметра есть идентификатор соответствующего формального параметра. Выражение типа является зависимой от конкретного языка программирования спецификацией типа возвращаемого значения для соответствующего формального параметра. Значение по умолчанию в общем случае представляет собой выражение для значения формального параметра, синтаксис которого зависит от конкретного языка программирования и подчиняется принятым в нем ограничениям. Выражение типа возвращаемого значения также является зависимой от языка реализации спецификацией типа или типов значений параметров, которые возвращаются объектом после выполнения соответствующей операции. Двоеточие и выражение типа возвращаемого значения могут быть опущены, если операция не возвращает никакого значения. Для указания кратности возвращаемого значения данная спецификация может быть записана в виде списка отдельных выражений. Строка‑свойство служит для указания значений свойств, которые могут быть применены к данному элементу. Строка‑свойство не является обязательной, она может отсутствовать, если никакие свойства не специфицированы. Операция с областью действия на весь класс показывается подчеркиванием имени и строки выражения типа. По умолчанию под областью операции понимается объект класса. В этом случае имя и строка выражения типа операции не подчеркиваются. Операция, которая не может изменять состояние системы и, соответственно, не имеет никакого побочного эффекта, обозначается строкой‑свойством «{запрос}». В противном случае операция может изменять состояние системы. Для повышения производительности системы одни операции могут выполняться параллельно или одновременно, а другие – только последовательно. В этом случае для указания параллельности выполнения операции используется строка‑свойство вида «{concurrency = имя}», где имя может принимать одно из следующих значений: последовательная (sequential), параллельная (concurrent), охраняемая (guarded). При этом придерживаются следующей семантики для данных значений: – последовательная (sequential) – для данной операции необходимо обеспечить ее единственное выполнение в системе, одновременное выполнение других операций может привести к ошибкам или нарушениям целостности объектов класса; – параллельная (concurrent) – данная операция в силу своих особенностей может выполняться параллельно с другими операциями в системе, при этом параллельность должна поддерживаться на уровне реализации модели; – охраняемая (guarded) – все обращения к данной операции должны быть строго упорядочены во времени с целью сохранения целостности объектов данного класса, при этом могут быть приняты дополнительные меры по контролю исключительных ситуаций на этапе ее выполнения. С целью сокращения обозначений допускается использование одного имени в качестве строки‑свойства для указания соответствующего значения параллельности. Отсутствие данной строки‑свойства означает, что семантика параллельности для операции не определена. Поэтому следует предположить худший с точки зрения производительности случай, когда данная операция требует последовательного выполнения. Появление сигнатуры операции на самом верхнем уровне объявляет эту операцию на весь класс, при этом данная операция наследуется всеми потомками данного класса. Если в некотором классе операция не выполняется (т. е. некоторый метод не применяется), то такая операция может быть помечена как абстрактная «{abstract}». Другой способ показать абстрактный характер операции – записать ее сигнатуру курсивом. Подчиненное появление записи данной операции без свойства {абстрактная} указывает на тот факт, что соответствующий класс‑потомок может выполнять данную операцию в качестве своего метода. Если для некоторой операции необходимо дополнительно указать особенности ее реализации (например, алгоритм), то это может быть сделано в форме примечания, записанного в виде текста, который присоединяется к записи операции в соответствующей секции класса. Если объекты класса принимают и реагируют на некоторый сигнал, то запись данной операции помечается ключевым словом «сигнал» («signal»). Это обозначение равнозначно обозначению некоторой операции. Реакция объекта на прием сигнала может быть показана в виде некоторого автомата. Кроме других случаев эта нотация может быть использована, чтобы показать реакцию объектов класса на ошибочные ситуации или исключения, которые могут моделироваться как сигналы или сообщения. Поведение операции может быть указано дополнительно в форме присоединенного к операции примечания. В этом случае текст примечания заключается в скобки, если он представляет собой формальную спецификацию на некотором языке программирования и соответствует элементу «семантическое ограничение языка UML». В противном случае текст примечания является простым описанием на естественном языке и обозначается прямоугольником с «загнутым» верхним правым уголком. Список формальных параметров и тип возвращаемого значения могут не указываться. Квантор видимости атрибутов и операций может быть указан в виде специального значка или символа, которые используются для графического представления моделей в некотором инструментальном средстве. Имена операций, так же как и атрибутов, записываются со строчной (малой) буквы, а их типы – с заглавной (большой) буквы. При этом обязательной частью строки записи операции является наличие имени операции и круглых скобок. В качестве примеров записи операций можно привести следующие обозначения отдельных операций: – +создать() – может обозначать абстрактную операцию по созданию отдельного объекта класса, которая является общедоступной и не содержит формальных параметров. Эта операция не возвращает никакого значения после своего выполнения; – запросить_счет_клиента(номер_счета:integer):Currency – обозначает операцию по установлению наличия средств на текущем счете клиента банка. При этом аргументом данной операции является номер счета клиента, который записывается в виде целого числа (например, «123456»). Результатом выполнения этой операции является некоторое число, записанное в принятом денежном формате (например, $1,500.00); – выдать_сообщение():{"Ошибка деления на ноль"} – смысл данной операции не требует пояснения, поскольку содержится в строке‑свойстве операции. Данное сообщение может появиться на экране монитора в случае попытки деления некоторого числа на ноль, что недопустимо. 4.7 Отношения между классами Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами. Базовыми отношениями или связями в языке UML являются: Отношение зависимости. Отношение ассоциации. Отношение обобщения. Отношение реализации. Каждое из этих отношений имеет собственное графическое представление на диаграмме, которое отражает взаимосвязи между объектами соответствующих классов. Отношение зависимости в общем случае указывает некоторое семантическое отношение между двумя элементами модели или двумя множествами таких элементов, которое не является отношением ассоциации, обобщения или реализации. Оно касается только самих элементов модели и не требует множества отдельных примеров для пояснения своего смысла. Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели. Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой на одном из ее концов («‑›» или «‹‑»). На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса‑клиента зависимости к независимому классу или классу‑источнику (см. рисунок 3). На данном рисунке изображены два класса: Класс_А и Класс_Б, при этом Класс_Б является источником некоторой зависимости, а Класс_А – клиентом этой зависимости.  Рисунок 3 – Графическое изображение отношения зависимости на диаграмме классов В качестве класса‑клиента и класса‑источника зависимости могут выступать целые множества элементов модели. В этом случае одна линия со стрелкой, выходящая от источника зависимости, расщепляется в некоторой точке на несколько отдельных линий, каждая из которых имеет отдельную стрелку для класса‑клиента. Например, если функционирование Класса_С зависит от особенностей реализации Класса_А и Класса_В, то данная зависимость может быть изображена следующим образом (см. рисунок 4).  Рисунок 4 – Графическое представление зависимости между классом‑клиентом и классами‑источниками Стрелка может помечаться необязательным, но стандартным ключевым словом в кавычках и необязательным индивидуальным именем. Для отношения зависимости предопределены ключевые слова, которые обозначают некоторые специальные виды зависимостей. Эти ключевые слова (стереотипы) записываются в кавычках рядом со стрелкой, которая соответствует данной зависимости. Примеры стереотипов для отношения зависимости представлены ниже: «access» – служит для обозначения доступности открытых атрибутов и операций класса‑источника для классов‑клиентов; «bind» – класс‑клиент может использовать некоторый шаблон для своей последующей параметризации; «derive» – атрибуты класса‑клиента могут быть вычислены по атрибутам класса‑источника; «import» – открытые атрибуты и операции класса‑источника становятся частью класса‑клиента, как если бы они были объявлены непосредственно в нем; «refine» – указывает, что класс‑клиент служит уточнением класса‑источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом. Отношение ассоциации соответствует наличию некоторого отношения между классами. Данное отношение обозначается сплошной линией с дополнительными специальными символами, которые характеризуют отдельные свойства конкретной ассоциации. В качестве дополнительных специальных символов могут использоваться имя ассоциации, а также имена и кратность классов‑ролей ассоциации. Имя ассоциации является необязательным элементом ее обозначения. Если оно задано, то записывается с заглавной (большой) буквы рядом с линией соответствующей ассоциации. Наиболее простой случай данного отношения – бинарная ассоциация. Она связывает в точности два класса и, как исключение, может связывать класс с самим собой. Для бинарной ассоциации на диаграмме может быть указан порядок следования классов с использованием треугольника в форме стрелки рядом с именем данной ассоциации. Направление этой стрелки указывает на порядок классов, один из которых является первым (со стороны треугольника), а другой – вторым (со стороны вершины треугольника). Отсутствие данной стрелки рядом с именем ассоциации означает, что порядок следования классов в рассматриваемом отношении не определен. В качестве простого примера отношения бинарной ассоциации рассмотрим отношение между двумя классами – классом «Компания» и классом «Сотрудник» (см. рисунок 5). Они связаны между собой бинарной ассоциацией Работа, имя которой указано на рисунке рядом с линией ассоциации. Для данного отношения определен порядок следования классов, первым из которых является класс «Сотрудник», а вторым – класс «Компания». Отдельным примером или экземпляром данного отношения может являться пара значений (Петров И. И., «Ремавт»). Это означает, что сотрудник Петров И. И. работает в компании «Ремавт».  Рисунок 5 – Графическое изображение отношения бинарной ассоциации между классами Тернарная ассоциация и ассоциации более высокой арности в общем случае называются N‑арной ассоциацией. Такая ассоциация связывает некоторым отношением 3 и более классов, при этом один класс может участвовать в ассоциации более чем один раз. Класс ассоциации имеет определенную роль в соответствующем отношении, что может быть явно указано на диаграмме. Каждый экземпляр N‑арной ассоциации представляет собой N‑арный кортеж значений объектов из соответствующих классов. Бинарная ассоциация является частным случаем N‑арной ассоциации, когда значение N=2, и имеет свое собственное обозначение. N‑арная ассоциация графически обозначается ромбом, от которого ведут линии к символам классов данной ассоциации. В этом случае ромб соединяется с символами соответствующих классов сплошными линиями. Обычно линии проводятся от вершин ромба или от середины его сторон. Имя N‑арной ассоциации записывается рядом с ромбом соответствующей ассоциации. Некоторый класс может быть присоединен к ромбу пунктирной линией. Это означает, что данный класс обеспечивает поддержку свойств соответствующей N‑арной ассоциации, а сама N‑арная ассоциация имеет атрибуты, операции и/или ассоциации. Другими словами, такая ассоциация, в свою очередь, является классом с соответствующим обозначением в виде прямоугольника и является самостоятельным элементом языка UML – ассоциацией‑классом. N‑арная ассоциация не может содержать символ агрегации ни для какой из своих ролей. В качестве примера конкретной тернарной ассоциации рассмотрим отношение между тремя классами: «Футбольная команда», «Год» и «Игра». Данная ассоциация указывает на наличие отношения между этими тремя классами, которое может представлять информацию об играх футбольных команд в национальном чемпионате в течение нескольких последних лет (см. рисунок 6). Отдельный класс ассоциации имеет собственную роль в отношении. Эта роль может быть изображена графически на диаграмме классов. С этой целью в языке UML вводится в рассмотрение специальный элемент – конец ассоциации (Association End), который графически соответствует точке соединения линии ассоциации с отдельным классом. Конец ассоциации является частью ассоциации, но не класса. Каждая ассоциация имеет два или больше концов ассоциации. Наиболее важные свойства ассоциации указываются на диаграмме рядом с этими элементами ассоциации и должны перемешаться вместе с ними.  Рисунок 6 – Графическое изображение тернарной ассоциации между тремя классами Одним из таких дополнительных обозначений является имя роли отдельного класса, входящего в ассоциацию. Имя роли представляет собой строку текста рядом с концом ассоциации для соответствующего класса. Она указывает специфическую роль, которую играет класс, являющийся концом рассматриваемой ассоциации. Имя роли не является обязательным элементом обозначений и может отсутствовать на диаграмме. Следующий элемент обозначений – кратность отдельных классов, являющихся концами ассоциации. Кратность отдельного класса обозначается в виде интервала целых чисел, аналогично кратности атрибутов и операций классов. Интервал записывается рядом с концом ассоциации и для N‑арной ассоциации означает потенциальное число отдельных экземпляров или значений кортежей этой ассоциации, которые могут иметь место, когда остальные N‑1 экземпляров или значений классов фиксированы. Так, для рассмотренного ранее примера (см. рисунок 5) кратность «1» для класса «Компания» означает, что каждый сотрудник может работать только в одной компании. Кратность «1…*» для класса «Сотрудник» означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. Частным случаем отношения ассоциации является так называемая исключающая ассоциация (Xor‑association). Семантика данной ассоциации указывает на тот факт, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один ее экземпляр. На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации, рядом с которой записывается строка‑ограничение «{хоr}» (см. рисунок 7).  Рисунок 7 – Графическое изображение исключающей ассоциации между тремя классами Специальной формой или частным случаем отношения ассоциации является отношение агрегации, которое, в свою очередь, тоже имеет специальную форму – отношение композиции. Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. Данное отношение имеет фундаментальное значение для описания структуры сложных систем, поскольку применяется для представления системных взаимосвязей типа «часть‑целое». Раскрывая внутреннюю структуру системы, отношение агрегации показывает, из каких компонентов состоит система и как они связаны между собой. С точки зрения модели отдельные части системы могут выступать как в виде элементов, так и в виде подсистем, которые, в свою очередь, тоже могут образовывать составные компоненты или подсистемы. Это отношение по своей сути описывает декомпозицию или разбиение сложной системы на более простые составные части, которые также могут быть подвергнуты декомпозиции, если в этом возникнет необходимость в последующем. Очевидно, что рассматриваемое в таком аспекте деление системы на составные части представляет собой некоторую иерархию ее компонентов, однако данная иерархия принципиально отличается от иерархии, порождаемой отношением обобщения. Отличие заключается в том, что части системы никак не обязаны наследовать ее свойства и поведение, поскольку являются вполне самостоятельными сущностями. Более того, части целого обладают своими собственными атрибутами и операциями, которые существенно отличаются от атрибутов и операций целого. В качестве примера отношения агрегации рассмотрим взаимосвязь типа «часть‑целое», которая имеет место между сущностью «Грузовой автомобиль» и такими компонентами, как «Двигатель», «Шасси», «Кабина», «Кузов». Грузовой автомобиль состоит из двигателя, шасси, кабины и кузова. Именно это отношение между классом «Грузовой_автомобиль» и классами «Двигатель», «Шасси», «Кабина», «Кузов» описывает отношение агрегации. Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой незакрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой «целое». Остальные классы являются его «частями» (см. рисунок 8).  Рисунок 8 – Графическое изображение отношения агрегации в языке UML Отношение композиции, является частным случаем отношения агрегации. Это отношение служит для выделения специальной формы отношения «часть‑целое», при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части. Пример – окно интерфейса программы, которое может состоять из строки заголовка, кнопок управления размером, полос прокрутки, главного меню, рабочей области и строки состояния. Подобное окно представляет собой класс, а его компоненты являются как классами, так и атрибутами или свойствами окна. Последнее обстоятельство весьма характерно для отношения композиции, поскольку отражает различные способы представления данного отношения. Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой класс‑композицию или «целое». Остальные классы являются его «частями» (см. рисунок 9).  Рисунок 9 – Графическое изображение отношения композиции в языке UML В качестве дополнительных обозначений для отношений композиции и агрегации могут использоваться дополнительные обозначения, применяемые для отношения ассоциации. А именно, указание кратности класса ассоциации и имени данной ассоциации, которые не являются обязательными. Отношение обобщения является обычным таксономическим отношением между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком). Данное отношение может использоваться для представления взаимосвязей между пакетами, классами, вариантами использования и другими элементами языка UML. Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения. При этом предполагается, что класс‑потомок обладает всеми свойствами и поведением класса‑предка, а также имеет свои собственные свойства и поведение, которые отсутствуют у класса‑предка. На диаграммах отношение обобщения обозначается сплошной линией с треугольной стрелкой на одном из концов. Стрелка указывает на более общий класс (класс‑предок или суперкласс), а ее отсутствие – на более специальный класс (класс‑потомок или подкласс). Как правило, на диаграмме может указываться несколько линий для одного отношения обобщения, что отражает его таксономический характер. В этом случае более общий класс разбивается на подклассы одним отношением Обобщения. С целью упрощения обозначений на диаграмме классов совокупность линий, обозначающих одно и то же отношение обобщения, может быть объединена в одну линию. В этом случае данные отдельные линии изображаются сходящимися к единственной стрелке, имеющей с ними общую точку пересечения. Это обозначение по форме соответствует графу специального вида, а именно – иерархическому дереву. В этом случае класс‑предок является корнем этого дерева, а классы‑потомки – его листьями. Отличие заключается в возможности указания на диаграмме классов потенциальной возможности наличия других классов‑потомков, которые не включены в обозначения представленных на диаграмме классов (многоточие вместо прямоугольника). Рядом со стрелкой обобщения может размещаться строка текста, указывающая на некоторые дополнительные свойства этого отношения. Данный текст будет относиться ко всем линиям обобщения, которые идут к классам‑потомкам. Другими словами, отмеченное свойство касается всех подклассов данного отношения. При этом текст следует рассматривать как ограничение, и тогда он записывается в фигурных скобках. В качестве ограничений могут быть использованы следующие ключевые слова языка UML: {complete} – означает, что в данном отношении обобщения специфицированы все классы‑потомки, и других классов‑потомков у данного класса‑предка быть не может. Пример – класс Клиент_банка является предком для двух классов: Физическое_лицо и Компания, и других классов‑потомков он не имеет. На соответствующей диаграмме классов это можно указать явно, записав рядом с линией обобщения данную строку‑ограничение; {dispoint} – означает, что классы‑потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов. В приведенном выше примере это условие также выполняется, поскольку предполагается, что никакое конкретное физическое лицо не может являться одновременно и конкретной компанией. В этом случае рядом с линией обобщения можно записать данную строку‑ограничение; {incomplete} – означает случай, противоположный первому. А именно, предполагается, что на диаграмме указаны не все классы‑потомки. В последующем возможно восполнить их перечень не изменяя уже построенную диаграмму. Пример – диаграмма класса «Автомобиль», для которой указание всех без исключения моделей автомобилей соизмеримо с созданием соответствующего каталога. С другой стороны, для отдельной задачи, такой как разработка системы продажи автомобилей конкретных моделей, в этом нет необходимости. Но указать неполноту структуры классов‑потомков все же следует; {overlapping} – означает, что отдельные экземпляры классов‑потомков могут принадлежать одновременно нескольким классам. Пример – класс «Многоугольник» является классом‑предком для класса «Прямоугольник» и класса «Ромб». Однако существует отдельный класс «Квадрат», экземпляры которого одновременно являются объектами первых двух классов. Вполне естественно такую ситуацию указать явно с помощью данной строки‑ограничения. С учетом возможности использования строк‑ограничений диаграмма классов может быть изображена без многоточий и без потери информации. 4.8 Моделирование логической схемы базы данных Многие системы, которые нужно моделировать, будут иметь в своем составе сохраняемые объекты. Это значит, что они могут быть помещены в базу данных для последующего извлечения. Чаще всего используются для хранения реляционные и объектно-ориентированные базы данных либо гибридные объектно-реляционные базы. UML хорошо подходит для моделирования как логических, так и физических схем баз данных. Диаграммы классов UML представляют собой надмножество диаграмм «сущность-связь» (entity-relationship, E-R) - общего инструмента моделирования, используемого в логическом проектировании баз данных. В то время как классические E-R диаграммы сосредоточены только на данных, диаграммы классов идут на шаг вперед, позволяя также моделировать поведение. В физической базе данных эти логические операции обычно представлены в виде триггеров и хранимых процедур. Чтобы смоделировать схему, необходимо: Идентифицировать те классы в модели, состояние которых не должно быть зависимым от времени жизни работающего приложения. Создать диаграмму классов, содержащую классы, выявленные на первом этапе. Можно определить собственный набор стереотипов и помеченных значений, чтобы представить специфичные для базы данных детали. Раскрыть структурные подробности этих классов. В основном это означает необходимость подробно специфицировать их атрибуты, а также ассоциации с указанием множественности, которые связывают данные классы. Выявить общие образцы, которые усложняют физическое проектирование базы данных, например циклические ассоциации и ассоциации «один-к-одному». При необходимости создать промежуточные абстракции для упрощения логической структуры. Рассмотреть поведение классов, отмеченных на первом этапе, раскрыв операции, существенные для доступа к данным и обеспечения их целостности. Вообще, чтобы четче разграничить различные аспекты системы, следует инкапсулировать бизнес-правила, описывающие манипуляции наборами этих объектов, в слое, находящемся над данными устойчивыми классами. Там, где возможно, использовать инструментальные средства, которые помогут трансформировать логический дизайн в физический. На рисунке 10 показан набор классов, описывающих информационную систему учебного заведения. Этот рисунок развивает диаграмму классов и показывает детали классов, существенных для конструирования физической схемы базы данных. Начиная с нижнего левого угла диаграммы, находятся классы Student (Студент), Course (Курс) и Instructor (Преподаватель). Существует ассоциация между Student и Course, указывающая, что студенты посещают курсы. Более того, каждый студент может выбирать неограниченное число курсов; каждый курс может посещать множество студентов. Эта диаграмма раскрывает атрибуты всех шести классов. Отметим, что все атрибуты - примитивных типов. Когда моделируется схема базы, обычно связи с непримитивными типами моделируются в виде явных ассоциаций, а не атрибутов. Два класса - School (Учебное заведение) и Department (Факультет) - включают несколько операций, предназначенных для манипулирования их частями. Эти операции важны для поддержания целостности данных: например, добавление и удаление факультетов может повлечь за собой некоторые недоразумения. Есть много других операций, которые стоит рассмотреть для этих и других классов (скажем, запрос определенной информации перед записью студента на курс). Такие функции можно трактовать скорее как бизнес-правила, а не операции, призванные обеспечивать целостность данных, поэтому их лучше поместить на более высокий уровень абстракции.  Рисунок 10 – Моделирование схемы базы данных 4.8 Моделирование физической базы данных Логическая схема базы данных охватывает словарь хранимых данных системы вместе с семантикой их связей. Физически все эти сущности сохраняются в базе данных - либо в реляционной, либо в объектно-ориентированной, либо в гибридной (объектно-реляционной) - для последующего извлечения. UML так же хорошо приспособлен к моделированию физических баз данных, как и к моделированию их логических схем. Отображение логической схемы базы данных на объектно-ориентированную базу достаточно прямолинейно, поскольку даже сложные цепочки наследования могут быть сохранены без какого-либо преобразования. Однако отобразить логическую схему на реляционную базу не так просто. Если имеет место наследование, приходится принимать решения относительно того, как отображать классы на таблицы. Обычно применяется либо одна из трех ниженазванных стратегий, либо их комбинация: Спуск (push down) - определяется отдельная таблица для каждого класса. Это простой, но примитивный подход, поскольку он вызывает проблемы сопровождения при добавлении новых дочерних классов или модификации существующих родительских; Подъем (pull up) - все цепочки наследования свертываются так, что реализации любого класса в иерархии имеют одинаковое состояние. Недостаток в том, что во многих экземплярах приходится хранить избыточную информацию; Расщепление таблиц (split tables) - данные родительского и дочернего класса разносятся по разным таблицам. Такой подход лучше отображает структуру наследования, но его недостаток состоит в том, что для доступа к данным приходится соединять многие таблицы. Проектируя физическую базу данных, необходимо также решить, как следует отображать операции, определенные в логической схеме. Объектно-ориентированные базы данных обеспечивают достаточно прозрачное отображение, но что касается реляционных, здесь приходится решать, как реализовать эти логические операции. Опять же, существует несколько вариантов: Простые операции создания, выборки, обновления и удаления реализуются стандартными вызовами SQL или ODBC. Более сложное поведение (такое как бизнес-правила) отображается на триггеры и хранимые процедуры. С учетом приведенных соображений для моделирования физической базы данных необходимо: Идентифицировать присутствующие в модели классы, которые представляют логическую схему базы данных. Выбрать стратегию отображения этих классов на таблицы. Следует рассмотреть и физическое распределение баз данных. Необходимо проанализировать физическое размещение данных в системе - от этого тоже зависит выбор стратегии. Создать диаграмму артефактов для визуализации, специфицирования, конструирования и документирования отображения, в которой артефакты имеют стереотип таблицы. По возможности использовать инструментальные средства для преобразования логической схемы в физическую. На рисунке 11 показан набор таблиц базы данных, взятых из информационной системы учебного заведения. Вы видите одну базу -school.db, изображенную в виде артефакта со стереотипом database.  Рисунок 11 – Моделирование физической базы данных Она состоит из пяти таблиц: student (студент), class (класс), instructor (инструктор), department (отдел) и course (курс). В соответствующей логической схеме базы данных нет наследования, поэтому отобразить ее на физическую несложно. Хотя в данном примере это не показано, вы можете специфицировать содержимое каждой таблицы. Артефакты могут иметь атрибуты, поэтому общая идиома при моделировании физической базы данных заключается в использовании атрибутов для специфицирования столбцов каждой таблицы. Аналогичным образом артефакты могут иметь операции, которые позволяют отображать хранимые процедуры. 5 Индивидуальные задания 5.1 Создать в Enterprise Architect новый проект под именем Lab1. 5.2 Добавить в проект диаграмму классов. 5.3 Смоделировать логическую схему базы данных (диаграмму классов) в соответствии с вариантом (номер рабочего места). 5.4 Смоделировать физическую схему базы данных в соответствии с вариантом (номер рабочего места). Вариант 1 Разработать СУБД "Абитуриент" для автоматизации работы приемной комиссии ВУЗа. БД должна содержать три таблицы: анкеты абитуриентов, данные о дисциплинах и результаты экзаменов. Создать формы для ввода данных, запрос и отчет для результатов экзамена. Анкета включает следующие данные об абитуриенте: регистрационный номер (ключевое поле); фамилия, имя, отчество; дата рождения; наличие красного диплома или золотой/серебряной медали; адрес (город, улица, номер дома, телефон); Данные о дисциплинах содержат: шифр дисциплины (ключевое поле). название дисциплины; Результаты экзаменов содержат: регистрационный номер абитуриента; шифр дисциплины; экзаменационная оценка. Вариант 2 Разработать информационную подсистему "Зарплата" для автоматизации начисления почасовой заработной платы в бухгалтерии. База данных состоит из трех таблиц, содержащих сведения о работниках, ставки почасовой оплаты и табель отработанных часов. Создать формы для ввода данных, запрос и отчет для начисленной зарплаты. На каждого работника хранятся следующие данные: личный номер (ключевое поле); фамилия, имя, отчество; отдел; должность; разряд; Тарифная сетка для почасовой оплаты: должность (ключевое поле вместе с разрядом); разряд (от 7 до 15); ставка (руб/час). Табель содержит: личный номер; месяц; количество часов, отработанных за месяц. Вариант 3 Разработать информационную систему "Оптовая база". На оптовой базе хранятся товары, получаемые от поставщиков. Потребителями являются организации, предварительно направляющие на базу заявки на товар. Отдел снабжения базы ведет учет движения товаров. Создать формы для ввода данных, запрос и отчет для просмотра заявок. БД должна состоять из трех таблиц: "Склад", "Товары", "Заявки". Таблицы имеют следующую структуру: "Склад": код товара; количество; дата поступления. "Товары": код товара (ключевое поле); название товара; единица измерения; "Заявки": код заявки (ключевое поле); название организации; код товара; требуемое количество; Вариант 4 Разработать информационную систему "Потребительская корзина" для анализа уровня жизни в семье. Уровень жизни зависит от соотношения доходов семьи и цен на потребляемые продукты. Создать формы для ввода данных, запрос и отчет для потребления. БД системы содержит 3 таблицы: "Продукты", "Доходы" и "Потребление". Таблицы имеют следующую структуру: "Продукты": код продукта (ключевое поле); наименование; ед. измерения. "Доходы": год, месяц (ключевое поле); совокупный доход за месяц. "Потребление": год, месяц; код продукта; количество; цена. Вариант 5 Разработать информационную систему "Библиотека" для учета хранимой и выданной читателям литературы. Создать формы для ввода данных, запрос и отчет для просмотра выданных книг. БД системы состоит из трех таблиц со следующей структурой: "Книги": шифр книги (ключевое поле); автор; название; количество экземпляров. "Читатели": читательский билет (ключевое поле), фамилия и инициалы, отдел (адрес); "Выдача": шифр книги; читательский билет; количество экземпляров; дата выдачи; дата возвращения; Вариант 6 Разработать информационную систему "ГАИ" для учета нарушений правил дорожного движения водителями. Создать формы для ввода данных, запрос и отчет для просмотра сведений о нарушителях. БД системы состоит из трех таблиц: "Автомобили", "Водители" и "Сведения о нарушителях" со следующей структурой: "Автомобили": марка автомобиля; серия и номер технического паспорта (ключевое поле); государственный номер; номер двигателя; номер кузова; "Водители": фамилия, имя и отчество водителя; адрес; серия и номер водительского удостоверения (ключевое поле). "Сведения о нарушителях": серия и номер водительского удостоверения; гос. номер автомобиля; Нарушение; дата нарушения. Вариант 7 Разработать информационную систему "Старт" для подсчета результатов соревнований. Создать формы для ввода данных, запрос и отчет для просмотра финишных протоколов. База данных состоит из трех таблиц: "Участники": фамилия и инициалы; стартовый номер (ключевое поле); шифр группы (учитывающий пол и возраст); спортивная организация. "Протокол старта": стартовый номер; время старта; отметка о не выходе на старт. "Протокол финиша": стартовый номер; время финиша; отметка о сходе с дистанции. Вариант 8 Разработать информационную систему "Перевозки", для транспортного предприятия. На предприятии имеется пакет заявок от других организаций на перевозку различных грузов. Создать формы для ввода данных, запрос и отчет для просмотра доставок. БД системы состоит из трех таблиц: "Транспорт", "Заявки", "Доставка", имеющих следующую структуру: "Транспорт": марка автомобиля; государственный номер (ключевое поле); расход топлива (литров на 100 км.). "Заявки": код заявки (ключевое поле); дата; пункт отправления; пункт назначения; название груза; единица измерения; количество груза. "Доставка": дата отправления, дата возвращения, гос. номер автомобиля, код заявки, количество фактически перевезенного груза, пройденное расстояние. Вариант 9 Разработать информационную систему "Сессия" для анализа успеваемости на факультете по конкретной специальности. Создать формы для ввода данных, запрос и отчет для просмотра результатов экзамена. БД системы состоит из трех таблиц: "Студенты", "Экзамены" и "Дисциплины" со следующей структурой: "Студенты": шифр студента (ключевое поле); фамилия, имя, отчество; курс; группа. "Экзамены": шифр студента; дата; шифр дисциплины; оценка. "Дисциплины": шифр дисциплины (ключевое поле); название дисциплины. Вариант 10 Разработать информационную систему "Учебная нагрузка" для учета нагрузки преподавателя ВУЗа и автоматизации отчета о выполнении нагрузки. Создать формы для ввода данных, запрос и отчет для просмотра выполнения нагрузки. БД системы состоит из 3 таблиц со следующей структурой. Таблица "Дисциплины": код дисциплины (ключевое поле); название дисциплины; курс; Таблица "Виды нагрузки" (лекции, лаб.работы, семинары, индивидуальная работа, зачеты, экзамены, прочее): Код занятия (ключевое поле); название нагрузки. Таблица "Выполнение нагрузки": дата; номер пары; номер группы (подгруппы); код дисциплины; название темы; код занятия; количество часов. 6 Содержание отчета (в рабочей тетради) 6.1 Номер варианта. 6.2 Результаты выполненной работы. 6.3 Ответы на контрольные вопросы. Контрольные вопросы Дайте определение диаграммы классов. Перечислите требования, предъявляемые к имени класса. Перечислите кванторы видимости. Перечислите виды отношений и представьте их графическое изображение. Объясните отличие изображения кратности отношений 1..* и 0..*. Список литературы1 Буч, Г. Язык UML. Руководство пользователя/ Г. Буч, Д. Рамбо, А. Джеобсон. М., 2001, с. 120-130, 413-426 2 Леоненков, А.В. Самоучитель UML/ А.В. Леоненков. Санкт-Петербург, 2002, с. 167-210 1 2 |