Интерпретация книги Дэвида Парнаса «О критериях, которые следует использовать при разложении систем на модули»
Я написал эту статью, чтобы помочь объяснить знаменитую академическую статью 1971 года Дэвида Парнаса в более удобоваримой форме. Надеюсь, кому-то это пригодится.
Мороженое и системный дизайн
Сегодня мы собираемся представить проектирование линии по сборке сэндвичей с мороженым как пример проектирования программных систем.
В статье Парнаса объясняется, что при попытке спроектировать сложную систему, такую как наш завод по производству мороженого, мы должны разбить фабрику на меньшие (размером с укус, если хотите) секции, которые он называет «модулями». Поскольку у нас есть большая группа инженеров, архитекторов и строителей, они не могут работать на одной и той же части завода одновременно. Слишком много поваров портят суп (или, в данном случае, мороженое)! Поэтому нам нужно разделить членов нашей команды на группы и назначить им свои конкретные задачи. В этом нам помогут четко определенные модули.
Идея разделения работы на более мелкие части не нова. Настоящий вопрос в том, как лучше всего разрушать системы?
Основной аргумент статьи Парнаса, помимо модульности систем, заключается в том, что мы должны реализовать концепцию, называемую «сокрытие информации», и объяснение того, что это означает. Идея сокрытия информации заключается в том, что мы должны создавать наши программные системы так, чтобы две системы были независимы от процессов друг друга; то есть процессу B все равно, как процесс A выполняет свою работу. Давайте вернемся к нашей фабрике мороженого, чтобы проиллюстрировать это.
Давайте обрисуем некоторые из возможных процессов на фабрике по производству сэндвичей с мороженым. Имейте в виду, что у меня нет опыта работы в отрасли, кроме интереса непрофессионала к рассматриваемой теме.
Я предполагаю, что поток процесса будет выглядеть примерно так, в каждой системе будет несколько процессов:
1. Flour, sugar, yeast, milk, eggs, chemicals, flavorings, etc… are delivered to the factory. a. Ingredients are separated into ice cream and cookie staging areas. 2. The sandwich cookie ingredients are mixed together and baked. a. Ingredient mixing b. Cookie baking c. Quality control d. Moved to ice cream line for filling 3. The ice cream ingredients are mixed together and cooled to the temp for magical ice cream consistency. a. Ingredient mixing b. Cooling process c. Quality control 4) Cookies are filled with ice cream a. Ice cream injection process b. Excess ice cream wiped off 5) Quality control a. Yuuuum! 6) Sandwiches are individually wrapped 7) Sandwiches are boxed 8) Boxes are stacked on pallet 9) Pallet is stored in freezer 10) Pallet is retrieved and put on truck to distribution center. 11) DONE
Я, возможно, переборщил с этим описанием, но мельчайшие подробности помогут нам в нашей аналогии.
Проблемы, связанные с утечкой информации
Теперь предположим, что вся производственная линия автоматизирована, или, по крайней мере, производственные рабочие очень буквальны и не очень гибки. Ни роботы, ни люди не умеют критически мыслить и, по сути, выполняют свои задачи в точности в соответствии с приказом. Единственная возможность сделать эту систему гибкой - это очень внимательно подходить к разработке первоначального набора инструкций.
Например, простой способ - настроить каждую машину так, чтобы размер файлов cookie был 25 мм x 75 мм ». Вы знаете, что это правильный размер, поскольку вы провели серию встреч на высоком уровне с руководителями, которые категорически заявили вам, что это лучший размер и что размер никогда не изменится.
Однако что, если они действительно изменятся? Проведено маркетинговое исследование, и выяснилось, что квадратные бутерброды в моде. Если вы попытаетесь просто и быстро модифицировать машину для выпечки печенья, вы получите катастрофические результаты! Машина для розлива мороженого, излишки салфетки, упаковочная машина, сама упаковка - все это не того размера! Единственный способ изменить размер сэндвича - это заменить каждую машину в системе.
Что, если вы захотите изменить тип индивидуальной упаковки каждого сэндвича? Выглядит достаточно безобидно, но вы можете не осознавать, что новая бумага намного толще, и бутерброды больше не помещаются в коробку! Теперь вы должны сконфигурировать несколько машин, упаковочную машину, упаковочную машину, паллетизатор (так как коробки уже не одного размера) и т. Д.… Чтобы разрешить одно небольшое изменение процесса. Это одно небольшое изменение процесса может даже вызвать серьезные сбои, если такое же количество ящиков больше не умещается на поддоне, поскольку грузовик имеет ограниченное пространство для поддонов, может возникнуть нехватка места для грузовых автомобилей для выполнения постоянного заказа! Потребуется привезти дополнительные грузовики; начислены обвинения в срочности. Это может быстро стать дорогим!
Устранение утечки информации
Как бы мы построили эту систему, чтобы никогда не возникало подобных проблем? Что ж, мы хотим выполнить сокрытие информации. Мы хотим, чтобы каждый процесс был полностью независим от другого. В наших примерах мы построим каждую машину так, чтобы она автоматически подстраивалась под размер файла cookie. Эти машины будут сканировать файл cookie, определять его размер и избегать проблем, связанных с ошибкой размера файла cookie. Более того, боксерский автомат не будет строить коробку, пока не определит, насколько велики бутерброды во время текущего прогона. Только после этого он выберет конкретный размер коробки, соответствующий входящим бутербродам. Точно так же будут выполнять свои задачи и другие машины, расположенные ниже по потоку.
Представьте, что ваши рабочие-люди отказались намазывать мороженое на бутерброды, потому что раньше вы несли им печенье вручную, а теперь поставили коробку на тележку. Им не нужно знать об изменении формулы, изменении температуры или о чем-то еще. Все, что им нужно сделать, это намазать мороженое. Изменения одного процесса (модуля) не должны влиять на другой.
Очевидно, что проектирование самоуправляемых машин сложнее, чем просто жестко закодировать в них значения, но мы здесь не для того, чтобы отправиться на пикник. Скорее, мы здесь для того, чтобы создавать надежные, простые в использовании и легко обслуживаемые системы.
Хорошим аналогом примера оберточной бумаги в программной системе может быть жесткое кодирование для определенного типа файла или формата данных. На очень простом уровне, если вы объявляете переменную с использованием определенных типов, таких как `int x = input;`, эта входная переменная может измениться в будущем и вызвать ошибки. Вместо этого использование универсальных типов переменных, таких как `var x = input;`, позволило бы типу данных восходящего потока измениться с `int` на` decimal` от поставщика данных, и вы могли бы даже не знать об этом. Очевидно, что это упрощенный пример, но он иллюстрирует то, что мы должны попытаться построить наши процессы независимо друг от друга, насколько это возможно.
Правильное проектирование
Затем профессор Парнас обсуждает недостатки классического метода проектирования системы, когда он садится и рисует блок-схему.
Блок-схемы полезны при попытке разделить большую систему на модули (декомпозиция или модуляризация), но не для проектирования системы, которая реализует скрытие информации. Такой код является более гибким и более пригодным для повторного использования, поскольку реализация каждого класса скрыта от других, что предотвращает сильносвязанные классы. Если мой упаковщик мороженого реализует скрытие информации, я также могу без проблем отправлять ему батончики мюсли.
