Конспект лекций, страница 19

Указано, что для любого аэропорта таких авиалинийдолжно быть больше нуля, но меньше 500.Конструкция iterate позволяет описывать нестандартные операции над коллекциями.Запись: <коллекция>->iterate(<переменная1> : <тип>; <переменная2> : <тип> [= <нач. значение>] | <тело>)где <переменная1> – параметр итератора, <переменная2> – результат итератора, <тело> –OCL-выражение с <переменная1> и <переменная2>.Например, ограничение:context Airline inv: self.flights->select(maxNrPassengers > 150)->notEmptyидентично:context Airline inv: self.flights->iterate (f : Flight; answer : Set(Flight) = Set{ } |if f.maxNrPassengers > 150 then answer->including(f) else answer endif )->notEmptyПоясним второе OCL-выражение.

Для авиалинии будет собрана коллекция всех ее рейсови на этой коллекции будет запущен итератор. В начале работы результат итератораинициализируется пустым множеством. Затем для каждого рейса f из коллекции, одногоза другим, будет вычислено условное выражение, которое добавит в результат лишь терейсы, maxNrPassengers которых больше 150.В наследовании ограничений работает принцип подстановки Лисковой (Liskov’sSubstitution Principle): «Где может находиться экземпляр суперкласса, туда всегда можетбыть подставлен экземпляр его любого подкласса.» Это означает, что:• Инвариант суперкласса наследуется любым подклассом.• Подклассы могут усиливать инвариант.• Предусловие может быть ослаблено в подклассе.• Постусловие может быть усилено в подклассе.Если в ограничении требуется проверить, является ли экземпляр суперкласса такжеэкземпляром конкретного подкласса, то используют стандартную операцию ocllsTypeOf.Вспоминая пример, приведенный в начале лекции, мы можем описать следующие6ГрузовойРейсПассажирскийРейсограничения:context ГрузовойСамолет inv:Рейс->forAll(r | r.oclIsTypeOf(ГрузовойРейс))Рейсcontext ПассажирскийСамолет inv:Рейс->forAll(r | r.oclIsTypeOf(ПассажирскийРейс))0..*1Операция oclInState возвращает истину, еслиСамолетобъект находится в определенном состоянии.Пример:context Bottle inv:ГрузовойСамолетПассажирскийСамолетself.oclInState(closed) implies filled = #fullМы рассмотрели OCL применительно кBottlefilled : enum {empty, half, full}моделям (диаграммам) классов.

Он также можетиспользоваться на других диаграммах. Надиаграммах взаимодействия OCL применяют дляclosedopenзаписи сторожевых условий (от выполнениякоторых зависит, будет ли послано сообщение). На диаграммах деятельности OCLприменяют для описания деятельностей, узлов принятия решения, сторожевых условий напотоках.

На диаграммах состояний OCL используется для описания состояний исторожевых условий на переходах между состояниями.Подведем итоги.• OCL позволяет уточнять модель, формулировать запросы к модели, сохранять приэтом свободу реализации.• Пре- и постусловия OCL позволяют точнее описывать интерфейсы и компоненты.• Рекомендуется при использовании OCL писать простые ограничения, совместноиспользовать OCL и естественный язык, применять CASE-средства, поддерживающиеOCL (например, из состава Eclipse Model Develepment Tools или Dresden OCL Toolkit).Литература к лекции 81.

J.Warmer, A. Kleppe. Object Constraint Language, The: Getting Your Models Ready forMDA, Second Edition2. OCL portal http://www-st.inf.tu-dresden.de/ocl/3. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделированиеи разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Глава 3.4.

Дж. Арлоу, Ай. Нейштадт. UML 2 и унифицированный процесс, 2-е изд. – СПб.:Символ-Плюс, 2007. – Глава 25.7Лекция 9. Проектирование баз данныхПроектирование баз данных производится, если используется реляционная БД, приэтом устойчивые классы объектной модели отображаются в таблицы реляционной БД.Основные понятия реляционной модели:База данных – долговременное самодокументированное хранилище данных.Самодокументация = схема данных, хранящаяся в БД.Система управления базами данных (СУБД) – ПО доступа к данным. Обеспечивает:• защиту данных;• эффективность;• многопользовательский режим;• разделение данных между несколькими приложениями;• распределенность данных;• безопасность.Структура реляционных данных – совокупность таблиц.

В любой таблицефиксированное количество столбцов и произвольное – строк. Совокупность значенийячеек одной строки – запись.Оператор SQL – предложение SQL для манипуляции данными (выборка, изменение,добавление, удаление).Ограничения – условия, являющиеся частью схемы БД. Если какая-либо добавляемаязапись нарушает какое-то ограничение, то она не будет добавлена.Виды ограничений:Возможный ключ (потенциальный ключ) – сочетание столбцов, уникальноидентифицирующих каждую запись в таблице, такое что, все столбцы необходимы дляуникальной идентификации и ни в одном нет пустых значений.Основной (первичный) ключ – возможный ключ, который предпочтительнееиспользовать для работы с таблицей.

Есть у каждой таблицы.Внешний ключ – ссылка из другой таблицы на возможный ключ.Пример:persIDNameSurName addremployer1ВасяПупкин1000ЛондонcompIDcompNamecompAddr1000ОАО «МММ» МоскваПервичные ключи: persID в 1-ой таблице, compID – во 2-ой. Внешний ключ –столбец employer 1-ой таблицы.Для связанных таблиц актуальна поддержка ссылочной целостности. Ссылочнаяцелостность – это зависимость значений во внешнем ключе от значений в первичномключе связанной таблицы (например, при удалении записи о компании необходимо: либопроверить отсутствие связанных записей о сотрудниках и отменить удаление в случаеобнаружения таковых, либо каскадировать удаление, удаляя связанные записи осотрудниках, либо обнулить значения во внешнем ключе у связанных записей).Для обеспечения ссылочной целостности применяют триггеры – процедуры,описанные на языке SQL, которые автоматически запускаются при модификации таблиц,с которыми они связаны.

Триггеры не только обеспечивают целостность, с их помощьюудобно реализовывать и более сложные манипуляцию с данными (бизнес-логику).Триггеры являются частным случаем хранимых процедур. Хранимая процедура – это1процедура, работающая с таблицами, которая скомпилирована и хранится в виде кода вБД и может быть вызвана из клиентской программы. Хранимые процедуры выгоднееSQL-запросов, но они доступны всем приложениям, работающим с БД, что иногданежелательно.Реляционная схема данных и объектная модель оперируют разными понятиями, всвязи с чем необходима специальная работа по объектно-реляционному отображению.Отображение возможно в обе стороны: в прямую (от классов к таблицам) и в обратную(от таблиц к классам).

В лекции мы будем говорить о прямом отображении, но обратноеотображение подразумевается.Еще одно предваряющее замечание. Схема БД зависит не только от совокупностиустойчивых классов и связей между ними, но и от практических соображений. Например,может оказаться, что решение хранить все устойчивые объекты в одной «толстой»ненормализованной таблице, вполне себя оправдывает тем, что делает приемлемойскорость большинства запросов к БД. Описывая объектно-реляционное отображение, мыбудем рассматривать решения, тяготеющие к получению нормализованной БД.Переводить модель классов в схему БД предлагается в 3 этапа: отобразить классы втаблицы, отобразить ассоциации и отобразить связи обобщения.Отображение классов1. Каждый класс переводится в отдельную таблицу, атрибуты становятся столбцамитаблицы. Операции на структуру таблицы не влияют.

Они могут переводиться вхранимые процедуры, если мы ходим переложить часть работы по манипулированиюданными на СУБД.2. Уникальный идентификатор устойчивого класса превращается в первичный ключтаблицы. Если имеется несколько альтернативных уникальных идентификаторов,выбирается наиболее используемый.

Если в модели для устойчивого класса явно неуказан идентификатор, то в таблицу добавляется столбец ID – первичный ключ.Пример:КлиентимяадресIDклиента ИмяАдресgetName()getAdress()При отображении ассоциаций пытаются сэкономить и не создавать дополнительныетаблицы для хранения соединений между устойчивыми объектами за счет объединениянескольких таблиц в одну или добавления дополнительных столбцов в таблицы,порожденные классами, если семантика ассоциации позволяет.Отображение бинарных ассоциаций:ПерсонаимяфамилиядатаРожденияIDперсоныИмя ФамилияДатаРождения1Паспортномерсерия1 датаВыдачиместоВыдачиНомерПаспорта2Серия ПаспортаДатаВыдачиМестоВыдачи••«1 к 1му» – возможны различные решения, лучше создать общую таблицу для 2хклассов.

Столбцы – совокупность атрибутов. Первичный ключ – любой ID (первогоили второго класса). Достигается максимально возможная экономия: одна таблицапредставляет оба класса и ассоциацию между ними.«1 к 0..1» – внешний ключ добавляется к таблице необязательного класса.Паспортномерсерия0..1 датаВыдачиместоВыдачиПерсонаимяфамилия1датаРожденияIDперсоны1ИмяИванНомерПаспорта123456ФамилияИвановДатаРождения1.01.1990СерияПаспорта77ДатаВыдачи20.02.2008МестоВыдачиМоскваПерсонаID1Вообще говоря, можно было бы использовать тот же прием, что и в «1 к 1», нополучающаяся таблица будет «разреженной» – в некоторых записях будут пустые поля.Обратите внимание, что внешний ключ добавляется в таблицу, представляющуюнеобязательный класс, поскольку записей в ней будет меньше, чем в другой.• «0..1 к 0..1» – рекомендуется отдельная таблица для связи. Ее столбцы – внешниеключи для таблиц классов, связанных ассоциацией.