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

Это окончание невероятной информации про .

...

программистом и "нулями".

И здесь надо отметить сразу два "надсистемных эффекта":

• Каждая инструкция языка высокого уровня стала "еще мощней", т.е. компилировалась "сразу в десятки машинных команд".

• Инструкция языка высокого уровня понималась целиком, а операторы, входящие в инструкцию сами по себе (вне ее контекста), не имели смысла. Подобно тому, как в литературе обладают своим смыслом целиком фраза или стихотворение, а слова, их образующие, этим смыслом не обладают [9].

В результате исчезло соответствие между теми командами, которые пишет программист, и теми командами, которые исполняет процессор.

Как известно, это позволило создавать языки, «заточенные» под предметную область:

• Фортран - для решения инженерных задач и научных расчетов.

• Кобол - для решения экономических задач.

• Алгол-68, Паскаль - для обучения студентов программированию.

• Бейсик - для написания диалогов пользователя с ЭВМ.

• Си - для написания операционных систем, трансляторов, баз данных и других системных и прикладных программ.

• Пролог - для методов автоматического доказательства теорем.

• Ада - для моделирования параллельного решения задач. [7]

Изобретение языков высокого уровня позволило осуществлять перенос программы с машины на машину. И это позволило программисту (пишущему на высоком уровне) "не знать" или "знать минимально" устройство машины. Как бы сказали теперь, эти языки "инкапсулировали" (закрыли) "устройство машины" от программиста. Стали "интерфейсом" между программистом и компьютером.

• Затем произошел четвертый надсистемный переход: "структурное программирование" вытеснило "линейное". Программа стала пониматься как группа (читай: "надсистема") модулей, которые можно писать отдельно, а проектирование в значительной степени стало пониматься как проектирование интерфейсов для общения модулей.

• Затем произошел пятый надсистемный переход: впрочем, дальнейшую логику вдумчивый Читатель продолжит сам.

Если же поглядеть "через микроскоп" только на эволюцию языков высокого уровня, мы увидим в ином контексте те же эффекты:

• Языки первого поколения (FORTRAN I, ALGOL58, Flowmatic, IPL V) - это ассемблерные команды, которые группируются в вычислительные операции (сложение, вычитание, умножение, деление, присваивание). Программа, написанная на этих языках – это набор вычислительных операций.

• Языки второго поколения (FORTRAN II, ALGOL 60) - это уже вычислительные операции, которые выносятся в процедуры. Программа, написанная на этих языках - это набор процедур. (Как здесь, так и ниже "надсистемный переход" [2] очевиден.)

• В языках третьего поколения (ALGOL 68, Pascal)появилась абстракция данных: простые типы данных группируются в сложные типы данных (структуры). Программа, написанная на этих языках - это набор типов данных и операций над ними.

• Языки третьего поколения (Modula, C) - это средства для группировки процедур в модули. Программа, написанная на этих языках - это набор модулей.

• Языки третьего и четвертого поколений (Simula, Smalltalk, C++, Eiffel) - это средства для группировки процедур и простых типов данных в классы и объекты. Программа, написанная на этих языках - это набор классов и объектов.

#Ь ДО ДИЕЗ И МИ БЕМОЛЬ. НЕ НАДО ПРОСКАКИВАТЬ ПОЛУТОНА – В ЭТОМ СОЛЬ

А теперь вновь спустимся на землю. Предположим, разработчик пишет (сегодня!) некоторую программу. Не будем рассматривать логику программы и не будем рассматривать задачи, которые она призвана решить, а зафиксируем следующие системные уровни:

• Уровень 1. Код

• Уровень 2. Программный модуль

• Уровень 3. Типовой модуль (например, подпрограмма, класс, объект)

• Уровень 4. Группы близких, но неодинаковых на 100% "типовых модулей". Для их группировки "изобретают контекст", либо злоупотребляют "полиморфным наследованием".

• Уровень 5. Наборы из (2х, 3х, 4х...) "типовых модулей", объединенных общим контекстом (замыслом). Например, "паттерны проектирования" [12] или иное. (Об ином в следующих публикациях.)

• Уровень 6. Вся программа.

Неважно, какую среду программирования и какой язык использует разработчик. В контексте данного материала важно то, что он думает над проектом, понимая его как набор сущностей третьего или четвертого уровня, куда он в процессе работы добавляет сущности уровня 1, 2 и 3.

А потом из этих сущностей уровня "1,2,3" он пишет сразу объект уровня 6 (программу), совершая, тем самым, "проскок уровней".

Проявления данной ошибки в логике проектирования нам уже известны - "многофакторность и противоречивость", а проще говоря - "сложность и глючность" программ.

Коллеги иногда делают замечание о том, что "паттерны проектирования" [12] как раз иллюстрируют нам уровень, который ранее проскакивали. Мы пока и не спорим, просто стараемся показать общую картину.

ФА. ПРО ВЕРХ И ПРО НИЗ. НЕ ТОЛЬКО ЛИРИЧЕСКОЕ ОКОНЧАНИЕ

Действительно, создать качественную программу "из объектов", двигаясь "снизу вверх" (от подсистем к системе; от реализации к проекту), можно только при условии предельной простоты такой программы.

Однако, похоже, существует инерция мышления, оставшаяся с тех времен, когда все писали на низком уровне, и мысли о реализации неизбежно занимали наибольший промежуток времени. И многие программисты (конечно, не все) часто думают "снизу вверх". Больше над реализацией, чем над проектом.

Но, например, хороший архитектор никогда не проектирует дом "из квартир", а думает о нем сразу "в целом", "вписывает" в контекст окружающей среды, пользуется знаниями о готовых "стилях" (или создает свой стиль, зная о других). Хороший авиаконструктор не проектирует новый самолет "из его элементов", но пытается понять, как машина "летает в целом", или отталкивается от "принципов полета этого класса машин" и т.д., и т.п.

Мышление "снизу вверх" сродни попытке сложить организм из атомов углерода и водорода. Теоретически так сделать можно, но очень уж "многофакторно" и затратно как по времени, так и по ресурсам. И все равно, несмотря на затраты и при квалифицированной работе, получится урод + "теория неизбежности ошибок" вместо качественного продукта. За исключением, может быть, тех случаев, когда "организмом" (перепутав термины) назвали что-то предельно простое (например, 1 звено СН).

Для того, чтобы "сложить организм", надо представить его в целом и понять иерархию его качественных уровней.

• Уровень Организма

• Уровень Систем (нервная, пищеварительная … и т.д. …)

• Уровень Органов

• Уровень Клеток

• Уровень ДНК, белков

• Уровень Аминокислот

• .... и т.д. ....

(Наверняка, что-то пропущено, но сейчас дело не в этом).

• ... и т.д. где-то внизу дойдем до "простейших" углерода и водорода.

С проектной точки зрения, надо смотреть "сверху вниз" и не надо проскакивать системные уровни. Не стоит, например, пытаться строить органы из белков, минуя построение клеток - резко возрастают требования к квалификации "строителя" без какой-либо гарантии качества (наоборот, "глючность" вырастет независимо от квалификации). Аналогично: можно написать графический редактор и в машинных кодах, но лучше не надо.

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

Приведем характерную цитату из Г.С. Альтшуллера (Автора ТРИЗ), сказанную по другому поводу, но дающую точную аналогию:

"Сверхцивилизация мыслится на уровне общества, но только более развитого, более энергетически вооруженного. А на самом деле сверхцивилизации должны быть этажом выше, на уровне надобщества. Может ли отдельная клетка рассчитывать на то, что именно ее будет специально искать (для установления контакта!) организм? [1]

То есть сверхцивилизация не ищет нас потому, что мы инкапсулированы в каком-то подклассе :-). И ей это просто "по барабану". Так, пользователь компьютера не интересуется программным кодом. Или: девушка любит юношу, но ей безразличны его аминокислоты.

Совсем уж вернемся к программированию.

Программистам, даже и при создании конкретной программы, важно постоянно держать в памяти следующее: как минимум, одна из закономерностей развития их отрасли - это "надсистемные переходы" (см. также переходы по "этажной схеме") [1].

При этом каждое следующее серьезное изобретение в области программирования - это почти всегда изобретение следующего интерфейса (это и есть "этаж") между системными "слоями":

• Изобретение операционной системы - это изобретение интерфейса между машиной и приложениями. Операционная система инкапсулирует в себе соотв. функции.

• Изобретение языков программирования (например, ассемблера) - это изобретение интерфейса между кодом и человеком. Язык инкапсулирует в себе код.

• Изобретение языков более высокого уровня - то же самое на следующей стадии.

• Изобретение объектно-ориентированного программирования - это попытка создать интерфейс между функциями ("методами") и разработчиком.

• Поэтому нынешнее явление миру "шаблонно-ориентированного программирования" [12, стр 163] - совершенно закономерный надсистемный переход от "объектов" и "классов" к их готовым контекстным сочетаниям.

• Наверное, закономерен и дальнейший переход от "мышления отдельными шаблонами" к мышлению их готовыми сочетаниями (готовыми надсистемами из шаблонов). Давайте назовем эти готовые сочетания шаблонов "стилями". И тогда будет переход к "стильному программированию".

Характерна цитаты из [12, стр 178]: "Шаблоны высшего уровня ограничивают шаблоны низшего".

Вот-вот, оно самое. Но красивее будет сказать: "Стили инкапсулируют шаблоны, как шаблоны инкапсулируют классы и объекты, как классы инкапсулируют объекты и методы (функции)".

А еще лучше смотреть сразу на всю эту закономерность в целом. И проектировать (совершенствовать) даже конкретную программу "методом уяснения ее иерархии и продвижения дальше по закономерности". См. еще раз первые три примера.

Совершенно (в этот момент!) можно не думать о реализации (она сама упростится, если следовать данному правилу). Назовем это "тенденциозным программированием".

Однако чтобы не уйти в философию, на этом и остановимся.

ЛИТЕРАТУРА:

• Альтшуллер Г.С. Структура талантливого мышления.

• Сычев С.В., Лебедев К.А. Как вспомнить "и так известное".

• Сычев С.В., Лебедев К.А. Освобождение узников оператора "IF".

• Сычев С.В., Лебедев К.А. Что увидишь, то и неси (в статье "TStupid, или Новейший органон").

• Сычев С.В., Лебедев К.А. Неважно, где рисовать(в статье "TStupid, или Новейший органон").

• Сычев С.В., Лебедев К.А. Пусть само проявится (в статье "TStupid, или Новейший органон").

• Алексеев Е.Г. Электронный учебник по информатике.

• Alf. История языков программирования. Часть I.

• Лео Броди. Способ мышления – Форт. Язык и философия для решения задач, глава 1 "Философия Форта".

• Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд./Пер с англ. М.: "Издательство Бином", СПб: "Невский диалект", 1998 г. Или электронная версия.

• Александр Костинский, Владимир Губайловский. Эволюция языков программирования.

• Алан Шаллоуей, Джеймс Р. Тротт. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию: Пер.англ. М.: Издательский дом "Вильямс" 2002. 288 с.: ил.

• Реферат на тему "Языки программирования. Их классификация и развитие".

Материал опубликован на сайте "Открытые методики рекламы и PR "Рекламное Измерение" 23 января 2007 г.

Закажите нам разработку бизнес-процессов Вашей компании.

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

Последнее обновление: 31.10.2015

В этой теме и ряде последующих материалов мы рассмотрим трехуровневую архитектуру приложения ASP.NET MVC и ее возможную реализацию.

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

Тут сразу надо сказать, что многоуровневой архитектурой часто обозначают два не совсем связанных понятия: n-layer и n-tier. И layer, и tier, как правило, обозначаются словом "уровень", иногда по отношению к "layer" еще употребляется слово "слой". Однако в обоих случаях уровни будут разного порядка.

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

Layer представляет логический уровень. То есть у нас может быть уровень доступа к данным, уровень бизнес-логики, уровень представления, уровень сервисов и так далее. При этом логические уровни не совпадают с физическими. Так, обычно уровень предоставления в приложении ASP.NET содержит и контроллеры, которые обрабатывают ввод, и представления, которые отображаются в веб-браузере, то есть разделяется на два физических уровня.

В данном случае мы будем говорить именно о логических уровнях, то есть о n-layer архитектуре.

Классическая трехуровневая система состоит из следующих уровней:

Presentation layer (уровень представления): это тот уровень, с которым непосредственно взаимодействует пользователь. Этот уровень включает компоненты пользовательского интерфейса, механизм получения ввода от пользователя. Применительно к asp.net mvc на данном уровне расположены представления и все те компоненты, который составляют пользовательский интерфейс (стили, статичные страницы html, javascript), а также модели представлений, контроллеры, объекты контекста запроса.

Business layer (уровень бизнес-логики): содержит набор компонентов, которые отвечают за обработку полученных от уровня представлений данных, реализует всю необходимую логику приложения, все вычисления, взаимодействует с базой данных и передает уровню представления результат обработки.

Data Access layer (уровень доступа к данным): хранит модели, описывающие используемые сущности, также здесь размещаются специфичные классы для работы с разными технологиями доступа к данным, например, класс контекста данных Entity Framework. Здесь также хранятся репозитории, через которые уровень бизнес-логики взаимодействует с базой данных.

При этом надо отметить, что крайние уровни не могут взаимодействовать между собой, то есть уровень представления (применительно к ASP.NET MVC, контроллеры) не могут напрямую обращаться к базе данных и даже к уровню доступа к данным, а только через уровень бизнес-логики.

Уровень доступа к данным не зависит от других уровней, уровень бизнес-логики зависит от уровня доступа к данным, а уровень представления - от уровня бизнес-логики.

Компоненты, как правило, должны быть слабосвязанными (loose coupling), поэтому неотъемлемым звеном многоуровневых приложений является внедрение зависимостей.

При чем об ASP.NET MVC мы говорим прежде всего применительно к уровню представления, остальные же уровни могут быть реализованы независимо и могут использоваться в приложениях на других технологиях, как Windows Forms, WPF и т.д. И, как правило, все приложение в целом будет представлять решение (solution) в Visual Studio, а отдельные уровни - проекты. В то же время неверно полагать, что если уровень обязательно должен соответствовать отдельному проекту. При необходимости мы можем раздробить один уровень на несколько проектов, главное, чтобы его функционал представлял единое логическое звено.

И теперь создадим веб-приложение, которое будет разделено на три уровня.

Продолжение:

Часть 1 Многоуровневая архитектура
Часть 2 Многоуровневая архитектура - Многоуровневая архитектура