Модификация модели приложения
Посмотрим, что произойдет, если мы изменим бизнес-правило, ограничивающее количество авторов у книги единственным автором, а вместо него сформулируем следующее бизнес-правило: «каждая книга может иметь несколько авторов». Для этого запустим редактор моделей, выберем роль byAuthor и установим для нее свойство Multiplicity равным «1..*» (рис. 19).
Далее удалим файл 1.xml из рабочей папки. Запустим приложение на выполнение. Опять добавим указанных авторов с помощью первого навигатора, а с помощью второго навигатора ? книгу «12 стульев». Кликнем дважды на названии книги и убедимся, что автоформа изменилась (рис. 20).
Теперь вместо одного окошка для имени автора, как на рис. 18, мы обнаружим форму, позволяющую назначать данной книге произвольное число авторов. Перетащим последовательно обоих авторов на автоформу ? и теперь у книги «12 стульев» имеются в наличии оба автора.
Только что мы с вами наблюдали на практике характерную и основную черту MDA-приложений, а именно: поведение MDA-приложения определяется не кодом приложения, а UML-моделью. Мы не исправили ни строчки кода (да и кода-то, строго говоря, нет, по крайней мере, написанного нами), но получили новую функциональность нашей программы. Почему? Потому что мы изменили модель приложения и этого оказалось вполне достаточно для изменения поведения приложения.
Продолжим изучение свойств созданного приложения. Добавим нового автора ? Драйзер. Добавим во вторую таблицу книги ? «Американская трагедия», «Гений», «Финансист». Кликнем дважды на имени автора Драйзер, откроем закладку writes на появившейся форме автора и перетащим с помощью мыши эти три книги из главной формы на форму автора (рис. 21).
Еще раз нужно напомнить, что при перетаскивании нужно помещать курсор не на название книги или автора, а на ячейку первого столбца, выделенную символами ромбика и стрелки, которые показывают текущее положение указателя.
А теперь, когда автору Драйзер мы присвоили три книги, с помощью первого навигатора удалим его. При этом возникнет окно с требованием подтверждения операции удаления, и после нашего подтверждения автор Драйзер исчезнет из списка авторов, а форма автора автоматически закроется. Но три книги, принадлежащие перу этого писателя, по-прежнему будут фигурировать в списке книг на главной форме. Получается, что автора нет, а его книги присутствуют, то есть налицо некоторое «нарушение целостности данных», как принято говорить при работе с СУБД.
Попробуем изменить ситуацию. Сформулируем измененное ранее бизнес-правило немного иначе: «каждая книга должна быть написана по крайней мере одним автором». Таким образом, мы говорим, что не должно существовать книг, у которых отсутствует хотя бы один автор.
Для реализации этого правила снова обратимся к нашей модели, выберем роль ассоциации writes и изменим значение параметра Delete Action с <Default> на Cascade (рис. 22).
Снова запустим наше приложение: добавим автора ? Драйзер, которого мы удалили в прошлый раз, назначим ему уже известным способом три книги ? «Американская трагедия», «Гений» и «Финансист». А теперь попытаемся снова удалить автора из главной формы и убедимся, что после его удаления из правого списка книг также исчезли и написанные им книги. Опять мы увидели, что изменение в модели приложения непосредственно сказывается на его поведении.
 |
|
