Добавлен: 25.10.2018
Просмотров: 4935
Скачиваний: 12
31
10. наследование с одной таблицей (single table inheritance) – представляет иерархию наследования
классов в виде одной таблицы, столбцы которой соответствуют всем полям классов, входящим в
иерархию;
11. наследование с таблицами для каждого класса (class table inheritance) – представляет иерар-
хию наследования классов, используя по одной таблице для каждого класса;
12. наследование с таблицами для каждого конкретного класса (concrete table inheritance) –
представляет иерархию наследования классов, используя по одной таблице для каждого конкрет-
ного класса этой иерархии;
13. преобразователи наследования (inheritance mappers) – структура, предназначенная для органи-
зации преобразователей, которые работают с иерархиями наследования.
4.8.3. Слой представления
Приступая к проектированию слоя представления ИС, в первую очередь, делается выбор типа
интерфейса между «толстым» и «тонким» клиентами. Толстый клиент позволяет обеспечить богатый
графический интерфейс и высокую скорость отклика системы, однако, требует дополнительных рас-
ходов по внедрению и сопровождению клиентской части системы. В этой связи, на первом этапе про-
ектирования слоя представления рассматривается возможность использования тонкого клиента и
только в случае неудовлетворения требований обращаются к модели толстого клиента. Как показы-
вает практика, при разработке корпоративных приложений возможностей тонкого клиента оказыва-
ется вполне достаточно для реализации всего комплекса требуемых функций. В этой связи ниже бу-
дут рассматриваться типовые паттерны слоя представления тонкого клиента.
Для разработки web-приложений наибольшее распространение получил шаблон «модель-
представление-контроллер» (Model View Controller - MVC) (см. рис. Л.1). Контроллер принимает
запрос, извлекает из него информацию и передает управление соответствующему объекту модели,
которая может быть представлена, например, в виде модели предметной области или сценария
транзакции. Модель обращается к источнику данных и выполняет действия, предусмотренные в
запросе. Затем управление возвращается контроллеру, который, анализируя полученный результат,
принимает решение о выборе варианта представления ответа и передает управление слою представ-
ления. Слой представления отображает результат обработки средствами графического интерфейса.
Как правило, взаимодействие контроллера и представления осуществляется не напрямую, а через тот
или иной объект HTTP-сеанса.
В большинстве случаев, для одной и той же модели создается несколько представлений, од-
нако при внесении изменений в модель эти изменения должны быть отражены во всех представлени-
ях, использующих модель. Решение этой задачи достигается за счет использования типовых решений
наблюдатель (observer) или слушатель (listener)
2
[62].
Для реализации представления в модели MVC используются три типовых решения:
1. представление по шаблону (template view) соответствует размещению в структуре web-
страницы специальных маркеров, указывающих на расположение динамического содержимого
(см. рис. 8).
вызывает
использует
Рис. 8. Пояснение структуры паттерна «представление по шаблону»
Многие инструментальные платформы (ASP, JSP, PHP) позволяют в текст web-страницы вне-
дрять программный код (скриптлет), написанный на том или ином языке сценариев. Однако ис-
пользование скриптлетов приводит к смешиванию слоев программной системы, вызывает дубли-
2
При использовании типовых решений «наблюдатель» или «слушатель» представление отслеживает измене-
ние модели и как только изменение происходит генерирует событие по которому все остальные представления
обновляют свое содержимое.
32
рование кода и затрудняет применение многих средств структурирования, поддерживаемых как
объектно-ориентированной, так и структурно-функциональной методологиями. В этой связи ис-
пользование представления по шаблону предполагает назначение каждой странице вспомога-
тельного объекта (helper object), который содержит в себе всю логику домена. При этом страница
лишь выполняет вызовы вспомогательного объекта.
Строгое разделение задач оформления страницы и проработки программной логики при ис-
пользовании представления по шаблону позволяет добиться полной независимости работы гра-
фических дизайнеров и программистов. Недостаток типового решения представление по шаб-
лону связан с тем, что его использование в большинстве случаев возможно исключительно со-
вместно с web-сервером, что затрудняет проведение тестирования. Этот недостаток исключен в
типовом решении «представление с преобразованием», которое может функционировать при
отсутствии запущенного web-сервера.
2. представление с преобразованием (transform view) предполагает использование специальной
программы (преобразователя), которая просматривает данные домена и преобразует их в код
HTML (рис. 9).
Рис. 9. Пояснение структуры паттерна «представление с преобразованием»
В настоящий момент наиболее популярным языком для написания представлений с преобразова-
нием является функциональный язык программирования XSLT. При этом данные домена должны
храниться в формате XML. Использование XSLT оказывается наиболее эффективным, когда тре-
буются частые (и глобальные) изменения внешнего вида web-сайта.
3. двухэтапное преобразование (two step view) предполагает использование двух стадий: вначале
на основе данных домена формируется логическая структура (включая поля ввода, верхние и
нижние колонтитулы, таблицы, переключатели и т.д.), которая затем трансформируется в код
HTML. Методам второго этапа известно, какие элементы входят в логическую структуру и как
визуализировать каждый из них. В этом случае, при необходимости, глобальные изменения
внешнего вида Web-сайта могут быть осуществлены только переработкой второго этапа преобра-
зования, что повышает эффективность данного типового решения с точки зрения удобства пере-
работки графического интерфейса.
В большинстве случаев двухэтапное преобразование используется для обеспечения доступа к
web-контенту с помощью разнообразных обозревателей или когда необходимо поддерживать не-
скольких вариантов внешнего вида одного web-сайта, например, стационарной и «мобильной»
версий.
Контроллер MVC-модели выполняет обработку и диспетчеризацию HTTP-запросов. Наи-
большее распространение получили два следующих типовых решения:
1. при использовании паттерна «контроллер страниц» (page controller) задачи обработки HTTP-
запросов и принятия решения о ее перенаправлении разделяются между собой. Функциями кон-
троллера страниц являются:
a. сбор сведений для выполнения запроса: анализ URL и извлечение данных, введенных
пользователем в соответствующие формы;
b. создание объектов модели и вызов их методов, необходимых для обработки данных.
При этом все необходимые данные должны быть переданы модели из HTTP-запроса;
c. определение представления, которое должно быть использовано для отображения ре-
зультатов и передача ему необходимой информации, полученной от модели.
Контроллер страниц может быть реализован в виде сценария (CGI, сервлета и т.п.) или страницы
сервера (ASP, PHP, JSP и т.п.). Использование страницы сервера обычно предполагает сочетание
в одном файле контроллера страниц и представления по шаблону.
Как правило, контроллер страниц применяется для сайтов с достаточно простой логикой
котроллера, поскольку предполагает наличие отдельного контроллера для каждой логической
страницы Web-сайта. Если сайт имеет сложную структуру, а также, если предъявляются специ-
альные требования к проверке безопасности, обеспечению интернационализации или открытию
33
специальных представлений для особых категорий пользователей, то использование котроллеров
страниц приводит к дублированию кода. Дублирование кода можно избежать двумя способами:
(i) посредством вынесения общей логики контроллеров в служебные классы, которые составят
супертип слоя
3
; (ii) посредством использования типового решения контроллер запросов.
2. контроллер запросов (front controller) предполагает использование единственного объекта,
предназначенного для обработки всех запросов, но включает в свой состав две части:
a. web-обработчик – объект, который выполняет фактическое получение POST- и GET-
запросов, поступивших на web-сервер. Он извлекает необходимую информацию из
URL и входных данных запроса, после чего решает, какое действие необходимо ини-
циировать, и делегирует его выполнение соответствующей команде.
b. иерархия команд из числа которых web-обработчиком статически или динамически
выбирается необходимая команда для обработки поступившего запроса. Статический
выбор команды подразумевает проведение синтаксического анализа адреса URL и
применение условной логики, а динамический – извлечение некоторого стандартного
фрагмента адреса URL и динамическое создание экземпляра класса команды.
Web-обработчик интерпретирует полученный адрес URL и создает отдельный объект для даль-
нейшего обслуживания запроса. Таким образом удается централизовать деятельность по обработ-
ке всех HTTP-запросов в рамках единого объекта и избежать необходимости изменения конфигу-
рации web-сервера в случае модификации функционала сайта.
Кроме того, контроллер запросов хорошо сочетается с типовым решением перехватываю-
щий фильтр, который представляет собой декоратор
4
, выступающий в роли оболочки web
-
обработчика котроллера запросов и позволяющий строить цепочки фильтров, предназначенные
для обработки таких процессов как: аутентификация, регистрация на сайте, выбор кодировки и
т.д. [74, 95].
Выбор типового решения для обеспечения взаимодействия «представление-контроллер» во
многом зависит от используемой инструментальной среды. В частности, при использовании Visual
Studio в большинстве случаев используется связка «контроллер страниц – представление по шаб-
лону», а при использовании среды Struts(Java) - «контроллер запросов – представление по шабло-
ну».
Контроллер страниц и контроллер запросов, получив название входных контроллеров, нахо-
дят применение при проектировании web-сайтов, состоящих из нескольких десятков страниц. Если
проектируемый сайт включает в состав 30 и более страниц логика выбора нужных экранов начинает
дублироваться в нескольких контроллерах, что крайне нежелательно. В таком случае помимо вход-
ных контроллеров создается дополнительный сервисный слой – контроллер приложения (applica-
tion controller).
Контролер приложения выполняет две основные функции: выбор логики домена, которую
нужно применить в конкретной ситуации, и выбор представления, которое следует отобразить в от-
вет на запрос. Для осуществления этих функций контроллер приложения должен поддерживать две
коллекции ссылок на классы: одну для команд, выполняющихся в слое домена, и одну для представ-
лений. В качестве команд домена могут выступать объекты команд, являющиеся частью слоя кон-
троллера приложения, либо ссылки на сценарий транзакции или методы объектов домена.
Если в качестве представлений используются страницы сервера, то для вызова представления
можно применить имя соответствующей страницы.
Подводя итог, остановимся на вопросе согласования рассмотренных выше типовых решений
между собой (рис. 10).
Проектирование архитектуры слоев ИС начинается с выбора паттерна слоя предметной об-
ласти, который определит типовое решение слоя источника данных. Как указывалось выше, шлюз
таблицы данных гармонично сочетается с модулем таблицы: методы шлюза таблицы данных
возвращают структуры данных в виде множества записей, которые затем обрабатываются модулем
таблицы. Вместе с тем, шлюз таблицы данных может успешно использоваться и со сценарием
транзакции. И в том и в другом случае выбор между шлюзом записи данных и шлюзом таблицы
данных зависит лишь от предъявляемых требований к форме возвращаемого результата: в виде от-
3
Супертип слоя (layer supertype) используется тогда, когда все объекты соответствующего слоя имеют неко-
торые общие свойства или поведение. В этом случае рекомендуется создать суперкласс для всех объектов слоя
и вынести в него все общие методы для того, чтобы не дублировать их в объектах слоя.
4
Декоратор – это паттерн, позволяющий динамически возлагать на объект новые функции.
34
дельной записи или в виде множества записей. Однако, при проектировании слоя предметной облас-
ти с использованием сценария транзакций может оказаться, что в различных сценариях повторяется
одна и та же бизнес-логика. В этом случае рекомендуется перенести бизнес-логику в шлюз записи
данных, что превратит его в активную запись.
Паттерн «активная запись» рекомендуется использовать совместно с «простой» моделью
предметной области, когда структура домена совпадает с ER-моделью базы данных. Если же модель
предметной области является «сложной» единственным решением, позволяющим обеспечить полную
независимость слоя бизнес логики от слоя предметной области, является «преобразователь дан-
ных».
Аналогичный анализ проводится и в отношении слоя представления. В том случае, если кли-
ентская часть системы имеет множество экранов (страниц), то для организации алгоритма их вызова
дополнительно вводится «контроллер приложения». В противном случае пользуются сочетаниями
«контроллер страниц – представление по шаблону» или «контроллер запросов – представление
по шаблону». Приобретение того или иного фирменного преобразователя (например, XSLT) позво-
лит использовать «представление с преобразованием». К двухэтапному преобразованию прибе-
гают при необходимости поддерживать нескольких вариантов внешнего вида web-сайта.
<<слой
представления>>
представление
по шаблону
представление с
преобразованием
двухэтапное
преобразование
<<сервисный
слой >>
контроллер
страниц
контроллер
запросов
контроллер
приложения
<<слой
домена>>
сценарий
транзакции
модуль
таблицы
модель
предметной
области
<<слой
источника
данных>>
шлюз записи
данных
шлюз таблицы
данных
активная
запись
преобразователь
данных
БД
Рис. 10. Структура архитектурных слоев информационной системы
Таким образом, на страницах ПЗ в главе, посвященной разработке концепции
АСОИУ (ИМС), необходимо:
1. воспользовавшись литературными источниками [10, 14, 15, 34, 55] проанали-
зировать наиболее подходящие для проектируемой ИС варианты архитекту-
ры, чтобы выбрать один из них для дальнейшей проработки;
2. воспользовавшись паттернами GRASP и GoF [59, 62, 74, 80, 95] преобразо-
вать классы анализа, полученные на этапе формулирования требований к
ИС, в проектные классы. При этом в тексте ПЗ необходимо прокомментиро-
вать порядок использования того или иного паттерна;
3. воспользовавшись рекомендациями, изложенными в [98], аргументировано
выбрать и описать (с использованием диаграмм UML) типовое решение для
каждого из трех слоев проектируемой ИС: представления, предметной облас-
ти и источника данных;
4. с использованием GoF-паттернов (абстрактная фабрика, мост, цепочка обя-
занностей, команда, фасад, посредник, наблюдатель) разместить все классы,
относящиеся к тому или иному слою, в отдельные пакеты, обеспечив выпол-
нение фундаментального принципа модульной декомпозиции «низкая внеш-
няя связанность – высокое внутреннее сцепление»;
5. с использованием структурных GoF-паттернов (адаптер, заместитель, фасад)
выполнить проектирование интерфейсов отдельных пакетов системы.
35
Результаты, полученные при разработке концепции АСОИУ (ИМС), будут детализированы на
стадии эскизный проект и опубликованы в виде проектной документации программного обеспечения
(SDD – Software Design Document) в приложении к ПЗ.
4.9. ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Техническое задание (ТЗ) на АСОИУ является основным документом, определяющим требо-
вания и порядок создания (развития или модернизации) автоматизированной системы, в соответствии
с которым проводится разработка АСОИУ и ее приемка при вводе в эксплуатацию. ТЗ включает в
себя системное описание расширенных требований к разрабатываемому изделию и составляется на
основе исходного задания по курсовому проекту с учетом всей проведенной выше работы в отноше-
нии формулирования и спецификации требований.
ТЗ на АСОИУ разрабатывают на систему в целом, предназначенную для работы самостоя-
тельно или в составе другой системы. Дополнительно могут быть разработаны ТЗ на части АСОИУ
(на подсистемы АСОИУ, комплексы задач АСОИУ и т. п.; на комплектующие средства; на про-
граммные средства; на информационные изделия и т.д.) [71].
Включаемые в ТЗ на АСОИУ требования должны соответствовать современному уровню раз-
вития науки и техники и не уступать аналогичным требованиям, предъявляемым к лучшим совре-
менным отечественным и зарубежным аналогам. Задаваемые в ТЗ на АСОИУ требования не должны
ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, тех-
нико-экономических и других решений.
ТЗ на АСОИУ разрабатывают на основании исходных данных, а также данных, содержащихся
в итоговой документации стадии «Формирование требований к АСОИУ».
В ТЗ на АСОИУ включают только те требования, которые дополняют требования к
системам данного вида (АСУ, САПР, АСНИ и т. д.), содержащиеся в действующих НТД, и опреде-
ляются спецификой конкретного объекта, для которого создается система.
Поскольку в подразделе 2.6.1. ТЗ на создание АСОИУ (ГОСТ 34.602-89) необходимо пере-
числить требования к системе в целом, а в подразделе 2.6.3 требования к различным видам обеспече-
ния, то в главе «Техническое задание» пояснительной записки необходимо с учетом специфики про-
ектируемой АСОИУ, а также данных, указанных в задании на курсовой проект, выполнить анализ
требований, имеющих наиболее существенное значение.
В данном разделе ПЗ могут быть проанализированы требования к структуре и
функционированию системы, к численности и квалификации персонала систе-
мы и режиму его работы, показатели назначения, требования к надежности,
безопасности, эргономике и технической эстетике, к эксплуатации, защите ин-
формации от несанкционированного доступа, требования по сохранности ин-
формации при авариях, требования к защите от влияния внешних воздействий,
к патентной чистоте, требования по стандартизации и унификации; а также тре-
бования к видам обеспечения: математическому, информационному, лингвис-
тическому, программному, техническому, метрологическому, организационно-
му, методическому и другим [66, 68].
В частности, при описании требований к информационному обеспечению в большинстве слу-
чаев анализируют системы управления базами данных, структуру процессов сбора, обработки, пере-
дачи данных в системе и представлению данных, защите данных от разрушений при авариях и сбоях
в электропитании системы. При описании требований к лингвистическому обеспечению рассматри-
вают требования к применению в системе языков программирования высокого уровня, языков взаи-
модействия пользователей и технических средств системы, а также требования к кодированию и де-
кодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам
описания предметной области (объекта автоматизации). При описании требований к программному
обеспечению системы приводят перечень покупных программных средств, а также требования к не-
зависимости программных средств от используемых СВТ и операционной среды, к качеству про-
граммных средств, а также к способам его обеспечения и контроля.
Техническое задание на создание АСОИУ, оформленное в соответствии с ГОСТ 34.602-89
«Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое
задание на создание автоматизированной системы», помещается в приложение ПЗ. Учебный пример
составления ТЗ см. в [60, 76].