You get a bonus - 1 coin for daily activity. Now you have 1 coin

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

Lecture



© Сергей Сычёв, TRIZ-RI Group, Кирилл Лебедев, г. Санкт-Петербург

О ПОТЕРЯННОМ УРОВНЕ

Приложения ТРИЗ к программированию

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


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


Многоуровневая архитектура ДО. ТРИ ПОХОЖИХ И НЕПОХОЖИХ ПРИМЕРА

Приступим к ним без вступлений.

ПРИМЕР 1. УЧЕСТЬ НЕУЧИТЫВАЕМОЕ. (ПРО РАЗГРАНИЧЕНИЕ ДОСТУПА К ОДНОМУ САЙТУ.)

Предположим, надо предоставить разные уровни доступа разным Посетителям Web-сайта:

  • то, что может видеть любой Посетитель сайта;

  • то, что может видеть любой Посетитель, который зарегистрировался;

  • нечто дополнительное, что может видеть любой зарегистрировавшийся Посетитель из Москвы, но не должны видеть другие Посетители, независимо от того, зарегистрировались они или нет;

  • иное дополнительное, что могут видеть конкретные Посетители Иванов, Петров, Сидоров и т.д., которые зарегистрировались, но это не должны видеть все иные Посетители;

  • то, что может видеть VIP-Посетитель, которому специально подбираются темы, и при этом надо сделать так, чтобы его случайно не коснулись ограничения (например, если он не из Москвы и ему можно видеть то же, что Петрову);

  • то, что может видеть зарубежный посетитель, если он не VIP и ….. обострим задачу….

  • ….. и т.д. ….. вплоть до комбинаторного взрыва….

Как видим, основания для соответствующих разграничений очень разные. Модельно: А,В,7,©,§, W.... – т.е. «вдоль оси не ложатся». Поэтому разработчики не смогли их проиндексировать однородно.

Возникла "многофакторность" и долгие размышления на тему о том, какие критерии выбрать.

Бесспорно, всегда можно о чем-то договориться, но мы обострим противоречие [2] и введем следующее условие: "что бы мы ни придумали, позже непременно появится ранее неучтенное требование, которое испортит предыдущие правила".

Как быть?

ПРИМЕР 2. РАЗДЕЛИТЬ НЕРАЗДЕЛИМОЕ. (ПРО УПОРЯДОЧЕНИЕ СООБЩЕНИЙ И ТЕМ НА ФОРУМЕ.)

Один из Интернет-Форумов поначалу имел следующую иерархию:

o Форум
o Темы Форума
o Сообщения в Темах Форума

Например,

o Форум "О строительстве и архитектуре"
o Тема "Информация по стеновым панелям"
o Тема "Паттерны архитектуры"
o Тема "Ищем вменяемого прораба"
o Тема "О технологиях строительства без глупостей"
o Тема "А как Вы взаимодействуете с генподрядчиком?"
o Тема "В теории архитектуры наблюдается застой!"
o ……и т.д.……………………………………………………………..
o Тема "Кто подскажет, где найти библиотеку СНиП’ ов?"
o Сообщения в Темах Форума (здесь их приводить не будем)

Нетрудно заметить, что получилась "портянка", каких много в сети. Пока "Тем" было мало, с этим мирились, а когда их стало много, начали группировать "Темы" в "Категории":

o Форум
o Категории (группы "Тем")
o Темы Форума
o Сообщения в Темах Форума

Например,

o Форум "О строительстве и архитектуре"
o Категория "Теория архитектуры"
o Тема "Паттерны архитектуры"
o Тема "В теории архитектуры наблюдается застой!"
o …………….
o Категория "Взаимодействия с подрядчиками"
o Тема "Ищем вменяемого прораба"
o Тема "А как Вы взаимодействуете с генподрядчиком?"
o …………….
o Категория "Технология строительства»
o Тема "О технологиях строительства без глупостей"
o Тема "Кто подскажет, где найти библиотеку СНиП"
o Тема "Информация по стеновым панелям"
o ………………
o Категория "… и т.д. N…"
o Тема "………"
o Тема "………"
o ………………
o Категория "Разное"

Поначалу было удобно. Однако, по мере роста проекта, начали происходить следующие эффекты:

Эффект 1. Все большее и большее число "Тем" стало необходимо относить к нескольким "Категориям" сразу.

Например,

  • Тема "О паттернах архитектуры в стране невменяемых прорабов, нарушающих технологию";
  • Тема "Проблемы взаимодействия с подрядчиками – это продолжение общего российского беспредела или … ?"
  • … и т.д., и т.п. …

Эффект 2. Внутри одной "Темы" (скажем, популярной с большим числом сообщений) почти всегда, по факту, начали смешиваться несколько "Тем".

Например, Пользователи начинали с "застоя в теории архитектуры", а потом - в контексте обсуждения - логично переходили на смежные "Темы": "о том, как учат в наших ВУЗ’ах", "О критериях оценки архитектурных идей" и т.д. А затем они вновь могли обратиться к "застою" или к любому иному смысловому фрагменту.

"Разорвать" такое обсуждение на несколько "Тем" не получится – разорвется контекст.

И если для решения задач, вызываемых эффектом 1, можно было "Тему", которая относилась к нескольким "Категориям", отображать во все эти Категории (а когда таких "Тем" становилось много, 'Категории" переименовывать и/или заводить новые), то для решения задач, вызываемых эффектом 2, сходу решения найдено не было.

Традиционно обострим задачу и запишем: "Всегда (по определению) будет возникать противоречие [2]: "разделить "Тему" надо и разделять ее нельзя".

Как быть?

ПРИМЕР 3. НЕ ЗАБЫТЬ ПОЗАБЫТЬ ИЗМЕНЕНИЯ. (О СОПРОВОЖДЕНИИ БАЗЫ ДАННЫХ.)

"По наследству" досталась база данных, состоящая из N таблиц. Каждая таблица содержит записи, каждая запись характеризуется уникальным идентификатором. Записи из разных таблиц могут иметь одинаковые идентификаторы.

Для получения конкретных данных предыдущими разработчиками был создан единый класс CTableString,

int nTableStringID;
CTableString TableString;
//...
Таблица_Наименование.ПолучитьЗапись(nTableStringID, TableString);

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

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

Обострим задачу: пусть количество разных таблиц изменяется в базе данных довольно часто и непредсказуемо для разработчика. Но при этом вызывающий код пусть не меняется вовсе.

Мы уверены, что большинство Коллег уже знает решение, а как насчет первых двух примеров?


Многоуровневая архитектураРЕ. ТРИ ПОХОЖИХ И НЕПОХОЖИХ РЕШЕНИЯ

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

Разработчику, который думает над тем, как "устаканить многофакторное", надо:

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

  • Построить иерархию

  • Найти пропущенный уровень и реализовать его

  • Все "многофакторное и противоречивое" на одном уровне сгруппировать на следующем

РАЗБОР ПРИМЕРА 1. НЕ УЧИТЫВАЕМ, А ГРУППИРУЕМ

Так, решение первой задачи заключается в том, чтобы:

  • Прекратить бороться с многофакторностью и/или думать над тем, какие критерии "правильные"... (прекратили)

  • Ввести понятие группы прав", которые можно создавать по любым основаниям (то есть совершить "надсистемный переход" [2]) и соответствующие правила формулировать для "группы"

  • Пользователя (который регистрируется на сайте) помещать в соответствующую "группу" либо создавать отдельную "группу прав" для данного Пользователя.

  • При необходимости в пределах каждой "группы" линейно разграничивать права разным Участникам.

  • Индексировать

Например, было так:

  • "Посетители из Москвы":

    • Михайлов

    • Петров (попал в два контекста с разными правами и потому чего-нибудь не увидит)

    • Колобков

    • Иванов

    • Медведев

    • ………

  • "Любители темы "Занимательный буддизм"

    • Иванов

    • Петров (попал в два контекста с разными правами и потому чего-нибудь не увидит)

    • Сидоров

    • Джонсон (попал в два контекста с разными правами и потому чего-нибудь не увидит)

    • ……………...

  • "VIP’ы"

    • Колобков

    • Волков (он не из Москвы и потому может попасть под соотв. ограничение, а VIP’ы не должны под него попадать)

    • Медведев

    • ………………

  • "Иностранцы"

    • Джонсон (попал в две группы с разными правами и потому чего-нибудь не увидит)

    • Буш

    • Картер

    • ………………

Стало так:

  • Группа прав 1 "Права этих людей"

    • Иванов

    • Петров

    • …………………………………..

  • Группа прав 2 "Права этих людей"

    • Волков

    • ……………………………………..

  • Группа прав 3 "Права этих людей"

    • Джонсон

    • ……………………………………..

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

РАЗБОР ПРИМЕРА 2. ГРУППИРУЕМ, ЧТОБЫ РАЗДЕЛИТЬ НЕ РАЗДЕЛЯЯ

Предположим, в какой-либо "Теме" произошел Эффект 2. (см. выше). И мы столкнулись с противоречием: "разделить "Тему" надо и разделить ее нельзя".

Проиллюстрируем:

Внутри одной "Темы" стали по факту смешиваться несколько "Тем". Приведем "условную портянку":

Тема "Застой в теории архитектуры"

Автор: Иванов Кому: Всем
В теории архитектуры наблюдается застой… Он выражается в том, что …

[ответить] [новое сообщение для всех] [все ответы на это сообщение]
От: Петров Кому: Иванов Дата: 07.10.2004 16:15:53
Не согласен, прочитайте, например, исследование «Каменные мозги».

[ответить] [новое сообщение для всех] [все ответы на это сообщение]
От: Сидоров Кому: Иванов Дата: 07.10.2004 17:13:26
На какой выборке сделан Ваш вывод?

[ответить] [новое сообщение для всех] [все ответы на это сообщение]
От: Иванов Кому: Сидоров Дата: 08.10.2004 11:24:29

На какой "выборке" сделан ваш вывод?


Какая выборка? Оглянитесь вокруг.

[ответить] [новое сообщение для всех] [все ответы на это сообщение]
От: Сидоров Кому: Иванов Дата: 08.10.2004 12:01:53

Какая выборка? Оглянитесь вокруг.


Тогда надо писать: в архитектуре наблюдается застой, а не в теории...
В теории как раз традиционно все ОК.

[ответить] [новое сообщение для всех] [все ответы на это сообщение]
От: Петров Кому: Сидоров Дата: 08.10.2004 12:10:05
Дело не в теории. Просто в ВУЗах плохо учат...

[ответить] [новое сообщение для всех] [все ответы на это сообщение]
От: Козлов Кому: Петров Дата: 08.10.2004 13:17:45

Просто в ВУЗах плохо учат...


В ВУЗах учат нормально. Просто все из страны бегут.

[ответить] [новое сообщение для всех] [все ответы на это сообщение]
От: Петров Кому: Козлов Дата: 08.10.2004 13:25:37

В ВУЗах учат нормально. Просто все из страны бегут.


Что значит нормально? Какие у Вас критерии?

[ответить] [новое сообщение для всех] [все ответы на это сообщение]
От: Волков Кому: Всем Дата: 08.10.2004 13:30:26
Вопрос о критериях очень интересен. А до тех пор, пока эту тему не затронули, было скучно читать. И важно говорить не столько о критериях обучения, сколько о критериях качества архитектурных решений. Вот что я предлагаю:

++++++++++
--------------------
.....................


[ответить] [новое сообщение для всех] [все ответы на это сообщение]
От: Петров Кому: Волков Дата: 08.10.2004 15:19:59
Нет, эти критерии некорректны!

[ответить] [новое сообщение для всех] [все ответы на это сообщение]
От: Волков Кому: Петров Дата: 09.10.2004 10:20:42

Нет, эти критерии некорректны...


А если так:

+++++++++++++++
+_+_+_+_+_+_+_+_
--++--++--++--++--++

Что скажете?

[ответить] [новое сообщение для всех] [все ответы на это сообщение]
От: Иванов Кому: Волков Дата: 09.10.2004 10:27:05
Это интересно, конечно, но, что Вы скажете по теме? Считаете ли Вы, что застой в теории архитектуры все же есть..?

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

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

  • В теории архитектуры наблюдается застой

  • Хорошо ли учат в ВУЗах архитектуре?

  • О критериях качества архитектурных решений

Но поскольку все они встроены в контекст одного обсуждения (участники Форума общаются друг с другом), то на несколько "Тем" их не разорвать.

Решение заключается в разделении "Темы" на смысловые "Нити" с последующим помещением всех этих "Нитей" в общий контекст "Обсуждения-аналоги":

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

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

Теперь, если нажать на "Корень", то увидим все сообщения подряд, как выше. А если на конкретную "нить", то увидим сообщения принадлежащие ей. См. ниже:

Тема "Застой в теории архитектуры"

Обсуждения-аналоги(нити)

Корень

В теории архитектуры наблюдается застой [сообщений: 6] [изм.: 09.10.2004 10:27:05] [открыта]

Хорошо ли учат в ВУЗах архитектуре?[сообщений: 4] [изм.: 07.10.2006 15:35:06] [прочитана]

О критериях качества архитектурных решений[сообщений: 4] [изм.: 07.10.2006 15:40:26] [прочитана]

[Добавить аналогичное обсуждение]


[ Присоединить нить к текущей ]

Авторы

Иванов

Петров

=>

Иванов

Сидоров

=>

Иванов

Иванов

=>

Сидоров

Сидоров

=>

Иванов

Иванов

=>

Волков

Автор: Иванов

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

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


От: Петров Кому: Иванов Дата: 07.10.2004 16:15:53

Не согласен, прочитайте, например, исследование «Каменные мозги».

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


От: Сидоров Кому: Иванов Дата: 07.10.2004 17:13:26

На какой выборке сделан Ваш вывод?

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


От: Иванов Кому: Сидоров Дата: 08.10.2004 11:24:29

На какой "выборке" сделан ваш вывод?

Какая выборка? Оглянитесь вокруг.

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


От: Сидоров Кому: Иванов Дата: 08.10.2004 12:01:53

Какая выборка? Оглянитесь вокруг.

Тогда надо писать: в архитектуре наблюдается застой, а не в теории... В теории как раз традиционно все ОК.

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


От: Иванов Кому: Волков Дата: 09.10.2004 10:27:05

Это интересно, конечно, но, что Вы скажете по теме? Считаете ли Вы, что застой в теории архитектуры все же есть...

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


[ в начало ]

Тема «Застой в теории архитектуры»

Обсуждения-аналоги (нити)

Корень

В теории архитектуры наблюдается застой[сообщений: 6] [изм.: 089.10.2004 10:27:05] [прочитана]

Хорошо ли учат в ВУЗах архитектуре?[сообщений: 4] [изм.: 08.10.2004 13:30:26] [открыта]

О критериях качества архитектурных решений[сообщений: 4] [изм.: 07.10.2006 15:40:26] [прочитана]

[Добавить аналогичное обсуждение]


[ Присоединить нить к текущей ]

Авторы

Петров

Козлов

=>

Петров

Петров

=>

Козлов

Волков

=>

Всем

Автор: Петров

Дело не в теории. Просто в ВУЗах плохо учат...

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


От: Козлов Кому: Петров Дата: 08.10.2004 13:17:45

Просто в ВУЗах плохо учат...

В ВУЗах учат нормально. Просто все из страны бегут.

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


От: Петров Кому: Козлов Дата: 08.10.2004 13:25:37

В ВУЗах учат нормально. Просто все из страны бегут.

Что значит нормально? Какие у Вас критерии?

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


От: Волков Кому: Всем Дата: 08.10.2004 13:30:26

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

++++++++++
--------------------
.....................

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


[ в начало ]

Тема «Застой в теории архитектуры»

Обсуждения-аналоги (нити)

Корень

В теории архитектуры наблюдается застой[сообщений: 6] [изм.: 09.10.2004 10:27:05] [прочитана]

Хорошо ли учат в ВУЗах архитектуре?[сообщений: 4] [изм.: 07.10.2006 15:35:06] [прочитана]

О критериях качества архитектурных решений[сообщений: 4] [изм.: 09.10.2004 10:27:05] [открыта]

[Добавить аналогичное обсуждение]


[ Присоединить нить к текущей ]

Авторы

Волков

Петров

=>

Волков

Волков

=>

Петров

Иванов

=>

Волков

Автор: Волков

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

++++++++++
--------------------
.....................

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


От: Петров Кому: Волков Дата: 08.10.2004 15:19:59

Нет, эти критерии некорректны!

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


От: Волков Кому: Петров Дата: 09.10.2004 10:20:42

Нет эти критерии некорректны...


А если так:

+++++++++++++++
+_+_+_+_+_+_+_+_
--++--++--++--++--++

Что скажете?

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


От: Иванов Кому: Волков Дата: 09.10.2004 10:27:05

Это интересно, конечно, но, что Вы скажете по теме? Считаете ли Вы, что застой в теории архитектуры все же есть...

[ответить] [новое сообщение для всех] [все ответы на это сообщение]

[создатьнить] [отображение ...] [удалить ]


[ в начало ]

Читатель обратил внимание и на две опции, расположенные слева на панели:

  • "Добавить аналогичное обсуждение" и

  • "Присоединить нить к текущей"

Первая позволяет начать новое обсуждение сразу в текущем контексте, если это органично. А вторая - присоединять близкие по содержанию обсуждения из других контекстов.

Выше был приведен условный пример. Ниже дана ссылка на одно из реальных обсуждений сети: "Как сделать так, чтобы вас заметили". Ссылка дана на Корень, однако, поглядите все нити слева на панели.

Таким образом, теперь иерархия Форума такая:

  • Форум

    • Категории (группы Тем)

      • Темы Форума

        • "Нити" обсуждений, собранные в группу "Аналоги" - ранее был "проскок" этого уровня

          • Сообщения в Темах Форума

Новая структура позволила ввести "контекстность" (например, группировку "Тем" и возможность оперирования уже укрупненной "группой" ("пачками тем", а не "темами"), свойства которой можно описать отдельно и др.).

РАЗБОР ПРИМЕРА 3. О СОПРОВОЖДЕНИИ БАЗЫ ДАННЫХ

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

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

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

Все запросы вызывающий код всегда направляет классу ДиспетчерБазы (где есть СправочникТаблиц с их идентификаторами), а тот, в свою очередь, перенаправляет их конкретной таблице.

Раньше мы имели только идентификатор (целое число) записи в конкретной таблице, и вызывающий код должен был знать о том, какой таблице его передать. Теперь он этого не знает и знать не должен, поскольку с таблицами общается класс ДиспетчерБазы. (А ранее был проскок этого уровня.) Поэтому в качестве идентификатора будет выступать пара:

  • Идентификатор таблицы.
  • Идентификатор записи.

Эту пару можно "оформить" в новый класс СправочникИдентификаторов, где, собственно, справочник идентификаторов и будет находиться, и передавать его базе данных при запросе:

Запись = ДиспетчерБазы.ПолучитьЗапись(СправочникИдентификаторов);

Если нет желания создавать специальный класс, справочник идентификаторов можно "свернуть" в целое число. Например, задав для каждой таблицы свои диапазоны:

  • 1 - 1 000 000 - диапазон идентификаторов для 1-ой таблицы;

  • 1 000 001 - 2 000 000 - диапазон идентификаторов для 2-ой таблицы;

  • 2 000 001 - 3 000 000 - диапазон идентификаторов для 3-ей таблицы;

  • и т.д.

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

Но что общего мы находим во всех трех примерах? Причина каждой задачи это "проскок одного из системных уровней" при проектировании.

  • В первом примере был проскок уровня "Группа Прав". Ранее были просто "права", и в этом заключалась причина задачи.

  • Во втором примере был проскок уровня "Смысловые Нити". Ранее сообщения группировались сразу в "Тему", и в этом заключалась причина задачи.

  • В третьем примере был проскок уровня "Диспетчер Таблиц". Ранее таблицы и вызывающий код общались напрямую, и в этом заключалась причина задачи.

И в этом месте мы уйдем от "частных случаев" к "общей закономерности".

Многоуровневая архитектураМИ. ЧЕМ ИСТОРИЧЕСКИЕ ПРИМЕРЫ ПОХОЖИ НА ТРИ ПРЕДЫДУЩИХ?

Вспомним "эволюцию языков программирования":

  • Вначале были &"нули и единицы"

  • Позже произошел первый надсистемный переход: "нули и единицы" сгруппировались в "мнемоники" - часто повторяющиеся готовые сочетания "нулей и единиц", например, для команды пересылки данных - MOV, для команды сложения - ADD и т.п. Т.е. появились "ассемблеры" [8].

    Заметим: мнемоники, как бы сказали теперь, "инкапсулировали" (закрыли) "нули и единицы" от программиста. Стали "интерфейсом" между

продолжение следует...

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


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

created: 2020-05-28
updated: 2020-05-28
0



Rating 9 of 10. count vote: 2
Are you satisfied?:



Comments


To leave a comment
If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Web site or software design

Terms: Web site or software design