Диссертация (1145120), страница 58
Текст из файла (страница 58)
В то же время интерфейсытаких систем содержат десятки и сотни однотипных экранных форм, которыенепросто создавать и поддерживать. Real-IT позволяет здесь существенноснизить трудозатраты.Базовый RealГрафическиередакторыСредаЯдроДополнительныеприложенияРис. 5.35 Архитектура пакета RealРассмотрим примеры. Пусть в схеме данных приложения есть таблица«А», и для неё создаётся экранная форма для ввода/редактирования полей записей.
Эта форма называется карточкой — пример см. на рис. 5.36, а. Если утаблицы есть связь с множественностью противоположного конца большей,чем единица, то в карточке появляется список записей из другой таблицы,связанных с этой записью таблицы «А». Список может быть встроенным вкарточку и вынесенным. Пример вынесенного списка показан на рис. 5.36, в.362Связи «многие-ко-многим» между таблицами переходят в формыотношения.
Пусть у нас в модели данных есть несколько сущностей, связанных отношением «многие-ко-многим» арности n, где n >=2. Тогда часто возникает потребность предоставить интерфейс для добавления/удаления связейобъектов этих сущностей. Общий подход к построению соответствующейэкранной формы выглядит так. Выделяется две стороны: f-сторона (fixed) иe-сторона (editing). F-сторона позволяет зафиксировать n-1 объектов сущностей, связанных данным n-арным отношением «многие-ко-многим».
Eсторона — это объекты оставшейся сущности. Именно их можно добавлять/удалять в связь для зафиксированных n-1 объектов f-стороны. На объекты f-стороны могут быть наложены фильтры, которые представляются связными полями выбора (comboboxes). Объекты e-стороны представляются ввиде IndexUnit — списка с кнопками выбора (checkboxes) или двух списков скнопками перемещения, как показано на рис. 5.36, б.Рассмотрим пример, представленный на рис. 5.36, б. Cущность «District»связана отношением «многие-ко-многим» с сущностью «Street» — в одномрайоне может быть несколько улиц, а одна улица может пролегать через несколько районов. В поле «District» мы выбираем какой-то определённыйрайон, и в списке справа сразу под ним отображаются все улицы, которые внего входят. В списке слева показаны все возможные улицы (то есть все содержимое сущности «Street»), и из этого списка вправо можно что-то добавить. Из списка слева можно что-то удалить.
То есть имеются средства дляредактирования связей в рамках отношения «многие-ко-многим».Составной частью форм-отношений и списков является фильтр. Нарис. 5.36, б, поле выбора «District» является фильтром. Фильтр может бытьсложным — пример показан на рис. 5.36, в. Этот фильтр содержит целыйнабор полей выбора, часть из которых связаны друг с другом. Так, при выборе определённого района (поле выбора «District») в поле выбора «Street»363будут предложены для выбора только те улицы, которые связаны с этим районом, а не вообще все улицы города.бавРис.
5.36. Типы экранных форм Real-IT: а — карточка, б — формаотношение, в — списокВыше мы рассмотрели фильтр-представление, осуществляющий фильтрацию набора данных для их предъявления пользователю с последующим использованием в запросах к базе данных. Существует другой вид фильтра —фильтр ввода, который предназначен для ввода данных на основе уже существующих значений.
Он также состоит из полей выбора, и в зависимости отвыбора в одном поле в другом предлагаются определённые значения. Так, нарис. 5.36, а поля ввода «Distric» и «Street» составляют единый фильтр ввода,так как являются связными.Классическая схема данных, выполненная с помощью диаграмм сущность-связь или какой-либо их разновидности, оставляет неопределённымимного вариантов, которые на практике, в «живой» базе данных, должны быть364описаны более строго. Например, многие объекты не могут быть одновременно связаны всеми связями с другими объектами, как это следует из определения их сущностей.
Здесь можно использовать язык ограничений типаOCL, но последний имеет существенно больше возможностей, чем требуютсяв данном случае. Вместе с тем, хотелось бы иметь ограничения в доступном,наглядном и хорошо воспринимаемом виде. Было выбрано графическоепредставление. Рассмотрим пример.На рис. 5.37, а представлен фрагмент схемы данных для адреса сотрудникакомпании. Адрес включает два разных случая: (i) сотрудник проживает вбольшом городе, и его адрес содержит район этого города; (ii) сотрудникпроживает либо в маленьком городе, либо в сельской местности, и тогда район в адресе отсутствует.
Две этих ситуации изображены на рис. 5.37, б, в. Этирисунки являются диаграммами объектов UML и задают конфигурацию реальных записей и их связей в базе данных, в рамках которой определённаясвязь должна быть. Эта определяемая связь помечается словом «limited». Внашем примере такой связью является связь адреса и улицы. То есть для двухзаписей из таблиц «Address» и «Street» связь между ними реализуется, если вбазе данных есть одна из конфигураций записей, связанных между собой, какпоказано на рис. 5.37, б и в. В случае б связи между районом и адресом недолжно быть.
Если потребуется определить аналогичные ограничения дляотношениямеждурайономинаселённымпунктом(сущностями«CityDistrict» и «Settlement»), то нужно создать аналогичные диаграммы,определяющие контекст и альтернативы именно для этого отношения.365аAddressn1Settlementn0..1CityDistrict10..1nn1nnnStreetб:AddressAbsent:CityDistrictв:Settlement:AddressLimited:SettlementLimited:Street:CityDistrict:StreetРис. 5.37.
Пример ограничений в Real-IT: а — схема данных, б — ограничение 1 (городских районов нет), в —ограничение 2 (городские районы есть)Модель данных в Real-IT задаётся с помощью диаграмм классов UML,ограничения на эту модель определяются с помощью диаграмм объектов, наоснове специального языка ограничений [30]. Модель пользовательского интерфейса строится с помощью специальных программных инструментов,позволяющих задать, для каких таблиц нужны карточки, по каким связям создавать списки, а по каким — формы-отношения, а также задать различныепараметры этих экранных форм. Основываясь на этой информации, Real-ITавтоматически генерирует диаграммы классов UML, описывающие созданную модель интерфейса.
Первоначально в Real-IT не было диалоговых инструментов для создания этой модели, и пользователям предлагалось создавать её в UML-редакторе. Однако этот подход не оправдал себя на практике — пользователям было неудобно, процесс занимал много времени. Тогдаи были созданы соответствующие программные инструменты для упрощениязадания интерфейса.366Как уже указывалось выше, Real-IT является DSM-решением, использовавшим универсальный пакет моделирования Real. Решение активно создавалось и использовалось в течение 5 лет, и далее ещё в течение 6 лет использовалось в режиме сопровождения.
С его помощью было создано более десяти промышленных информационных систем.3675.7 Выводы1. Представленные примеры индустриальных проектов демонстрируютширокое применение DSM как в программной инженерии, так и в других областях, в частности, в бизнес-инжиниринге и образовании.2. Рассмотренный материал подтверждает исходный тезис методологиипредметно-ориентированногомоделирования — припрактическомприменении DSM важным является не только спецификация языка моделирования, но разработка решения в целом, включая программныйинструмент с удобным и адекватным функционалом, а также методприменения.3. Продемонстрировано использование различных DSM-платформ, включая общепризнанные средства, в частности GMF, менее традиционныесредства — Microsoft Visio, — а также стандартные средства моделирования (пакет ARIS).4.
Предложенная в методологии модель разработки DSM-решений апробирована при решении представленных задач. Модель показала своюэффективность — созданные с её помощью решения удовлетворилииндустриальным ограничениям (время разработки, финансовые ресурсы, команда).368ЗаключениеВ качестве итогов сформулируем результаты, достигнутые в ходевыполнения данного исследования.1. Предложена методология предметно-ориентированного моделирования,предназначеннаядляразработкиинструментованализаипроектирования программного обеспечения на основе визуальныхмоделей и предоставляющая средства для спецификации итоговойпоставкиописывающаяDSM-проекта,дополнительныефункциональные компоненты, не реализованные существующимитехническими средствами, включающая средства для создания процессаразработки и сопровождения DSM-решения, а также для анализарисков.2.
Разработан алгоритм слияния двух версий и-карт (mind maps) вконтексте групповой разработки требований к ПО (первичный сбор ианализтребований)средствамиИнтернетпослеобрываивосстановления сетевого соединения.3. Созданамодельv2v-трансформацийдляавтоматизированнойразработки диаграммных сервисов с целью решения проблем навигациии сопровождения больших моделей.4. Предложен метод контроля качества (корректности) предметноориентированныхспецификаций,включающийсредствадляавтоматизированного создания валидаторов спецификаций на основеOCL-ограничений.5. Предложена модель для проектирования и разработки продуктовсемейств программно-аппаратных систем, основанных на программныхконструкторах и конфигурировании ПО целевых продуктов с помощьюкомпоновкиаппаратнойориентированныйязыкчасти.THCLМодельвключает(TelecommunicationпредметноHardware369Configuration Language) и архитектуру технологии графическогопроектирования.6.
Создан метод FSS (Formal Services Specification), предназначенный дляанализаипроектированияпрограммныхсистем,реализующихэлектронный доступ к государственным и публичным услугам.7. Предложена модель КИТ-решения (Корпоративная ИТ-архитектура),предназначенная для разработки и сопровождения ИТ-архитектуркрупных компаний.8. Создан метод DocLine для разработки и сопровождения документацииПО на основе повторного использования. Предложен предметноориентированныйязыкDRL/GR(DocumentationReuseLanguage/Graphical Representation) для проектирования документациилинеек программных продуктов.Создан алгоритм обнаруженияповторов и рефакторинга документов на основе техники поиска клоновв ПО.В качестве рекомендаций для использования полученных результатов впромышленности, образовании и научных исследованиях укажем, чтопредложенная методология предметно-ориентированного моделирования(глава 2) является полноценным руководством для создания DSM-решенийразличной степени сложности — ИТ-решений, настроенных стандартныхпродуктов моделирования, а также методик, предназначенных для совсемнебольших применений предметно-ориентированных языков.В качестве дальнейших направлений исследований укажем следующее.1.