Помоги проекту - поделись книгой:
В качестве базовой абстракции был выбран документ. То есть все объекты в системе – это документы, относящиеся к какому-либо их классу. Каждый документ хранился в одной из папок, составляющих иерархию, напоминающую вид обычного проводника Windows.
В рамках механизма ООП, надстроенного над процедурным, поддерживалось одиночное наследование реализации. Вместо формальных конструкторов, деструкторов и методов основу составил механизм событий, вызывающий процедуры-обработчики в порядке, зависящем от иерархии классов.
В наибольшем выигрыше оказалось прикладное программирование. Сбылась «голубая мечта» – вся… нет, не так, ВСЯ разработка сосредоточилась в одном звене и среде на декларациях классов, свойств-операций и на реализующих обработку событий хранимых процедурах.
Тонкий клиент отображал в динамике результаты обработки события сервером. Большинство экранных форм, таким образом, формировалось автоматически, программист только объявлял в процедуре соответствующие поля ввода и сетки. Для специфичных случаев расположения элементов управления было необходимо визуально проектировать форму либо во встроенном в приложение редакторе, либо в среде Visual Basic, загрузив затем описание формы на сервер.
В общем случае, для создания программистом новых классов в системе было необходимо:
• декларировать классы;
• создать соответствующие таблицы;
• описать возможные ограничения на уровне метаданных (например, папку для создания по умолчанию или максимальное число ссылок);
• написать обработчики стандартных событий;
• добавить привилегии, видимые администратору;
• если необходимо, инициализировать данные, например, создать служебные объекты или документы-классификаторы.Всё перечисленное программист мог сделать на макрорасширении над языком Transact SQL, не выходя за рамки разработки соответствующих скриптов. Приведу примеры использовавшегося кода.
Пример фрагментов кода модуля учёта сотрудников
Как можно заметить, декларация форм напоминает таковую в HTML, но с гораздо более богатыми элементами стандартного графического интерфейса, не ограниченного возможностями браузера. Прикладному программисту не надо управлять соединением с сервером баз данных, внедрением SQL-запросов, обработкой сетевых ошибок и многим другим, потому что код уже находится внутри процедур адресного пространства СУБД, обеспечивая максимальную производительность обработки данных. При этом, на минуточку, на дворе 1996 год, никто из веб-разработчиков пока не выходит за рамки
Номенклатура базовых классов и системных служб позволяла пользоваться полуфабрикатами прикладного назначения: от управления жизненным циклом документа, доступом к папкам до бухгалтерских абстракций, позволявших задействовать механизмы материального и финансового учёта. Для реализации нового типа документа и отражения его в системе управленческого учёта предприятия программисту требовалось работы на 1–3 дня.
Высокая степень изолированности ядра и тонкого клиента от прикладных модулей позволила также специализировать работу части программистов над системой, не привлекая других разработчиков, для которых более важным было понимание предметной области, чем используемых архитектур. Если за год с созданием первой версии и собственно технологии справлялось пять человек и двое дистанционно разрабатывавших тонкого клиента программистов, то в дальнейшем по мере расширения функционала штат прикладных программистов увеличился.
Однако в планах руководства было создание коробочного продукта, задача, требующая гораздо больше усилий по созданию обобщённых моделей предметных областей и функциональной архитектуры в целом. Техническая архитектура – важный, но не единственный столп разработки тиражируемых продуктов. Никакая широта технической мысли не поможет, если на платформе реализуются неадекватные по сложности задачам решения, неполные или противоречивые требования. К сожалению, эта проблема не была решена и во второй версии прикладного обеспечения системной платформы.
Приведу мнение коллеги по проекту, Владимира Иванова, аналитика и руководителя группы разработки бухгалтерской подсистемы. Роль функционального архитектора или, в терминах MSF [107] , менеджера продукта он называет просто «маркетолог».Я попробую сформулировать, что делалось неправильно и какие решения были найдены, их уже удалось применить большей частью в проектах за пределами Ultima-S на базе ее разработки.
Проектированием системы на самом деле должен заниматься не технарь, а маркетолог как Стив Джобс. Система – это товар, удовлетворяющий потребности. Маркетолог может понять потребности рынка, сформулировать требования к товару, может оценить осуществимость маркетинговой компании. На деле технический архитектор нужен маркетологу для оценки себестоимости проекта и его сроков, а также для информации о новых перспективных технологиях, тогда маркетолог сможет искать сочетания «потребность + технология». Проблема проекта Ultima-S и многих других в том, что там не было маркетолога, определяющего вид продукта и программу продвижения, что сделало бессмысленным большое количество технологических действий.
Следуйте совету Джобса: «Обычные художники заимствуют – великие воруют». Для меня, как руководителя группы разработки бухгалтерского модуля, существовала проблема: никто не мог поставить задачу. Системный архитектор был «не совсем в теме», маркетолог со знанием продукта отсутствовал. Но мне в голову пришла удачная идея начать копировать макроязык и систему настроек 1С, одновременно обеспечивая совместимость с объектной моделью Ultima-S. Если бы разработчики Ultima-S, до того как взяться за написание кода, провели тщательное изучение архитектур аналогов на рынке, все было бы иначе. Можно было бы передовую платформу Ultima-S приспособить к куче хороших идей у 1С и «Галактики». Я в то время часто общался с экспертами «Галактики», они серьёзно опасались, что мы именно так и сделаем: реверс-инжиниринг и переписывание в новой технологии. Ресурсы для этого у нас были. Но, увы, сделали только частично, а 1С – это все-таки модель малого бизнеса, тогда как мы целились в сектор Enterprise, где была «Галактика».
Учитесь у лидеров рынка, их успех не от «просто так». Я получил два важных опыта в этом проекте – объектно-реляционное моделирование и проблемно-ориентированные конструкторы, которые популяризовал Нуралиев. Могу сразу сказать: Нуралиев круче. Дело в том, что его функциональная архитектура была следствием изучения потребности рынка и типовых сценариев внедрения. Наш
бухгалтерский модуль из Ultima-S до сих пор живёт и здравствует в нескольких холдингах, которые не раз оценивали миграцию на Axapta, но оставались все равно на нём. Концепция 1С плюс возможность Transact SQL-программирования – мечта многих разработчиков бизнес-решений. Нуралиева много раз просили это сделать, но он держался за свой подход, чтобы поддержать кросс-платформенность [108] .
Наследование объектов и объект-контейнер с визуальным конструктором. Ultima-S построена на идее наследования классов, как современный вариант PostgreSQL. Если брать модель 1С – это наследование только на системном уровне и отказ от наследования в бизнес-уровне в пользу конструирования путём сложения комбинаций объектов в объект-контейнер с помощью визуальных конструкторов. Модель 1С сильней. Быстрее создаёт новые сущности, за счёт разделения системного уровня и конструктора, она также надёжнее, так как настройщики очумелыми ручками не могут залезть в ядро.
Прикладная разработка не место для эстетического наслаждения от красот технологий. Это бизнес. Ultima-S сильно пострадала от того, что стала чем-то вроде лаборатории Xerox в 1980-х, где масса людей апробировала разные технологии, научилась и пошла делать другие проекты в Apple и Microsoft. Архитектурные эксперименты оправданы, если маркетолог видит преимущества в архитектуре товара, которые преобразуются в удовлетворение потребностей клиентов. Надо оценивать эффективность архитектуры не в терминах красот, а в терминах трудозатрат. Пользователю все равно, он не видит что там внутри. Но он видит, что система дорабатывается медленно или валится с ошибкой. Для меня был огромный плюс, что я познакомился в этом проекте с MS Project и стал в нем анализировать трудозатраты программистов. Выводы были интересные. Я заметил, что программисты и технологии могут выглядеть невзрачно, но давать невероятные эффекты по скорости и надёжности кода в терминах низких трудозатрат, и наоборот, вроде бы красивые решения могут превращаться в «чёрную дыру» для бюджета проекта.
На деле Ultima-S показала, что идея реализации сервера приложений средствами СУБД жизнеспособна и эффективна, также она совместима с лучшими функциональными практиками на рынке, как, например, моделирование в 1С. Но отсутствие маркетолога на проекте в качестве его лидера не дало технологиям добиться коммерческого успеха, который пришёл уже к системам – наследникам Ultima-S.
Во многом разделяя мнение Владимира, хотелось бы добавить, что бороться за статус главного идеолога продукта контрпродуктивно в любой ситуации. Наилучшим, по моему мнению, решением является единство и противоположность технической и функциональных архитектур, развивающиеся при постоянном диалоге групп, ответственных за техническую реализацию решения и функционал продукта. Такая практика используется в рамках MSF, в том числе и в самой Microsoft.
Считать трудозатраты на разработку архитектуры и ядра достаточно сложно. Ещё труднее считать отдачу в дальней или даже средней перспективе. Если при разработке заказного проекта в первой версии приоритетом может быть именно ближняя перспектива, то в продуктовой разработке такой подход неизменно приводит к необходимости полной переделки второй версии.
С прикладной разработкой всё относительно просто: есть функционал, оцениваемый заказчиком или маркетологами в конкретную сумму, есть трудозатраты на его реализацию, остальное – прибыль от деятельности. Чтобы убедиться, насколько хороши техническая архитектура и платформа, как они влияют на производительность прикладного программирования в растущем проекте, надо более формально разделить эти два направления деятельности, чего сделано не было.
В конце концов, на любом серьёзном производстве кроме непосредственно цехов и мастерских есть лаборатории и конструкторские отделы, работающие на перспективу, а степень наукоёмкости или, как ещё говорят, высокотехноло-гичности продукции, напрямую зависит от доли вложений в перспективные разработки, заключённой в себестоимости товара.
Критическая масса клиентуры в проекте, выводящая его на прибыльность, не была достигнута, что послужило формальной причиной закрытия после более чем трёх лет существования. Но история на этом не кончилась.
Не прекращалась поддержка некоторых клиентов. После перерыва базовая часть системы была переименована в NEXUS и перешла в домен разработок с открытым кодом. Оказалось, что платформа является весьма эффективным средством автоматизации небольшими группами и индивидуальными консультантами с хорошим знанием технологий. Было проведено несколько новых внедрений системы на базе только самой платформы с полной разработкой прикладного кода.
Возвращаю слово Игорю Паньшину, чей рассказ в предыдущей главе был коротким.
Я хотел бы рассказать о внедрении, на которое у меня ушло несколько лет. Думаю, всем известно, что такое оператор сотовой связи. Но мало кому известно, что такое сотовый оператор, у которого завтра отберут частоты. Таким оператором оказалась Петросвязь или РТК (Радио-Телекоммуникационная Компания), имевшая оборудование QUALCOM на частотах 800 МГц, которые решили отдать телевидению. Первыми сбежали разработчики биллинга BillOnLine, оставив работающую систему без всякой поддержки. На свою беду, как я не мог бросить тогда VАХ, так не смог уйти от умирающей в прямом смысле слова системы.
Выход был найден. Бралось ядро NEXUS и компилировалось в работающую базу системы BillOnLine. Тонкий клиент сразу начинал работать. Оставалось дописать классы, которые поддержали бы бизнес-задачи предприятия, что и было сделано. Подход имел ещё одно интересное преимущество перед всеми мне известными. Скрипт ядра позволял устанавливать его в базу данных практически всех систем MSProject, DOCSVision, 1C 7.7 и 1С 8, что сразу давало дополнительную свободу управления и способность дорабатывать штатную систему под нештатные нужды организации без привлечения разработчиков продукта. Основным преимуществом является способность решить бизнес задачи в рамках SQL-запросов и хранимых процедур на порядок или два быстрее, чем любая программная платформа.
Правда, сейчас, после 10 лет разработки и внедрения Ultima-S называется NEXUS, но это сути не меняет. В настоящий момент я работаю на перекрёстке NEXUS и 1С 8, обеспечивая нужную производительность учётной системы в целом. Это даже не разработка, а сопровождение-разработка.
Другой ключевой особенностью платформы является возможность анализа хозяйственной деятельности предприятия практически в реальном времени. Как только документ оперативного контура меняет состояние «черновика» на одно из действительных, информация отражается на счетах управленческого учёта с заданными разрезами. Об этом подробнее рассказывает Сергей Быков, ведущий специалист BI.
Технические ограничения эпохи бумаги и слабых ЭВМ вынудили «зашивать» аналитику в код счета. До сих пор многие системы, спроектированные профессиональными бухгалтерами, реализуют именно этот подход, например Oracle и SAP. Получить подробные данные о деятельности предприятия из классической главной книги (ГК) невозможно: количество сегментов в коде счета ограничено очень скромным числом (4–8).
Из-за этого возникла задача анализа хозяйственной деятельности предприятия. Но по сути эта всё та же учётная задача – построение отчётов об операциях на основании заданных правил группировки типов документов. Такая группировка делается и в ГК, но с потерей существенной для принятия решений информации.
Бухгалтерский движок в NEXUS позволяет преодолеть «проклятие» учёта по плану счетов с сегментацией кода счёта. Код отражает только вид операций – кассовые, банковские, складские, производственные и т. д. Существенные признаки операций сохраняются в виде аналитических срезов. В результате получается структура, сразу пригодная для OLAP [109] .
Судите сами, Saldo – таблица фактов, несколько раз соединённая с таблицей Docs (измерения). Классическая «звезда». Для того чтобы помочь OLAP-клиенту, создаём отдельные view для каждой роли таблицы Docs – клиенты, товары, счета (в понятии регистров учёта), валюты, партии и т. д.
Далее подключаем эту структуру в Excel и получаем готовый OLAP, который наполняется данными в соответствии с учётной политикой предприятия, непосредственно в момент выполнения хозяйственных операций. Это не просто анализ операционной деятельности, это сверхоперативный анализ! Такая оперативность в других, более раскрученных системах возможна только в виде ограниченных плоских отчётов, построенных по первичным документам.
Я поддерживаю системы на этом «моторе» уже 10 лет – решение на удивление простое, гибкое и мощное. За это же время имел опыт использования JDEdwards OneWorld, Oracle Apps и в меньшей степени с SAP.
История системы продолжается.
Нешаблонное мышление
Моя профессиональная практика складывалась таким образом, что обсуждение обобщённых решений касалось прежде всего задач предметной области и соответствующего уровня абстракций. С некоторой натяжкой их можно отнести к аналитическим шаблонам, так как в качестве основы брались только существенные части структур, интерфейсов или даже просто рабочие идеи. Лучше назвать их аналитическими эскизами.
О типовых решениях уровня реализации речь заходила редко, но уже в середине 1990-х годов иногда возникали упоминания книги GoF – «банды четырёх» [110] [6] о приёмах объектно-ориентированного проектирования, где была предпринята попытка их обобщения. Признаюсь, руки долго не доходили до непосредственного ознакомления с этим трудом, но где-то в начале годов 2000-х издание наконец попало ко мне в руки.
Имея уже немалый опыт проектировщика и программиста, я надеялся найти в книге, как минимум, более проработанный вариант приёмов, использованных в предшествующих проектах. Достаточно быстро я обнаружил, что за многолетнюю практику большинство описанных авторами шаблонов было совершенно невостребованным кругом решаемых задач. Те же оставшиеся, что удалось идентифицировать, несколько удивили простотой и не всегда отражающими суть названиями.
Полагаю, что для человека, знакомого с основами ООП, вынести зависящую от контекста операции логику в специализированные обработчики или даже в классы, имеющие единый интерфейс вызова, является несложной операцией, над которой придётся раздумывать несколько минут. Например, часто такая задачка возникает в разного рода генераторах, когда по исходной модели нужно выдать код на том или ином языке программирования. Видимо поэтому, мне и не приходило в голову величать такую операцию «стратегией». Не ассоциировалась у меня тактическая перестановка фигур на шахматной доске со столь солидным термином.
Зачастую, ещё вчерашние новички, научившись достаточно элементарным вещам, любят порассуждать о том, что изобретение велосипедов – пустое дело. По моим представлениям на воспроизведение большинства из приводимых в книжке «велосипедов» в конкретных случаях у любого специалиста с навыками абстрактного мышления вряд ли должно уходить более часа. Это заметно быстрее изучения самой книги, ее осмысления и, наконец, осознания тех моментов, когда, собственно, надо применить абстрактный слепок в реальной жизни.
Распространённое мнение о создании некоей общей терминологии для повседневной работы программистов также не вполне подтвердилось на практике. В используемых спецификациях названиям шаблонов не находилось места. Обычно там пишется что-то вроде «реализовать документы с такими-то атрибутами, используя следующие базовые классы фреймворка» для новичка либо «реализовать функции А, Б, и В учёта договоров, используя модули X, Y и Z» для более опытного разработчика. Дело в том, что шаблоны из книги – уровня реализации и к моделированию предметной области имеют далёкое отношение. Они востребованы скорее теми, кто программирует (не хочу писать «кодирует») в группе, руководствуясь общей для всех подробной функциональной спецификацией. «Вася, здесь я сделаю адаптер над твоим классом, чтобы не напрягать тебя. – Да, Петя, спасибо». О том же, что класс имеет всего один экземпляр объекта, то есть является «синглетоном», Петя сможет догадаться по интерфейсу и без дополнительного вопроса Васе.
Факт защиты одним из авторов научной диссертации по теме книги заставил в очередной раз призадуматься о степени проникновения современной теоретической мысли в практику софтостроения. По моим представлениям, книга имела к науке весьма опосредованное отношение и являлась скорее чем-то вроде поваренной книги. Но лучше так, чем никак. Для себя же сделал вывод: если вы практикуете уже лет 5–10, то имеет смысл пролистать книжку и отложить, понадеявшись на фоновую память. Вдруг кто-то ввернёт в беседе незнакомый термин – меньше времени уйдёт на выяснение, что имелось в виду. На практике же толку будет немного.
Сложнее обстоит дело с теми, кто только начинает свой путь. Прочтение сего труда новичком, как мне кажется, является прямым аналогом попадания в прокрустово ложе диктуемой парадигмы. Потому что книга описывает набор решений, а неокрепшему за недостатком практики уму проектировщика надо научиться самому находить такие решения и пути к ним. Для чего гораздо эффективнее первое время «изобретать велосипеды», нежели сразу смотреть на готовые чужие. На чужие надо смотреть, когда придуман хотя бы один собственный, чтобы понять, насколько он несовершенен, и выяснить, каким же путём можно было бы прийти к лучшим образцам велосипедов данной модели.
Однако книга все-таки дала всплеск, и по воде пошли круги. А. Алексан-дреску в книге «Modern C++ design» начал экспериментировать с реализацией шаблонов на C++ и продвигать в массы свои велосипеды. Появились издания с достаточно абсурдными названиями. Например, «Шаблоны на C#». Постойте, коллеги, какие ещё шаблоны на C#? Оказывается, шаблоны сыграли с программистским сообществом злую шутку: они оказались ещё и зависимыми от языка программирования. То есть, прочитав «банду четырёх», писавших свой труд исходя из возможностей C++, срочно бегите за новой порцией информации, кто для Java, кто для C#. Хотя задумывались шаблоны с обобщающей практики целью.
Поясню на примере использования шаблона Visitor. У Александреску в самом начале описания шагов по применению шаблона на существующей иерархии классов документов, которую нужно наделить новыми функциональными возможностями (в примере шла речь о сборе статистики), в качестве отправной точки приводится следующий код:
Линейный способ
void DocStats::UpdateStats(DocElement& elem)
{
if (Paragraph* p = dynamic_cast<Paragraph*>(&elem))
{
chars_ += p->NumChars();
words_ += p->NumWords();
}
else if (dynamic_cast<RasterBitmap*>(&elem))
{
++images_;
}
else…
добавляем по одному оператору if для каждого типа инспектируемого объекта
}Автором совершенно справедливо отмечается существенный недостаток этого фрагмента: преобразование типов делает его сложным для сопровождения, кроме того, нет никакой гарантии, что проверка для базового класса не выполнится раньше, чем для производного. Достаточно ошибиться в порядке следования операторов if, и на ветку производных классов программа никогда не попадёт.
Добавлю, что если разные классы элементов документов имеют полиморфные свойства, собираемые статистикой, то задача ещё более усложняется. Например, «параграф» и «формула» могут иметь одно и то же свойство NumChars.
После рассуждений о недостатках линейного кода выносится решение о необходимости виртуализации вызовов путём построения иерархии, аналогичной существующей иерархии классов, и добавления новых методов в неё. То есть реализации шаблона Visitor, описание которого на добрых двух десятках (!) страниц вы можете посмотреть в книжке. Если очень захотите.
Теперь представьте, что вы используете другой язык с развитым механизмом интроспекции типов времени выполнения. Например, отражение (Использование отражения
class DocStats
{
…
void UpdateStats(DocElement elem)
{
Type elemType = typeof(DocElement);
BindingFlags flags = BindingFlags.Public | BindingFlags.NonPublic |
BindingFlags.Instance;if (elemType.GetMethod("NumChars")!= null)
chars += (int) elemType.InvokeMember("NumChars", flags | BindingFlags.
InvokeMethod,
null, elem, null);
if (elemType.GetMethod("NumWords")!= null)
words += (int) elemType.InvokeMember("NumWords", flags | BindingFlags.
InvokeMethod, null, elem, null);
if (elemType.GetProperty("Image")!= null)
images++;
…
обследуем все интересующие нас свойства классов
}
}Проблем с преобразованием типов и порядком вызова методов нет, поэтому никаких усложнений с виртуализацией, использующихся в шаблоне для С++, не требуется.
Более того, не требуется и сам шаблон! Можно пойти и другим путём несложной и безопасной реструктуризации: извлечь существующие в неявном виде интерфейсы элементов документа в явные определения и обследовать в методе сбора статистики передаваемый объект на предмет реализации классами интерфейсов. Например, if (elemType is IParagraph), is IImage, is IFormula и т. д. Тогда можно обойтись вообще без отражения.
Наконец, существует и другое специфичное для C++ решение: реализовать аналогичную иерархию с заданной виртуальной операцией и, далее, используя множественное наследование, «подмешать» эти реализации к существующей иерархии, используя в дальнейшем только полученные классы-миксты.
Весьма элегантное решение на основе
Итого на простом примере имеем целый букет решений вместо одного шаблонного, из которых можно выбирать оптимальный. Попытавшись однажды объяснить подобное программисту, видимо, несколько увлёкшемуся шаблонами, я не встретил понимания.
Несколько позднее я наткнулся в магазине на книгу с названием, претендующим на звание наиболее абсурдного из встречавшихся. Оно звучало как «Thinking in patterns». В переводе на русский язык – «Мыслить шаблонно». Ещё недавно привычка шаблонно мыслить считалась в инженерном сообществе признанием ограниченности специалиста, наиболее пригодного для решения типовых задач с 9 утра до 6 вечера. Теперь не стесняются писать целые книжки о том, как научиться шаблонному мышлению…Думать головой
Серия коротких заметок была задумана, как некий противовес механистическому подходу к программированию, пропагандируемому различными учебниками шаблонов. Потому что думать надо не шаблонами, а головой. Начнём с того, что кажется очевидным.
Обобщение
Откажитесь от термина «наследование», который искажает смысл действий. Мы обобщаем. Обобщение (наследование) реализации или интерфейсов – весьма неоднозначный механизм в объектно-ориентированном программировании, его применение требует осторожности и обоснования.
ОСНОВНОЕ ПРАВИЛО
Обобщаемые классы должны иметь сходную основную функциональность.
Например, если два или более класса:
• порождают объекты, реализующие близкие интерфейсы;
• занимаются различающейся обработкой одних и тех же входных данных;
• предоставляют единый интерфейс доступа к другим данным, операциям или к сервису.
Взгляните, три примера, и уже несколько шаблонов оказались ненужными: (1) – «фабричный метод» (
Почему шаблоны «вдруг» стали ненужными? Потому что требуется только обобщение, причём в перечисленных случаях необходимость операции более чем очевидна. Требования же исходят напрямую из вашей задачи. Корректно проведя обобщение вы автоматически получите код и структуру, близкую к той, что вам предлагают зазубрить и воспроизводить авторы разнообразных учебников шаблонов.
Одно понятие и три очень часто встречающихся на практике случая гораздо эффективнее для запоминания и использования, нежели абстрактные картинки и текст шести шаблонов.
Основная ошибка – обобщение по неосновному функциональному признаку. Например, когда обобщают сотрудников и пользователей. Или заказы на поставку и накладные на отгрузку. Или яблоки с теннисными мячиками. Почему нет, они же разноцветные, круглые и продаются в магазинах?
Ошибка приводит к построению иерархии по неосновному признаку. Когда внезапно найдётся ещё один такой признак, возможно, более существенный с точки зрения прикладной задачи, обобщить больше не удастся: придётся ломать иерархию или делать заплату в виде множественного наследования, недоступного во многих объектно-ориентированных языках. Или пользоваться агрегацией.
Не увлекайтесь обобщением. Ошибки тоже обобщаются и уже в прямом смысле этого слова наследуются. Исправление по новому требованию может привести к необходимости сноса старой иерархии, содержащей ошибки.ВОЗЬМИТЕ ЗА ЭМПИРИЧЕСКОЕ ПРАВИЛО
Глубина более двух уровней при моделировании объектов предметной области, вероятнее всего, свидетельствует об ошибках проектирования.
Для построения устойчивой глобальной иерархии необходим серьёзный анализ предметной области, ведь не случайно создание таксономии – сложная научно-исследовательская работа, которой в крупных компаниях занимаются аналитики. Но и такой работы будет недостаточно, если, например, предполагается использование модуля (библиотеки, компонента, службы) в нескольких смежных областях. Класс «Книга» для библиотеки, магазина и читателя – это три разных взгляда на одну и ту же сущность с отличающимися ассоциациями и обобщениями. Ещё сложнее дело обстоит с классом «человек». Поэтому не спешите наследовать «менеджера» и «охранника» от класса «сотрудник» вне рамок учёта кадров, ведь они ещё и материально-ответственные лица, руководители или участники проектов, контактные лица, граждане, родители своих чад, налогоплательщики, собственники, вкладчики, заёмщики, автомобилисты…
Про сборку мусора и агрегацию
Достаточно широко известна проблема принадлежности объектов как друг другу, с образованием соответствующей иерархии, так и графу вызовов функций (подпрограмм). По словам М. Донского [11], наличие в некоторых языках механизма сборки мусора, является примером отказа от самой идеи справиться с этими проблемами и молчаливым признанием возможности присутствия в среде объектов, не принадлежащих ни подпрограммам, ни другим объектам.
Итак, сборщик мусора, он же GC –
Рассмотрим типовой пример, когда сборщик мусора спасает от ошибки программирования, но не спасает от ошибки проектирования. Речь о контейнере, являющемся владельцем своих объектов. Наиболее распространённой ошибкой является сохранение ссылок на эти объекты в другом объекте вне контейнера. При этом часто оказывается, что ссылки ещё живы, но указывают в пустоту, потому что контейнер уже удалён. В случае «ручного» управления в традиционных языках, таких как C++, при обращении по ссылке возникнет ошибка, ведущая к сбою или отказу. При наличии сборщика мусора программа продолжит работу, хотя объекты так и останутся висеть в памяти. Конечно, приятно осознавать, что программа не свалится с ошибкой, а продолжит работу. Особенно если это относительно критичное серверное приложение. Но проблема-то остаётся. Например, «висящие» объекты могут продолжать использовать или даже блокировать системные ресурсы. А могут и просто занимать недопустимо много памяти.
Решение здесь достаточно простое.
НУЖНО ВЗЯТЬ ЗА ПРАВИЛО, ЧТО
контейнер всегда управляет своими объектами. Поэтому обращаться к его внутренним объектам нужно только через интерфейс самого контейнера.
При этом быть готовым к обработке ситуации, когда контейнер говорит: «Извини, но такой объект уже удалён или пока недоступен». Если же объект переходит во владение к другому контейнеру, то он перестаёт управляться прежним. И процесс передачи объекта и управления также не может быть реализован простым присваиванием полученной ссылки.
Метафора из жизни. Вам нужна цитата из книги, библиотечный код которой вы знаете. Пусть цитата занимает одну страницу в книге, её номер вы знаете. Библиотека – контейнер книг. Книжный магазин – тоже. Варианты взаимодействия:
1. Пойти в библиотеку и взять книгу на время. У контейнера остаётся ссылка на вас, если потом книгу будут снимать с учёта (удалять), то о вас вспомнят и попросят вернуть.
//Правильно:
читатель. Книги. Добавить(библиотека. Выдать(код, читатель));
//Ошибка:
читатель. Книги. Добавить(библиотека. Книги(код));Кстати, ошибка в данном примере означает, что книгу, между нами говоря, вы попросту спёрли, а интерфейс библиотеки позволяет это легко сделать.
2. Обратиться в справочную службу библиотеки и попросить их прислать копию нужной страницы.
//Правильно:
читатель. Реферат. Цитаты. Добавить(библиотека. КопироватьСтраницу(код,
номер_страницы));
//Ошибка:
читатель. Реферат. Цитаты. Добавить(библиотека. Книги(код). Страницы(номер_
страницы));3. В библиотеке книги не оказалось, купить книгу в магазине.
//Правильно:
покупатель. Книги. Добавить(магазин. Продать(код, покупатель));
//Ошибка:
покупатель. Книги. Добавить(магазин. Книги(код));Ошибка в данном примере снова означает, что книгу вы украли.
Два совпадения. Случайные ли?
В случае явного управления памятью возникнет системная ошибка: библиотека или магазин полезут без спросу в ваше отсутствие в квартиру за объектом и заберут его назад. Придя домой, вы не обнаружите на полке нужной книги.
В случае же со сборщиком мусора факт кражи книги не вызовет внешних проблем. В самом простом случае библиотека просто удалит ссылку на пропавшую книгу из своих каталогов. Сама книга при этом продолжит занимать место на вашей полке. Но может статься, например, без вашего ведома из книги будут удалены подцензурные страницы, ведь ссылка-то известна.
Оба случая являются логической ошибкой проектирования интерфейсов, но сборщик мусора на некоторое время скроет их от вас. В этой ипостаси сборка мусора, позволяющая программистам избавиться от назойливых ошибок обращения к памяти (Журнал хозяйственных операций
Отвлечёмся ненадолго от общих концепций и рассмотрим более конкретные проблемы разработки учётных приложений. Вопросы, подобные «почему нельзя хранить остатки в форме текущих величин», «зачем нужна история операций», «зачем там нужна транзакция в режиме «сериализация» (что такое режим
Довольно сжатое изложение статьи «Как проектировать бухгалтерию»[19] в терминах абстракций может быть не очень понятным начинающим. Напротив, статья «Введение в складской учёт»[18] рискует показаться излишне упрощённой и «заточенной» на складскую бухгалтерию с отраслевой спецификой. И в обоих случаях не хватает конкретики, разъясняющей вышеназванные вопросы.
Начнём с первого антишаблона «Таблица остатков», на которые я вдоволь насмотрелся во времена буйного расцвета торгово-складского софтостроения в 1990-х годах. Начинающий проектировщик рассуждает так: мне нужно текущее количество товара в наличии, а все движения, в результате которых эта цифра и появилась, можно оставить в стороне, а то и прямо в первичных документах.
Представьте, что в документ недельной давности вкралась ошибка. Её исправили, причём пересчитанные текущие остатки по-прежнему неотрицательны. Значит ли, что они неотрицательны и на каждый день прошедшей недели? Разумеется, нет. Приходит клиент и говорит: «Мне выписали 10 штук, а на складе только 8, я на вас, жуликов, в суд подам». Парадокс? Никакого парадокса. За товаром он пришёл сегодня, но продали ему товар вчера. А на состояние «вчера» после корректировки остаток был бы отрицательным. Вот ему и не хватило.
Если не верите, что такое возможно, вот схема движения.
Теперь откорректируем приход 2012-04-01 с 12 утюгов на 10. Получаем, что на сегодня их 0. Вроде бы все в порядке. Всё, да не совсем: сегодняшняя закупка ещё не поступила на реализацию. Поэтому вчерашний «минус 2» пока действителен.
Почесав свой мыслительный орган, проектировщик приходит к неутешительному выводу: даже для фактических операций нужно считать остаток по истории (журналу). Не говоря уже о резервировании товара, где ситуация меняется гораздо быстрее: то тут отменили, то там подтвердили.
Но считать по журналу:
• может быть долго;
• необходимо защитить считанные значения, чтобы при последующей записи не возникло «минусов».
Последний пункт требует пояснений. По сути, это и есть та самая сериализованная транзакция. Она гарантирует, что считанные значения не будут изменены другой транзакцией. То есть продажа не будет давать отрицательный остаток, если между операцией расчёта остатка и расхода вклинится другой. Это просто, смотрите.
В итоге молодцы-продавцы, нечаянно воспользовавшись ошибкой программиста, сплавили клиентам 12 утюгов, хотя в наличии было 10.
Если же ваши операции расчёта, проверки и расхода работают в одной транзакции на уровне изоляции «сериализация», то такая ситуация исключена. «Продавец 2» из примера будет ждать, пока «Продавец 1» закончит операцию и в свою очередь убедится, что утюгов уже не 10, как было на экране в момент заказа, а только 5.
Почему нельзя просто блокировать всю таблицу-журнал, а надо использовать какие-то хитроумные транзакции с непонятным уровнем изоляции?
Объяснить это тоже просто. Представьте, что один продаёт утюги, а второй – гладильные доски. Если заблокировать таблицу, то второй продавец всё равно будет ждать первого. Всегда. И вообще, все и всегда будут ждать одного, подобно очереди в общественный туалет с одной кабинкой. Кстати, именно эта метафора наиболее употребительна при объяснении работы механизма бинарного семафора –
Здесь я должен отметить, что использование транзакции в режиме
Рассуждая, мы плавно подошли к вопросу «Зачем хранить историю остатков?». Действительно, ведь есть журнал, всё можно посчитать по состоянию на любой период.
Вернёмся к примеру корректировки документа недельной давности. Таблицы остатков у нас уже нет, а мы должны рассчитать и проверить на «минус» все дни за последнюю неделю. Допустим, ваша программа правильная, использует соответствующие транзакции и считает остаток от операций одного дня примерно за 500 миллисекунд. Умножим на 7, получим, что с большой вероятностью примерно 3,5 секунды пользователи учётной системы будут ожидать окончания вашей операции.
Это, мягко говоря, нехорошо. К тому же, если ваш расчёт не написан на языке СУБД – SQL, то цифра в 500 миллисекунд явно завышена в разы.
Придётся нам возвращаться к «таблице» остатков. Но совсем не к такой таблице, что была вначале, а к новой, называемой «сальдо» или «итогами». Мы добавим туда ещё один важный разрез – период. И будем поддерживать остаток на заданный период в актуальном состоянии. Тогда ваша программа просто должна попытаться отменить операцию и посмотреть, нет ли в сальдо «минусов», начиная с даты аннулированного документа. Здесь тоже возможна блокировка, но, во-первых, менее вероятная, а во-вторых, более быстрая, так как мы просто производим вычитание количества от уже рассчитанных остатков, начиная с даты вместо полного пересчёта по журналу операций.
Как поддержать актуальность остатков? Скорее всего, триггером (кто сказал «материализованные виды»?). Это будет весьма критичный код в вашей системе, поэтому придётся, не побоюсь этого слова, «вылизывать» его так, чтобы он выстреливал за единицы миллисекунд. Дам совет начинающим: учите сиквел, транзакции, уровни изоляции, и будет ваша система быстрой и надёжной. И не только в примере с учётной системой, но и вообще по жизни. Опытным же разработчикам есть поле для оптимизации и дальнейшего совершенствования решений, включая альтернативные подходы.UML и птолемеевские системы
Для того чтобы было легче подступиться к теме унифицированного языка моделирования UML, уже упоминавшегося в предыдущих главах, необходимо сделать небольшое историческое отступление [21].
Что же заставило учёных отказаться от системы Птолемея? Ответ с позиций современной теории познания мы видим в следующем. Система Птолемея описывала движение планет, видимое с Земли, то есть описывала явление. Если же мы оказались, например, на Меркурии или Марсе, то земную птолемеевскую систему нам пришлось бы упразднить и заменить новой.
Система Коперника сумела схватить сущность взаимного движения планет Солнечной системы. Такое описание, говоря современным языком, уже не зависело от того, какую планету в качестве системы отсчёта захочет выбрать себе наблюдатель.
С точки зрения теории познания объективной истины теологи совершали грубейшую ошибку: они сущность подменяли явлением. Наблюдаемое с Земли движение планет по небосводу они считали их действительным движением относительно Земли. .
В UML должно настораживать уже самое первое слово – «унифицированный». Не универсальный, то есть пригодный в большинстве случаев, а именно унифицированный, объединённый. Силами небольшого количества экспертов, если точнее, сначала двух, позже к ним присоединился третий, был создан сборник, содержащий наиболее удачные нотации из их собственной практики. Сборник стали продвигать в массы, а за неимением лучшего, и в стандарты.
Стандарт получился несколько странным. В его названии присутствует слово «моделирование». Модель от картинки в графическом редакторе отличается наличием базового формализма, позволяющего проверить созданную конструкцию на непротиворечивость, а если повезёт, то и на полноту. Очень простой, но верный признак проблемы – отсутствие в инструменте моделирования команды «Проверить». И если условной кнопки «Check model» в панели не предусмотрено, то ваш CASE [112] является просто продвинутым редактором специализированной векторной графики с шаблонами генерации кода.
Для сравнения, в IDEF0 [113] проверка целостности имеется, что не даст аналитику нарисовать в своей модели возникающие из пустоты и пропадающие в никуда объекты. Концептуальная модель данных в любой нотации, ER [114] или IDEF1х, также обратит внимание проектировщика на «висячие» сущности, циклические связи и прочие моменты, скорее всего, являющиеся ошибкой. На уровне логической модели данных (реляционная) к вышеназванным проверкам присоединятся новые, например, связанные с ограничениями типов (доменов), наличия ключей и другие. UML работает на логическом уровне.
Пишу я об этом вовсе не потому, что IDEF-стандарты такие крутые, несмотря на то, что системные аналитики ими часто пользуются. Просто небольшой сравнительный пример из закромов собственной практики.
Наконец, главное слово, «язык». Графические образы – это, конечно, аналог слов, но не всякий набор слов является языком. Поэтому UML до языка ещё далеко. Язык, даже естественный, можно автоматически проверить на формальную правильность. Входящий в UML OCL хоть и является языком, но выполняет лишь малую часть работы по проверке, и не собственно модели, а её элементов. А о способностях проверить модель написано выше.
Всё сказанное не должно вас смущать и поражать новизной. Ведь и XML тоже не язык, несмотря на соответствующую букву в аббревиатуре, а технология создания языков пользователя на базе разметки и формальных правил её проверки посредством DTD или схем.
Итак, UML:
• не универсальный, а унифицированный, объединяющий отдельные практики;
• не язык, а набор нотаций (графических);
• не моделирования, а в основном рисования иллюстраций, поясняющих текст многочисленных комментариев.
Поэтому использование UML имеет две основные альтернативы, напрямую зависящие от целей:
• Цель – использовать «как есть». Не заниматься вопросами целостности, ограничившись рисованием частей системы в разных ракурсах. Если повезёт, то часть кода можно будет генерировать из схем.
• Цель – использовать для моделирования и генерации кода. Придётся создать свои формализмы, соответствующие моделируемой области. В самом минимальном варианте – использовать в принудительном порядке стереотипы и написанные руками скрипты и ограничения для проверки непротиворечивости такого использования. Чтобы, например, стереотип «Водитель» в рамках ассоциаций «Управление машинами» был связан только с классом, реализующим интерфейс «Транспортное средство».Во втором случае формализация модели является, по сути, созданием предметно-ориентированного языка, то есть серьёзной исследовательской работой вплоть до уровня научной диссертации. Далеко не каждая софтостроительная фирма может позволить себе вести такие работы без ясных перспектив тиражирования своих продуктов.
Поэтому в большинстве ситуаций программисты находятся в «случае номер один», да и то не всегда. Потому что вместо «порисовали картинки и пиши код» все может ограничиться «пиши код и не отвлекайся на теории яйцеголовых».
С картинками в UML сложилась некоторая неразбериха вкупе с излишествами. Например, диаграммы деятельности (
У Киплинга есть замечательный рассказ «Как было написано первое письмо». Про неудачный опыт использования графической нотации первобытными людьми. Но если в рассказе все закончилось хорошо, то в современном проекте была ситуация, когда двум проектировщикам по отдельности поручили делать диаграммы переходов для одного и того же набора классов. Получилось очень «унифицированно»: найти хотя бы одну пару общих элементов в двух диаграммах было затруднительно. Если методология проектирования действительно существует, то работа двух людей даёт сопоставимый результат.
С другой стороны, для фиксации знаний программиста о предметной области основой являются прецеденты, варианты использования (. .Диаграмма прецедентов показывает деловые субъекты, деловые прецеденты, пакеты деловых прецедентов и связи между ними. Никаких строгих правил относительно того, что нужно показывать в диаграммах прецедентов, не существует. Вы показываете те связи в модели, которые считаете интересными. .
Столь длинное вступление к главе напрямую связано с так называемым анализом прецедентов в UML. Это идеальный инструмент для создания птолемеевых систем. Только если модель Птолемея является геоцентрической, то прецеденты использования – модель заказчико-центрическая.
Прецеденты, как и геоцентрическая модель, могут удовлетворительно описывать явление, не касаясь его сущности. Всякий раз разработчики очередного корпоративного приложения создают свою «птолемеевскую систему», которая при попытке примерить ее на другую фигуру внезапно оказывается неподходящей и нуждается в серьёзной перекройке. Так и земная птолемеевская система не работает для наблюдателя, находящегося на Марсе. Если же прецеденты рисуются коллективом, то будет уместно также вспомнить притчу про слона и семь слепых мудрецов, так и не пришедших к единогласию о том, что же они на самом деле ощупывают.
Поделиться книгой: