Помоги проекту - поделись книгой:
Рис. 4. Концептуальные слои АИС
Слои концептуального устройства существуют в любой, подчёркиваю – в любой, информационной системе, даже если с точки зрения физической архитектуры или конкретного программиста их трудно различить. Это тот случай, когда незнание закона не освобождает от ответственности. Поэтому декомпозиция системы на концептуальные слои является предметом анализа, а не синтеза. Результатом этапа (или этапов) анализа являются, соответственно, концептуальные модели данных, их обработки и ввода/вывода, включая человеко-машинные интерфейсы.
Логическое устройство
Напротив, слои логической архитектуры не являются строго определёнными. Основным способом их выделения является постоянный диалог проектировщика с требованиями к системе и ответами на вопрос «Зачем нужен этот слой в данном случае?». Наиболее типовые вопросы и ответы сведены в так называемые шаблонные решения и рекомендуемые практики.
Логическое устройство является предметом синтеза, на выходе стадии – технический проект. Логическое устройство АИС в разрезе концептуальных слоёв может выглядеть, как на рис. 5.
Рис. 5. Пример организации логических слоёв АИС
Физическое устройство
Аналогично логической архитектуре, физическое устройство тоже является предметом синтеза на стадии проектирования реализации. Физический слой также называется звеном (Число звеньев системы определяется максимальным количеством процессов клиент-серверной архитектуры, составляющих цепочку между концептуальными слоями.
Рис. 6. Пример организации звеньев АИС
Тонким клиентом (
В противоположность тонкому, толстый клиент (
Так называемый «умный» (
Уровни
Даже в простой программе типа записной книжки имеется минимум 2 уровня:
• Уровень приложения, реализующий функционал предметной области.
• Уровень служб, поддерживающих общую для всех разрабатываемых приложений функциональность. Например, метаданные, безопасность, конфигурация, доступ к данным и т. д.
Рис. 7. Уровни АИС
В свою очередь, общие для многочисленных служб функции группируются в модули и соответствующие API уровня ядра системы. Таковы, например, API оконной системы графического интерфейса, SQL для доступа к реляционным базам данным, основанные на HTTP-протоколах веб-служб или компонентная среда сервера приложений.
С другой стороны, комплексная информационная система обладает множеством приложений, реализующих функционал нескольких предметных областей. В этом случае функциональность, связанная с их интеграцией и управлением, поднимается на уровень решения. Например, конфигурация информационных потоков между приложениями, включая пакетную обработку.
Совмещение
Теперь если мы наложим слои системы на её уровни, то получим достаточно простую матричную структуру, позволяющую бегло оценить, какой из элементов необходимо реализовать своими силами или же адаптировать уже имеющийся готовый. Но, что более существенно, реализация разных подсистем может осуществляться независимо друг от друга после спецификации своих межуровневых и межслойных интерфейсов.
Многозвенная архитектура
Итак, концептуальных слоёв в автоматизированной информационной системе всегда три: хранения данных, их обработки и отображения. А вот физических, их реализующих, может быть от одного, в виде настольного приложения с индексированным файловым хранилищем, до теоретической бесконечности.
Имея опыт разработки систем всех перечисленных на рис. 6 типов, наиболее позитивные впечатления у меня остались от «двухзвенки» с тонким клиентом. Подробнее я расскажу об этой архитектуре в главе про разработку тиражируемой КИС Ultima-Seller.
Разумеется, у каждой архитектуры есть свои преимущества и недостатки. Если подходить к вопросу проектирования объективно, то выбор в каждом конкретном случае вполне рационален. Но я вспоминаю, например, что в начале профессиональной деятельности нам хотелось просто попробовать «сделать трёхзвенку» своими руками, невзирая на то, что экономическая целесообразность такого выбора была не совсем очевидна как по затратам на разработку, так и по стоимости владения системой в будущем.
Сегодня доля специалистов, имеющих опыт в системном проектировании, в общем потоке становится всё меньше. Поэтому декомпозиция и выбор архитектуры часто проводится по принципу «прочитали статью, у этих парней получилось, сделаем и мы так же». Огород из нескольких физических уровней насаждается не потому, что это действительно надо, а потому, что очередной гуру написал об этом в своём блоге. Или потому, что нет другого опыта и мотивации его приобрести: чему научили ремесленника, тому и быть.
В итоге между экраном конечных пользователей и запрашиваемыми ими данными образуется толстая прослойка, которая на 80 % занята совершенно пустой работой по перекачиванию исходной информации из одного формата представления в другой. Регулярные восстановления долговременных объектов, бесконечные сериализации и десериализации, передача и преобразование XML, дёрганье за веб-службы… С учётом, например, обновления области экрана по изменению каких-то данных в другой его части эти мытарства умножаются в разы. Растёт время отклика системы. Пользователь нервничает и справедливо обвиняет в этом программистов.
В такой ситуации нет ничего необычного, потому что практика управления «по кейсам» [95] , то есть прецедентам, является широко распространённой в среде менеджеров среднего звена. Критичность основной массы проектов в ИТ снижается, соответственно, большая часть решений переходит из технической плоскости в управленческую. Эта тенденция будет только усиливаться.
Любопытно, что в русском языке слово «менеджер» имеет весьма точный, но основательно подзабытый в эпоху советской России перевод «приказчик». Магическая сила слов! Получил бы популярность клон игры «Монополия», если бы его в конце 1980-х годов назвали «Приказчик»? Теперь сравните пару «менеджер проекта» и «тестировщик» против другой: «приказчик» и «инженер-испытатель»…
Кто не хочет – ищет причины, кто хочет – средства. Ищите возможности сократить путь информации от источника к пользователю и обратно. В конце концов, архитектура служит для эффективной реализации системы, а не освоения бюджета и вовлечения в команду очередных выпускников курсов переквалификации. Подход разработки «по модели», о котором мы ещё поговорим, позволяет генерировать многие слои без участия программистов.
История нескольких #ifdef
640 килобайт памяти должно хватить каждому.
Билл Гейтс (приписывается), 1980-е годы
Перелом начала 1990-х годов в России вынудил целые коллективы квалифицированных системно мыслящих людей переходить из специализированных учреждений НИОКР непосредственно на уцелевшие производства, эмигрировать или начинать собственный бизнес. Не мудрено, что в такой ситуации уровень технической культуры в отделе программирования торгово-производственной компьютерной фирмы «Ниеншанц» был достаточным и для софтостроительных проектов. Разумеется, не последняя роль в создании атмосферы и соответствующего интеллектуального уровня принадлежала основателям компании, пришедшим в бизнес из научной среды: Виктору Ярутову, Дмитрию Разгуляеву, Егору Макарову – выпускникам физического факультета ЛГУ [96] .
Таким образом, уже в начале – середине 1990-х на предприятии существовала собственная комплексная информационная система Seller 2, выполненная в трёхзвенной архитектуре с технологией если и не совсем «умного», то и не вполне толстого клиента. Хотя разработчики ещё не знали термина
В следующей главе речь пойдёт о разработке тиражной КИС в «Ниеншанце». Разумеется, возникла она не на пустом месте. Чтобы самому не пересказывать предысторию появления нового продукта в виде предшествующих версий, я обратился непосредственно к участникам, своим бывшим коллегам. С небольшими поправками текст публикуется с их согласия.
То, что рассказывают ведущие программисты Дмитрий Цуранов (ДЦ), Сергей Быков (СБ) и Игорь Паньшин (ИП), кандидат технических наук, участвовавший в разработке на стадии платформы VAX [97] , вначале было весьма близко к современным понятиям «эволюционный дизайн» и «гибкие методики». Но потом приходит осознание и понимание.
Начало
ИП : Все начиналось на Рижском проспекте (бывший пр. Огородникова), 26 в Институте Аналитического Приборостроения при Академии Наук СССР. Основной нашей деятельностью была разработка программного обеспечения вообще. Нас кидало из стороны в сторону. От разработки графики для терминалов Radiance, отладки кластеров VAX 6320 и VAX station на базе сети DECnet, редакторов, пакетов цифровой обработки сигналов до баз данных Datatrieve, с которыми можно было общаться в командной строке, каких-то игр и просто удовлетворения интереса работой типа «псевдоклавиатурный драйвер». Тогда, на излёте СССР, я постоянно искал дополнительные заработки. Среди моих знакомых был Д. Разгуляев, уже занимавшимся бизнесом, результатом которого стала фирма «Ниеншанц», располагавшаяся в то время около станции метро «Чернышевская».
ДЦ : Около 1991 года мы в «Аналитприборе» начали делать систему по заказу фирмы «Ниеншанц». Какую систему? Трудно сказать. Первое техническое задание в виде клочка бумажки с закорючками родилось значительно позже, а тогда… Тогда мы делали систему, которая работает с базой данных. Не больше и не меньше.
В качестве базы использовалась СУБД VAX RDBMS, а само программирование шло на голом C. Было очевидно, что понадобится прокрутка данных, для чего напрашивались курсоры. Как выяснилось, имеющиеся в VAX курсоры блокировали данные, в результате чего было принято решение отказаться от них вообще, соорудив структуру, называвшуюся «вектор». Вектор – это результат выборки данных, по которой перемещается текущая позиция. Когда вы уходите вверх или вниз, подгружаются новые данные, не одна строчка, а сразу пакет, чтобы обращения к базе были реже. Библиотечка на C, предоставлявшая интерфейс к векторам, получила гордое название CST, или Client Server Tool.
СБ: Первоначальная архитектура системы была экзотической – сервер VAX c RDBMS, клиент на ПК. Она была обусловлена тем, что у «Ниеншанца» уже был один VAX. В числе прочих, рассматривался вариант с тонким клиентом: база данных VAX RDBMS, приложение на C или Паскале под VAX/VMS и тонкий клиент на ПК по протоколу X11. Несколько месяцев мы экспериментировали с X Windows.
#ifdef NWSQL (1991–92 год)
ДЦ: Спокойное время в «Аналитприборе», безвозмездно, то есть даром, предоставлявшем нам VAX, кончилось, и мы перешли в фирму «Ниеншанц», где столкнулись с персоналками IBM PC и операционной системой MS-DOS. Впечатление, которое произвела на нас однозадачная MS-DOS после 32-разрядной VAX/VMS с
В качестве сервера использовался Novell NetWare, а в качестве базы – NetWare SQL, и по этому случаю код библиотечки «векторов» пополнился многочисленными #ifdef NWSQL. Так как мы озаботились целостностью данных, то на Watcom C был написан серверный модуль NLM [99] , обеспечивавший механизм пессимистичных блокировок и даже рассылавший сообщения о модификации данных, что проводило к автоматическому обновлению векторов.
Кроме того, у нас появился программист, отвечающий за GUI [100] . Он разрабатывал довольно своеобразный редактор форм. Впрочем, у нас все было своеобразным.
СБ: «Ниеншанц» решил, что VAX – это слишком дорого для собственной КИС. Вот тогда возникли Novell и Btrieve, которые были бесплатным к нему приложением.
Новым программистом GUI был Юрий Дымов по прозвищу «папа», потому что, даже будучи младше нас, в 1992 году он уже был женат, имел дочь. Юра обладал богатым арсеналом приёмов программирования, о котором говорит тот факт, что один раз утечку памяти он пытался исправить сменой компилятора
C. Он написал собственный менеджер памяти, то, что современным языком называется
ДЦ: Конечно, программисты такого типа не смущаются вставлять в код уродливые подпорки «чтобы работало». Они обычно плохо работают в длинных проектах, слишком много энтропии вносят в код. Зато если «кровь из носу» надо сделать так, чтобы работало сегодня к 16 часам, – они лучше всех.
ИП: В России наступала эра персональных ЭВМ, а я не мог бросить заниматься VAX-ами. Прямо, как чемодан без ручки. Правда, там были общедоступные исходники. Я имею в виду общество DECUS (Digital Equipment Corporation User Society). Поэтому пришлось сделать выбор.
#ifdef BTSQL (1992-93 год)
ДЦ: NetWare SQL был лишь надстройкой к СУБД Btrieve [102] , встроенной в Novell-овскую серверную операционную систему. Причём эта надстройка выполнялась на клиенте в специальной резидентной программе
В итоге был написан небольшой слой, который находился под CST и транслировал узкое подмножество SQL без соединений (
Работа с Btrieve была ещё тем удовольствием, поскольку отсутствовало понятие логического поля. Например, при создании индекса указывалось, что индекс включает байты с 3-го по 9-й, а второй сегмент – с 22-го по 25-й. Список таблиц, полей, смещений к началу полей в записи приходилось вести самостоятельно.
Интересно, что Btrieve имела уникальный двухверсионный уровень изоляции, который я нигде больше не встречал. Процессы-читатели никогда не блокировались и не считывали «грязные» [103] данные, а если напарывались на них, то брали предыдущую чистую версию. Понятно, что какая-либо целостность этой версии по времени не гарантировалась: каждая таблица хранилась в своем файле. Журналов транзакций не было, «грязные» данные хранились в специальных страницах (
СБ: Кроме первой пробной установки Novell, за все остальные компания честно платила. Поэтому стоимость лицензий NetWare SQL была серьёзным аргументом в дополнение к его слабому быстродействию. CST на «голом» Btrieve работал в разы быстрее.
Кроме системы учёта для «Ниеншанца», на CST в 1992 году была сделана система для Молодёжной Биржи Труда. Как минимум год мы её сопровождали. В том же году сервер CST демонстрировался на выставке в ЛенЭкспо.
NDL, или Java в миниатюре (1993–94 год)
ДЦ: Между тем система, построенная на всем перечисленном, уже активно использовалась в компании и назвалась Seller 1.0. Написана она была, кроме интерфейса, опять-таки на голом C, а из-за ограничения в 640 килобайт представляла несколько разных исполняемых модулей: pay.exe для бухгалтерии, seller.exe для продавцов, store.exe для склада… Универсальную программу по причине размера собрать было уже нельзя.
Однако ограниченность платформы была ясна, и мы предприняли попытку разработать свой, как говорят сейчас, фреймворк. Да, мы создали в кратчайшие сроки свой язык NDL [104] , компилятор, компоновщик и исполняющую систему, независимую от ОС. Она была переносима без каких-либо серьёзных проблем, в переходный период код исполнялся одновременно и под DOS, и под Windows. В ней была даже реализована бесконечнозначная арифметика с фиксированной точкой, хотя в самом NDL количество знаков ограничивалось 64.
Но Windows будет потом, а пока исполняющая система под DOS научилась грузить NDL-программу в расширенную оперативную память (
СБ: Если Seller 1 делался по наитию Д. Разгуляева, уточнявшего каждую неделю техзадание, то Seller 2 мы делали «правильно». Месяца 2–3 мы практически «бездельничали» – то есть придумали и обсудили приличное количество идей, оставив то, что нам казалось лучшим. Нарисовали схему базы данных и даже составили список ключевых функций. И только после этого приступили к реализации.
Сам NDL начинался с интерпретатора. Был придуман мета-код, первые бизнес-функции писались прямо на нем, но через месяц стало ясно, что без нормального языка дальше жить нельзя. Тогда появился NDL, компилятор и компоновщик. За основу синтаксиса был взят Паскаль. Код компилятора генерировался по описанию грамматики конвейером из 2 утилит, lex и yacc, под FreeBSD, установленной на одном из серверов. Полученный код на C затем компилировался в среде Borland под Windows. Компоновщик NDL собирал проект по описанию в makefile с разрешением имён глобальных и локальных ссылок и объектов. При этом он мог оставлять комментарии, которые позволяли исполнять код в режиме отладки с позиционированием на строки исходного кода. Всё было по-взрослому, несмотря на то, что сделано командой из 3 человек менее чем за год.
Закат Novell
ДЦ: Начиналось все хорошо. Вышел новый Btrieve версии 6, где появились интерактивное резервное копирование (
Поначалу я этому обрадовался: задал сложный поиск, и сервер думает минуту. Пока не заглянул на заднюю панель компьютера. Лампочки, показывающие активность сетевой карты непрерывно горели! Маленький резидент на клиенте непрерывно посылал запросы типа «Готово? – Ещё нет». Иначе он и не мог, ведь раньше все обращения к Btrieve были короткими, и ждать не предполагалось…
Но тут вышла Windows 95 под кодовым названием «Чикаго». Novell почему-то не торопилась делать 32-разрядные драйверы и вообще как-то реагировать на новый тренд. В итоге Microsoft сама сделала 32-битные версии драйверов для IPX/SPX, но воспользоваться ими было невозможно, так как пресловутый brequest работал в 16-разрядном режиме DOS.
Наконец, я нашёл файл с говорящим именем breq32.dll (в «догугловую» эпоху это было делом дней и недель, а не секунд) и… выяснилось, что она представляет собой лишь 32-разрядный интерфейс для обращения к пресловутому brequest.
Последний гвоздь в крышку гроба Novell, как платформы разработки, был забит с попытки запустить систему под Windows NT. Все заработало правильно, но раз в 10 медленнее. Так у нас появился следующий #ifdef.
СБ: У Nоvell был лучший файловый сервис, который я видел. Нормальное управление правами доступа,
Сегодня я считаю, что такой альянс был ошибкой, так как Novell базировался на архитектуре x86. Тем, кому был нужен Oracle, такие решения не подходили, они в 1990-х покупали серверы на многопроцессорных RISC-архитектурах, например SPARC, а Novell был продуктом более низкой ценовой категории.
Думаю, они специально не торопились с драйверами под Windows и поддержкой доменов NT в своей службе каталогов, понимая, что Microsoft – их прямой конкурент, поскольку Windows объединила в себе функции сетевой серверной и настольной ОС. Btrieve под NT появился в результате выделения продукта в отдельную компанию.
От автора: Я снова столкнулся с Novell в 2010 году в рамках небольшого проекта для французской национальной сети телевещания. Корпоративная система безопасности для тысяч компьютеров на разных территориальных площадках была по-прежнему построена на службе каталогов NetWare, хотя и в тесной интеграции с аналогичной службой Microsoft. Новые компьютеры с Windows Vista/7 включались в общую систему. Сама Novell в конце того же 2010 года была куплена малоизвестной компанией Attachmate за целых 2,2 миллиарда долларов и формально прекратила существование. По некоторым сведениям, за Attachmate стояла Microsoft, незадолго до того выложившая 450 миллионов на приобретение у Novell технологий.
#ifdef Windows
ДЦ: Между тем мы стали переходить под Windows. Как уже говорилось, для кода бизнес-логики, написанной на NDL, переделок не потребовалось вовсе. Клиентское приложение было переделано, но понимало описания форм, сделанных ещё под DOS. Конечно, под Windows моноширинные шрифты и формы выглядели довольно уродливо, но тем же страдал и SAP R/3.
Пришлось нам переделывать и систему печати документов под лазерные принтеры, но это отдельная маленькая история. А вот что сильно портило настроение, это старая DOS-подсистема для Btrieve. Стоило программе обратиться с запросом на сервер, и она уходила в себя. Ещё один камень в огород Novell. Поэтому вскоре у нас появился последний в развитии второй версии #ifdef.
СБ: Когда в Seller 2 появился небольшой модуль кадрового учёта, то при запуске система стала поздравлять пользователя с днём рождения. На 8 марта мы рисовали стартовый экран с поздравлениями в стихах. Один год на первое апреля мы перевернули драйвер мыши: двинешь мышь влево – курсор идёт вправо, мышь от себя – курсор вниз. В другой раз перевернули экран вверх ногами. Сейчас мне трудно представить, чтобы с утра у всех в конторе, включая директоров, появились перевёрнутые экраны и программистам за это ничего не было.
Также существовал файл настроек, управлявший цветовой гаммой интерфейса. Кто-то из нас проговорился, и пользователи про него узнали. Такой вакханалии цветов, как в отделе оптовых продаж, я не видел нигде…
#ifdef MSSQL
ДЦ: Система стала полностью 32-разрядной, перепрыгнула на полноценную СУБД. Интересно, что в коде можно было по-прежнему встретить #ifdef VAXVMS… [105]
NDL переводил наиболее частые сообщения SQL на русский, чтобы пользователи не пугались. Приложение выдавало «табличку» – окно с сообщением на английском.
СБ: «Табличка» – термин одной из работниц склада. – Валя, почему это табличка? Это же окно сообщения… – Оно же в рамочке! ДЦ: До боли знакомое всем работающим с SQL Server сообщение «
СБ: Сервер блокировок перестал использоваться после перехода на SQL Server 6.5 и отказа «Ниеншанца» от использования Novell в качестве файлового сервера. Помню, как одна из девочек-продавцов с удивлением узнала, что теперь удалённый файл нельзя восстановить, в корзине сервера его не было. Серверу блокировок стало негде работать, он был реализован в виде NLM, и его заменили на использование функции app_lock. И снова абсолютно прозрачно для бизнес-приложений – просто заменили в NDL реализацию соответствующей мета-команды.
Постскриптум
Если вы дочитали предысторию до конца, вдумайтесь в цифры. КИС, реализующая основные функции автоматизации деятельности торгово-производственной фирмы среднего размера: от бухгалтерии и складов до сборочного производства и сбыта – была разработана командой из 4–5 человек примерно за полтора года, включая миграцию с предыдущей версии. Система критичная, даже короткий простой оборачивается параличом деятельности фирмы.
Причина столь сжатых сроков? Ясное понимание решаемых прикладных задач, создание соответствующего задаче инструментария, прежде всего, языка бизнес-правил высокого уровня, и подтверждение тезиса Брукса о многократно превосходящей производительности хороших программистов по сравнению с остальными.
Последние годы в ходе аудита баз данных я не раз наблюдал, как современные команды в 2–3 раза большей численности, вооружённые умопомрачительными средствами рефакторинга и организованными процедурами гибкой разработки, за год не могли родить работоспособный заказной проект, решающий несколько специфичных для предприятия задач. Сотни тысяч строк кода уходили в мусорную корзину или продолжали поддерживаться с большими трудозатратами, сравнимыми с переделкой.
В другом случае четыре с половиной программиста сумели в короткие сроки создать и в течение многих лет сопровождать КИС для французского туроператора национального (один из крупнейших) и европейского уровня. Это уже потом к ней приделали веб-интерфейс для заказов клиентов и B2B [106] -шлюз с партнёрами.
Есть о чём призадуматься, особенно желающим начать новый проект.
Ultima-S – КИС из коробки
На дворе стоял 1996 год, падение экономики если уже не прекратилось, то сильно замедлилось, но компания «Ниеншанц» приступила не просто к разработке очередной, третьей версии внутренней системы управления предприятием, а к созданию тиражируемого коробочного продукта. Словно в подтверждение мысли М. Донского о том, что техническая культура – это не производства и знания, а люди, умеющие это делать и применять [11].
Название у нового продукта возникло не сразу. К концу первого полугодия разработки продукта с кодовым названием Seller 3 руководство решило, что для широкого круга потенциальных клиентов название должно быть более «брендовым». Так появилась Ultima-S, где буква «S» перешла по наследству в качестве инициала прежнего имени.
Существует два основных подхода к разработке КИС, условно называемых «
В первом случае функциональным ядром системы становится планирование ресурсов производства. Упрощенно: на предприятии есть сотрудники, оборудование и сырьё (материалы, компоненты), с одной стороны, а с другой – план выпуска – «чего и сколько?» вкупе с технологией – «как?», то есть правилами, нормами и прочими ограничениями процесса преобразования сырья в готовую продукцию. В первом приближении, необходимо составить оптимальный по загрузке персонала и оборудования план этого процесса. После того как система научилась составлять производственный план, она тянет за собой все остальные функции: от кадров, ведь персонал не из воздуха появляется, и снабжения сырьём до складирования и сбыта готовой продукции.
Альтернативный путь проходит через бухгалтерию. Под термином «бухгалтерия» имеется в виду прежде всего внутренний, управленческий учёт на предприятии, а не фискальная её часть. Дело в том, что механизмы бухучёта придумали ещё в XV веке вовсе не ради подачи отчётности в средневековую налоговую инспекцию, а для понимания состояния дел на своём предприятии. Бухгалтерский учёт – хорошо формализуемая аппаратом матричной алгебры[13] абстракция для отражения и анализа хозяйственных операций в дискретных периодах времени, в том числе и будущих.
Большинство известных мне разработок КИС в России 1990-х годов шло «от бухгалтерии». Причина достаточно простая. Производство за первые 5 лет упало более чем вдвое, при этом у заводов, как правило, уже имелись свои системы, в том числе перенесённые с мейнфреймов на «персоналки» собственными силами отделов программистов, чаще всего в рамках файл-серверной технологии. В то же время рос сектор услуг, оптовой торговли и дистрибуции, многие предприятия создавались «с нуля», и для их автоматизации производственные системы не подходили за отсутствием собственно производства.
Поскольку основными потенциальными клиентами Ultima-S были именно оптово-розничные торговые компании, то функциональная архитектура системы базировалась на подходе «от бухгалтерии».
Запустив в эксплуатацию и получив в сопровождение систему, кратко описанную в предыдущей главе, программисты на собственном опыте убедились, что каждый физический слой увеличивает трудоёмкость разработки, тестирования и последующих модификаций системы. Поэтому, с учётом предполагаемого тиражирования, развивать продукт было решено в следующих направлениях:
• минимизация числа звеньев;
• «утончение» клиентского приложения, в идеале до уровня веб-браузера;
• использование промышленной СУБД для реализации бизнес-логики;
• реализация некоторых механизмов ООП для упрощения разработки прикладными и сторонними разработчиками методом надстраивания новых классов.
Синтезом вышеназванных приоритетов явилась двухзвенная архитектура с тонким клиентом.
Превратить промышленную СУБД в сервер приложений с технологической точки зрения просто. Для этого вам необходимо:
• запретить прямой доступ к таблицам базы данных;
• реализовать прикладную логику в виде хранимых процедур, функций и триггеров;
• разрешить доступ всех приложений только к соответствующим хранимым процедурам.В технологии с тонким клиентом дополнительно потребуется:
• разработать протокол прикладного уровня для взаимодействия тонкого клиента и сервера приложений;
• запретить доступ ко всем объектам базы данных вообще, за исключением нескольких реализующих этот протокол хранимых процедур и, возможно, буферных таблиц.Наконец, для надстройки над процедурным расширением SQL объектно-ориентированной среды, управляющей объектами предметной области, понадобилось:
• добавить поддержку декларации классов на уровне метаданных;
• реализовать механизм обработки сообщений между объектами;
• разработать набор базовых классов уровня ядра и служб системы (см. уровни).Я не буду подробно останавливаться на сравнении преимуществ и недостатков использованной в продукте архитектуры, они достаточно известны и не раз обсуждались в разных формах. Скажу лишь, что для нас сумма преимуществ тогда перевесила. Во многих случаях перевесит и сейчас, даже если добавить ещё одно промежуточное звено из простейшей веб-службы, занимающейся ретрансляцией сообщений между терминалом и СУБД.
Поделиться книгой: