Дефрагментация мозга. Софтостроение изнутри - Сергей Тарасов

• «Постановка задачи тоже сложна». Ума не приложу, откуда возникли эти десятки тысяч строк спагетти-кода.

• «Сроки очень сжатые». Мы давно забили болт на проектирование.

• «Наши модульные тесты покрывают почти 100 % кода». А функциональными тестами пусть занимается заказчик.

• «В нашей системе много компонентов». Установку и развёртывание системы могут сделать только сами разработчики.

Слоистость и уровни

Разбираться в слоях и уровнях должны не только разработчики КИС, то есть «скелета», но и те программисты, которые будут наращивать на него свои приложения. Иначе велик риск ненароком прилепить бицепс вместо ягодичных мышц или наоборот.

Определение автоматизированной информационной системы (АИС) складывается из трёх основных её компонентов: людей, информации и компьютеров. Любая АИС – это люди, использующие информационную технологию средствами автоматизации [9]. И КИС не исключение.

В публикациях по софтостроению часто используются понятия слоёв и уровней программной системы. В англоязычной среде соответствующие термины —

layer и level. На физическом уровне реализующий слой компонент системы называется звеном – tier. Чтобы не запутаться в употреблении терминологии, нам следует чуть подробнее вглядеться во внутреннее устройство АИС.

Любая автоматизированная информационная система может быть рассмотрена с трёх точек зрения проектировщика:

• концептуальное устройство[93];

• логическое устройство;

• физическое устройство.

Концептуальное устройство

Концептуальное устройство АИС составляют всего три слоя.

Рис. 4. Концептуальные слои АИС

Слои концептуального устройства существуют в любой, подчёркиваю – в любой, информационной системе, даже если с точки зрения физической архитектуры или конкретного программиста их трудно различить. Это тот случай, когда незнание закона не освобождает от ответственности. Поэтому декомпозиция системы на концептуальные слои является предметом анализа, а не синтеза. Результатом этапа (или этапов) анализа являются, соответственно, концептуальные модели данных, их обработки и ввода/вывода, включая человеко-машинные интерфейсы.

Логическое устройство

Напротив, слои логической архитектуры не являются строго определёнными. Основным способом их выделения является постоянный диалог проектировщика с требованиями к системе и ответами на вопрос «Зачем нужен этот слой в данном случае?». Наиболее типовые вопросы и ответы сведены в так называемые шаблонные решения и рекомендуемые практики.

Логическое устройство является предметом синтеза, на выходе стадии – технический проект. Логическое устройство АИС в разрезе концептуальных слоёв может выглядеть, как на рис. 5.

Рис. 5. Пример организации логических слоёв АИС

Физическое устройство

Аналогично логической архитектуре, физическое устройство тоже является предметом синтеза на стадии проектирования реализации. Физический слой также называется звеном (tier).

Число звеньев системы определяется максимальным количеством процессов клиент-серверной архитектуры, составляющих цепочку между концептуальными слоями.

Рис. 6. Пример организации звеньев АИС

Тонким клиентом (thin client) традиционно называют приложение, реализующее исключительно логику отображения информации. В классическом варианте это алфавитно-цифровой терминал, в более современном – веб-браузер.

В противоположность тонкому, толстый клиент (rich client) реализует прикладную логику обработки данных независимо от сервера. Это автономное приложение, использующее сервер в качестве хранилища данных. В трёхзвенной архитектуре толстым клиентом по отношению к СУБД является сервер приложений.

Так называемый «умный» (smart client) клиент по сути остаётся промежуточным решением между тонким и толстым собратьями. Будучи потенциально готовым к работе в режиме отсоединения от сервера, он кэширует данные, берет на себя необходимую часть обработки и максимально использует возможности операционной среды для отображения информации.

Не секрет, что возможности отображения у веб-браузера, как программируемого терминала, очень скромные, по сравнению с автономным приложением. Компромиссным решением является так называемое «насыщенное интернет-приложение»[94], также являющееся тонким клиентом, но обладающее всеми возможностями отображения клиента толстого.

Уровни

Даже в простой программе типа записной книжки имеется минимум 2 уровня:

• Уровень приложения, реализующий функционал предметной области.

• Уровень служб, поддерживающих общую для всех разрабатываемых приложений функциональность. Например, метаданные, безопасность, конфигурация, доступ к данным и т. д.

Рис. 7. Уровни АИС

В свою очередь, общие для многочисленных служб функции группируются в модули и соответствующие API уровня ядра системы. Таковы, например, API оконной системы графического интерфейса, SQL для доступа к реляционным базам данным, основанные на HTTP-протоколах веб-служб или компонентная среда сервера приложений.

С другой стороны, комплексная информационная система обладает множеством приложений, реализующих функционал нескольких предметных областей. В этом случае функциональность, связанная с их интеграцией и управлением, поднимается на уровень решения. Например, конфигурация информационных потоков между приложениями, включая пакетную обработку.

Совмещение

Теперь если мы наложим слои системы на её уровни, то получим достаточно простую матричную структуру, позволяющую бегло оценить, какой из элементов необходимо реализовать своими силами или же адаптировать уже имеющийся готовый. Но, что более существенно, реализация разных подсистем может осуществляться независимо друг от друга после спецификации своих межуровневых и межслойных интерфейсов.

Рис. 8. Уровни АИС в разрезе концептуальных слоёв

Многозвенная архитектура

Итак, концептуальных слоёв в автоматизированной информационной системе всегда три: хранения данных, их обработки и отображения. А вот физических, их реализующих, может быть от одного, в виде настольного приложения с индексированным файловым хранилищем, до теоретической бесконечности.

Имея опыт разработки систем всех перечисленных на рис. 6 типов, наиболее позитивные впечатления у меня остались от «двухзвенки» с тонким клиентом. Подробнее я расскажу об этой архитектуре в главе про разработку тиражируемой КИС Ultima-Seller.

Разумеется, у каждой архитектуры есть свои преимущества и недостатки. Если подходить к вопросу проектирования объективно, то выбор в каждом конкретном случае вполне рационален. Но я вспоминаю, например, что в начале профессиональной деятельности нам хотелось просто попробовать «сделать трёхзвенку» своими руками, невзирая на то, что экономическая целесообразность такого выбора была не совсем очевидна как по затратам на разработку, так и по стоимости владения системой в будущем.

Сегодня доля специалистов, имеющих опыт в системном проектировании, в общем потоке становится всё меньше. Поэтому декомпозиция и выбор архитектуры часто проводится по принципу «прочитали статью, у этих парней получилось, сделаем и мы так же». Огород из нескольких физических уровней насаждается не потому, что это действительно надо, а потому, что очередной гуру написал об этом в своём блоге. Или потому, что нет другого опыта и мотивации его приобрести: чему научили ремесленника, тому и быть.

В итоге между экраном конечных пользователей и запрашиваемыми ими данными образуется толстая прослойка, которая на 80 % занята совершенно пустой работой по перекачиванию исходной информации из одного формата представления в другой. Регулярные восстановления долговременных объектов, бесконечные сериализации и десериализации, передача и преобразование XML, дёрганье за веб-службы… С учётом, например, обновления области экрана по изменению каких-то данных в другой его части эти мытарства умножаются в разы. Растёт время отклика системы. Пользователь нервничает и справедливо обвиняет в этом программистов.

В такой ситуации нет ничего необычного, потому что практика управления «по кейсам»[95], то есть прецедентам, является широко распространённой в среде менеджеров среднего звена. Критичность основной массы проектов в ИТ снижается, соответственно, большая часть решений переходит из технической плоскости в управленческую. Эта тенденция будет только усиливаться.

Любопытно, что в русском языке слово «менеджер» имеет весьма точный, но основательно подзабытый в эпоху советской России перевод «приказчик». Магическая сила слов! Получил бы популярность клон игры «Монополия», если бы его в конце 1980-х годов назвали «Приказчик»? Теперь сравните пару «менеджер проекта» и «тестировщик» против другой: «приказчик» и «инженер-испытатель»…