Интегрированная концепция архитектуры предприятия

Интегрированная концепция и уровни абстракции

Интегрированная концепция архитектуры предприятия

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

Вообще говоря, при разработке и использовании архитектуры предприятия, конечно же, целесообразно придерживаться какой-либо одной методики, которая обеспечивала бы единство в подходах и соответствующие наборы инструментов для описания архитектуры. Мы кратко рассмотрим наиболее известные методики в «Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF» и «NASCIO. Модели «4+1» и SAM. Методики Microsoft и другие. Выбор «оптимальной» методики» . Здесь же мы детализируем наше общее представление о понятии «архитектура предприятия».

Архитектура предприятия является динамичным и мощным инструментом, который помогает организациям в процессе понимания своей собственной структуры и способов выполнения своей работы и функций. Она обеспечивает «карту» предприятия и «план маршрута» по изменению как в бизнес-областях, так и в области технологий.

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

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

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

Архитектура предприятия – это скорее процесс, чем некоторый статический предмет. Мы не будем говорить, что ее создание – это легкая веселая прогулка. Но тем не менее, это может быть притягательным и в каком-то смысле завораживающим занятием. Архитектура предприятия не является простым предметом, но в последующем изложении мы постараемся его сделать менее «устрашающим и приводящим в уныние». Существующие уже сегодня методики описания архитектуры предприятия позволяют организовать соответствующий процесс при наличии даже минимального количества первоначальной информации в интуитивной и естественной манере. При этом полнота описания архитектуры может наращиваться постепенно, по мере того как растет понимание объекта описания архитектуры – структуры и функций предприятия, а также обеспечивающих информационных технологиях.

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

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

Пользователями архитектуры предприятия является достаточно обширная аудитория специалистов и руководителей:

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

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

  • использование для анализа множества точек зрения на объект изучения (предприятие и его информационные системы) для того, чтобы «разделять и властвовать» в процессе борьбы с объективной сложностью реального мира. Важно понимать, что ни одна отдельно взятая точка зрения не является достаточной для понимания всего целого;
  • для того чтобы обеспечить процесс синтеза, все модели, которые включены в архитектуру, связываются с другими моделями. Они являются либо более детальной декомпозицией, либо связанными между собой представлениями. Это богатство взаимосвязей между моделями напрямую определяет качество архитектуры.

Итак, прежде чем продолжить, приведем еще одно определение архитектуры предприятия, которое дано на сайте www.geao.org «Всемирной Организации Корпоративной Архитектуры» (GEAO – Global Enterprise Architecture Organization):

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

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

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

Мы уже отмечали, что движущей силой архитектуры предприятия является целостное видение, пронизывающее внутриорганизационные границы. Представленная на рис. 4.1 схема, предложенная GEAO, иллюстрирует различные уровни абстракции, связанные с описанием предприятия. Отметим, что в рамках одной организации имеется только одна архитектура предприятия, но при этом на уровне отдельных систем может существовать большое количество архитектур уровня решений (solution architecture). Архитектура предприятия покрывает как аспекты, связанные с бизнесом, так и аспекты, связанные с ИТ, а также процессы развития, эволюции архитектуры и структуры управления и контроля за этими процессами (governance), которые обеспечивают переход от текущего состояния архитектуры в будущее желаемое состояние.


Рис. 4.1. Контекст и уровни абстракции архитектуры

Лекция 4. Интегрированная концепция архитектуры предприятия 
 459

Архитектура предприятия является динамичным и мощным инструментом, который помогает организациям в процессе понимания своей собственной структуры и способов выполнения своей работы и функций. Она обеспечивает «карту» предприятия и «план маршрута» по изменению как в бизнес-областях, так и в области технологий.

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

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

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

Пользователями архитектуры предприятия является достаточно обширная аудитория специалистов и руководителей:

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

2. системные архитекторы, которые отвечают за создание архитектуры отдельных информационных систем;

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

4. руководители, заинтересованные в систематическом, структурированном анализе проблем и возможностей, которые открываются перед бизнесом.

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

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

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

Приведем еще одно определение архитектуры предприятия, которое дано на сайте www.geao.org «Всемирной Организации Корпоративной Архитектуры» (GEAO – Global Enterprise Architecture Organization):

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

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

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

Рис. 4.1. Контекст и уровни абстракции архитектуры

Этот рисунок показывает, какие концепции могут соответствовать различным компонентам этого общего представления.

Рис. 4.2. Концепции, соответствующие различным элементам и уровням абстракции архитектуры

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

При описании архитектуры предприятия чрезвычайно важную роль имеют два следующих понятия:

1. перспектива (perspective) или уровень абстракции;

2. представление (view) или предметная область, домен архитектуры.

Большинство методик разделяет проблему описания архитектуры предприятия на некоторое количество представлений или предметных областей (доменов), таких как:

1. бизнес-архитектура – люди и процессы;

2. архитектура информации – данные, информация и знания;

3. архитектура прикладных систем;

4. технологическая архитектура.

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

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

Кроме перечисленных выше представлений (предметных областей или частных архитектур), в описании архитектуры предприятия иногда отдельно выделяют такие специализированные области, как «Безопасность» и «Руководящие принципы» (Governance), которые имеют отношение ко всем представлениям (частным архитектурам) сразу. При этом «Руководящие принципы» содержат правила, которым организация следует в процессе разработки и использования архитектуры предприятия.

Мы будем использовать термины «перспектива» и «уровень абстракции» как синонимы и термины «представление», «предметная область», «домен» как еще одну группу синонимов. К сожалению, российская терминология в этой области до конца не установилась, поэтому мы будем иногда приводить несколько терминов для одного понятия, пытаясь находить максимально близкое соответствие зарубежным аналогам.

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

1. уровень контекста – ориентирован на бизнес-руководство;

2. концептуальный уровень или «Видение Общих Требований» – ориентирован на «владельцев» бизнес-процессов;

логический уровень – ориентирован на архитекторов и проектировщиков систем;

4. физический уровень – ориентирован на проектировщиков и разработчиков систем.

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

Рис. 4.3. Представления (домены) и перспективы (уровни абстракции) описания Архитектуры

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

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

В результате мы имеем конструкцию определения архитектуры предприятия, которая условно показана на рис.

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

Рис. 4.4. Интегрированная концепция архитектуры предприятия

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

Итак, большинство методик описания архитектуры основаны на концепции, которую Стивен Спивак назвал «структурное мышление» (Framework Thinking). Структурное мышление является интересным принципом. Он требует от вас сознательного абстрагирования и упрощения проблемы в целях выполнения анализа. Наверное, каждый из нас в жизни сталкивался с объективно сложными ситуациями, когда сама эта сложность уменьшала наши возможности находить решения. Однако процесс «структурного мышления», с его разбиением целого на части и сознательным упрощением, позволял легче понимать, моделировать и решать, в конечном итоге, проблему.

Основной же принцип состоит в том, что в большинстве случаев бизнес определяет информационные технологии.

Концепция разделения архитектуры предприятия на различные представления (предметные области) и уровни абстракции позволяет бизнесу четко видеть влияние предлагаемых изменений. В общем случае изменения в более «высоких» предметных областях (представлениях), таких как изменения в бизнес-процессах, окажут влияния на более «низкие» уровни представлений (например, прикладные системы). Обратная ситуация, когда происходят изменения в прикладных системах, не обязательно затронет бизнес-процессы, хотя и такое вполне может быть, когда дополнительные функциональные возможности уровня прикладных систем обеспечат возможность реализации бизнес-процессов, которые ранее сдерживались отсутствием технологий.

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

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

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

Уровни абстракции (перспективы) в описании архитектуры предприятия

Лекция 4. Интегрированная концепция архитектуры предприятия

Архитектура предприятия является динамичным и мощным инструментом, который помогает организациям в процессе понимания своей собственной структуры и способов выполнения своей работы и функций. Она обеспечивает «карту» предприятия и «план маршрута» по изменению как в бизнес-областях, так и в области технологий.

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

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

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

Пользователями архитектуры предприятия является достаточно обширная аудитория специалистов и руководителей:

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

2. системные архитекторы, которые отвечают за создание архитектуры отдельных информационных систем;

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

4. руководители, заинтересованные в систематическом, структурированном анализе проблем и возможностей, которые открываются перед бизнесом.

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

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

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

Приведем еще одно определение архитектуры предприятия, которое дано на сайте www.geao.org «Всемирной Организации Корпоративной Архитектуры» (GEAO – Global Enterprise Architecture Organization):

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

Движущей силой архитектуры предприятия является целостное видение, пронизывающее внутриорганизационные границы. Представленная на рис. 4.1 схема, предложенная GEAO, иллюстрирует различные уровни абстракции, связанные с описанием предприятия. Отметим, что в рамках одной организации имеется только одна архитектура предприятия, но при этом на уровне отдельных систем может существовать большое количество архитектур уровня решений (solution architecture). Архитектура предприятия покрывает как аспекты, связанные с бизнесом, так и аспекты, связанные с ИТ, а также процессы развития, эволюции архитектуры и структуры управления и контроля за этими процессами (governance), которые обеспечивают переход от текущего состояния архитектуры в будущее желаемое состояние.

Рис. 4.1. Контекст и уровни абстракции архитектуры

Этот рисунок показывает, какие концепции могут соответствовать различным компонентам этого общего представления.

Рис. 4.2. Концепции, соответствующие различным элементам и уровням абстракции архитектуры

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

При описании архитектуры предприятия чрезвычайно важную роль имеют два следующих понятия:

1. перспектива (perspective) или уровень абстракции;

2. представление (view) или предметная область, домен архитектуры.

Большинство методик разделяет проблему описания архитектуры предприятия на некоторое количество представлений или предметных областей (доменов), таких как:

1. бизнес-архитектура – люди и процессы;

2. архитектура информации – данные, информация и знания;

3. архитектура прикладных систем;

4. технологическая архитектура.

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

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

Кроме перечисленных выше представлений (предметных областей или частных архитектур), в описании архитектуры предприятия иногда отдельно выделяют такие специализированные области, как «Безопасность» и «Руководящие принципы» (Governance), которые имеют отношение ко всем представлениям (частным архитектурам) сразу. При этом «Руководящие принципы» содержат правила, которым организация следует в процессе разработки и использования архитектуры предприятия.

Мы будем использовать термины «перспектива» и «уровень абстракции» как синонимы и термины «представление», «предметная область», «домен» как еще одну группу синонимов. К сожалению, российская терминология в этой области до конца не установилась, поэтому мы будем иногда приводить несколько терминов для одного понятия, пытаясь находить максимально близкое соответствие зарубежным аналогам.

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

1. уровень контекста – ориентирован на бизнес-руководство;

2. концептуальный уровень или «Видение Общих Требований» – ориентирован на «владельцев» бизнес-процессов;

3. логический уровень – ориентирован на архитекторов и проектировщиков систем;

4. физический уровень – ориентирован на проектировщиков и разработчиков систем.

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

Рис. 4.3. Представления (домены) и перспективы (уровни абстракции) описания Архитектуры

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

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

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

Рис. 4.4. Интегрированная концепция архитектуры предприятия

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

Итак, большинство методик описания архитектуры основаны на концепции, которую Стивен Спивак назвал «структурное мышление» (Framework Thinking). Структурное мышление является интересным принципом. Он требует от вас сознательного абстрагирования и упрощения проблемы в целях выполнения анализа. Наверное, каждый из нас в жизни сталкивался с объективно сложными ситуациями, когда сама эта сложность уменьшала наши возможности находить решения. Однако процесс «структурного мышления», с его разбиением целого на части и сознательным упрощением, позволял легче понимать, моделировать и решать, в конечном итоге, проблему.

Основной же принцип состоит в том, что в большинстве случаев бизнес определяет информационные технологии.

Концепция разделения архитектуры предприятия на различные представления (предметные области) и уровни абстракции позволяет бизнесу четко видеть влияние предлагаемых изменений. В общем случае изменения в более «высоких» предметных областях (представлениях), таких как изменения в бизнес-процессах, окажут влияния на более «низкие» уровни представлений (например, прикладные системы). Обратная ситуация, когда происходят изменения в прикладных системах, не обязательно затронет бизнес-процессы, хотя и такое вполне может быть, когда дополнительные функциональные возможности уровня прикладных систем обеспечат возможность реализации бизнес-процессов, которые ранее сдерживались отсутствием технологий.

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

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

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

Уровни абстракции (перспективы) в описании архитектуры предприятия

Понятие перспективы используется в искусстве для определения направления на изображаемый объект – например, вид здания с площади или из окна соседнего небоскреба. Помимо чисто «геометрического» направления, понятие перспективы может быть обобщено для отображения различного уровня восприятия объекта – например, описание и восприятие одного и того же здания с точки зрения туриста, осматривающего окрестности, постоянного жильца или пожарного может быть существенно различным, в соответствии с их опытом и отношением к предмету. Этот же термин достаточно широко применяется и при разработке программных систем.

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

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

Контекст является важным для понимания тех или иных, в том числе технологических, решений и компромиссов.

Ниже приведены примеры вопросов, на которые должен давать ответ уровень контекста:

1. Каких целей хочет добиться организация?

2. Почему организация занимается таким бизнесом: видение, миссия и цели?

3. Каковы тенденции в индустрии, в которой работает организация?

4. Как организация расположена и где она работает географически?

5. Каковы факторы, определяющие достижение высоких результатов в бизнесе (value drivers)?

6. Каковы на самом высоком уровне классы информации, которыми оперирует организация?

7. Каковы функции этого бизнеса?

8. В каких областях сосредоточена ключевая компетенция организации?

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

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

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

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

1. Какие области бизнеса должны быть поддержаны информационными технологиями?

2. Какая общая бизнес-архитектура (например, «фронт-офис», «мид-офис», «бэк-офис») будет использоваться?

3. Как системы будут соотноситься с организационными структурами и бизнес-архитектурой, насколько информационные системы отдельных департаментов будут консолидированы в единый набор ключевых прикладных систем?

4. Как выглядят бизнес-процессы, которые обеспечивают создание продуктов и оказание услуг?

5. Какая информация требуется для каждого бизнес-процесса и как эта информация может повторно использоваться?

6. Организован ли бизнес организации в централизованном или децентрализованном виде?

7. Какой уровень делегирования полномочий должны обеспечивать системы?

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

9. Какие вопросы по надзору и руководству использованием технологий должны быть рассмотрены на данном этапе?

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

В качестве методов, которые используются для построения бизнес-моделей на этапе концептуального проектирования, могут быть, например, такие инструменты языка UML как Варианты Использования (Use Cases), диаграммы деятельности и другие методы проектирования процессов.

Логический уровень архитектуры показывает основные функциональные компоненты и их взаимосвязи между собой без технических деталей того, как на практике реализована функциональность этих компонент. Логический уровень является «последним» уровнем, который изолирует требования бизнеса от обеспечивающих выполнение этих требований технологий. Он определяет классы прикладных систем, технологий и данных, которые должны быть поддержаны, но не в терминах конкретных продуктов и технологических решений. Логические модели отвечают на вопрос о том, как требования, идентифицированные в концептуальных моделях, будут реализованы. На этом уровне определяются общие принципы, которые будут накладывать определенные ограничения на решения, принимаемые на более низких уровнях (например, ориентация на технологии web-сервисов).

На этом уровне даются ответы на следующие вопросы:

1. Какие приложения необходимы для поддержки бизнес-процессов?

2. Кто является основными пользователями и заинтересованными сторонами в реализации данных прикладных систем?

3. Как выглядят нормализованные модели данных для этих приложений?

4. Какие прикладные системы нужны для управления данными: создания, чтения, внесения изменений и удаления данных?

5. Какие нужны технологии для реализации этих прикладных систем?

6. Как будет выглядеть распределенная архитектура прикладных систем?

7. Какие стандарты должны быть приняты организацией?

Логический уровень описывает решение в виде набора сервисов или компонент в независимой от технологической реализации форме. Это включает четкое определение интерфейсов (или так называемых контрактов), связанных с интеграцией и совместной работой этих сервисов и компонент. Поскольку этот уровень описания архитектуры не зависит от конкретных продуктов реализации, он остается относительно стабильным. Он может меняться, чтобы отражать инициированные «сверху-вниз» изменения, включая новые фундаментальные бизнес-модели (например, переориентация на модель обслуживания, основанную на потребностях клиента), а также отражать изменения, инициированные в направлении «снизу-вверх», такие как возможности, открывающиеся в связи с использованием новых технологий (например, применение CRM-системы для управления отношениями с клиентами). Изменения могут быть связаны с новыми технологическими парадигмами и концепциями, такими, например, как сервис-ориентированная архитектура или Grid-вычисления. При подобном подходе влияние изменений на уровне бизнеса или технологий могут быть оценены в явной и последовательной манере.

Ключевыми вопросами, которые должны быть решены на данном уровне абстракции, являются следующие:

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

2. Как логические компоненты будут распределены между различными системами (будут ли эти компоненты реализованы в виде web-сервисов)?

3. Как единый брокер или шина интеграции будет обеспечивать различные бизнес-системы, или как средства обеспечения совместной работы будут использоваться помимо баз данных и средств интеграции для того, чтобы обеспечить работу виртуальных групп сотрудников?

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

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

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

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

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

Примеры вопросов, на которые отвечают на данном уровне абстракции, следующие:

1. Каковы функциональные спецификации каждой прикладной системы?

2. Будет ли организация разрабатывать специализированные приложения или покупать стандартные?

3. Каковы критерии выбора и как будут оцениваться различные инициативы по реализации систем?

4. Как данные будут представлены на физическом уровне?

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

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

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

На уровнях физической архитектуры и уровне реализации для ускорения цикла разработки, повышения качества разрабатываемых систем (за счет использования проверенных решений) и уменьшения рисков проекта могут использоваться такие концепции и архитектурные модели, как, например, Microsoft Systems Architecture (MSA).

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

Таблица 4.1. Пример рассмотрения системы на различных уровнях абстракции

Перспектива (уровень абстракции) Уровень детализации
Контекст
  • Компания представляется в виде «черного ящика» и является центральным «действующим лицом» (фактором).
  • Бизнес моделируется с точки зрения внешних для бизнеса факторов.
  • Моделируются только бизнес-взаимодействия, средства игнорируются.
Концептуальный
  • Моделируются потоки работ бизнес-процессов, идентифицированных на концептуальном уровне.
  • Система, реализующая процессы, является центральным актором в форме «черного ящика».
  • Бизнес-процессы моделируются с точки зрения внешних для системы акторов. Рассматриваются средства коммуникаций, используемые для выполнения транзакций.
Логический
  • Моделируется внутренняя архитектура системы.
  • Основные компоненты системы являются основными факторами.
  • Поведение системы моделируется с точки зрения внутренних для системы «черных ящиков».
Физический
  • Моделируется физическая структура реализации системы.

Многоуровневая абстракция

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

Многоуровневая абстракция

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

Зачем вообще делят на уровни абстракции?

1. Борьба со сложностью. На каждом уровне применяются методы именно данного уровня.
2. Уменьшение связности.
3. Обеспечение взаимозаменяемости классов на всех уровнях кроме верхнего.

Многоуровневая абстракция работы с данными

Идем по убыванию уровня абстракции:
* Класс-сущность реального мира
* Провайдер данных
* Реальные библиотеки работы с данными
Пример:
* User
* IUserProvider, SqlUserProvider, XmlUserProvider,…
* SqlClient, XmlDocument,…
При этом мы получаем низкую связность: User знает про интерфейс IUserProvider, SqlUserProvider и XmlUserProvider выполняют IUserProvider и пользутся библиотеками SqlClient и XmlDocument. Более того, объекты определенного уровня абстракции работают только с объектами следующего (нижнего) уровня абстракции, но никак не наоборот, что не допускает циркулярных связей.

Когда возникают проблемы?

1. Обычно в одном проекте несколько многоуровневых абстрактных моделей. Проблемы возникают если несколько абстрактных моделей надо подвергнуть однообразным изменениям. При этом приходится вносить изменения во все промежуточные уровни абстракции включая верхний.
2. При прототипировании накладные расходы на проектирование многоуровневой абстрактной модели могут быть слишком высоки и возможно написание временного кода без уровней абстракции, который придется выкинуть после утверждения прототипа.
3. Абстракция от источников данных может породить (и порой порождает) неоптимальную работу с источниками данных.

Что делать?

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

Чем кодогенерация может помочь в сложных моделях

Сложные приложения всегда задают много вопросов. По моим наблюдениям, на бОльшую часть из них можно ответить еще в процессе разработки (например, на сайте нужно кеширование или нет; какая операционная система будет на сервере; использовать буфферизацию вывода или нет…). Если мы ответим на этим вопросы заранее — мы можем избежать лишней сложности программы, лишних действий, лишних проверок и т.п. Более того, кодогенератор сам может собрать в среде назначения некоторые данные заранее, которые он может использовать для оптимизации работы.
Но это не значит, что меньше результирующего кода = проще система. Кодогенератор сам должен быть достаточно качественный для того, чтобы генерировать качественный код.

Кодогенерация + многоуровневая абстрактная модель

Данные подходы не противоречат друг другу и могут использоваться совместно. Например, в ASP.NET существует система хранения личных данных пользователей в профилях (Profile). Там выстроена абстрактная модель с несколькими уровнями абстракции, а сверху лежит ProfileBase. Если список свойств мы зададим в конфигурации, то будет сгенерирован потомок класса ProfileBase — ProfileCommon, который будет содержать те свойства, которые мы указали в конфигурации. Фактически, в конфигурации мы указали метаданные.
В следующей статье мы разработаем определенный несложный кодогенератор.

Уровень абстракции (программирование)

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

Уровень абстракции предоставляет способ сокрытия деталей реализации определенного множества функциональных возможностей. Модели программного обеспечения, использующие уровни абстракции, включают семиуровневую модель OSI для протоколов передачи данных компьютерных сетей, библиотеку графических примитивов OpenGL, модель ввода-вывода на основе потоков байт из Unix, адаптированную MSDOS, Linux и большинством других современных операционных систем.

В операционной системе Unix большинство типов операций ввода-вывода рассматриваются как потоки байтов, считываемые или записываемые на устройство. Эта модель потока байтов используется для ввода-вывода в файл, сокет и компьютерный терминал, чтобы обеспечить независимость от устройства ввода-вывода. Для чтения и записи в устройство на уровне приложения программа вызывает функцию открытия устройства, которое может соответствовать реальному устройству, например, терминалу или виртуальному устройству, например, сетевому порту или файлу в файловой системе. Физические характеристики устройства передаются операционной системе, которая, в свою очередь, предоставляет абстрактный интерфейс, позволяющий программисту считывать и записывать байты в устройство. Операционная система затем выполняет действительное преобразование, необходимое для чтения и записи потока байтов в устройство.

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

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

Хорошая абстракция обобщает то, что можно сделать абстрактным; допуск специфики нарушает абстракцию и ее успешное применение требует приспособления к каждому уникальному требованию или проблеме.

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

Известный афоризм Дэвида Уилера гласит: Все проблемы в информатике можно решить на другом уровне окольным путем; это часто неверно цитируется с заменой «окольного пути» на «абстракцию». Продолжение от Кевлина Хенни гласит «…за исключением проблем с большим уровнем косвенности.»

Архитектура компьютера

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

Ссылки

См. также

  • Слой в объектно-ориентированном смысле
  • Инкапсуляция (программирование)
  • Абстракция данных
  • Прозрачность
  • Кольца защиты
  • Программное обеспечение
  • Интерфейс программирования приложений
  • Инженерия программного обеспечения
  • Аппаратное обеспечение
  • База данных
  • Компьютерная сеть

Уровни абстракции

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

На самом нижнем уровне — электронных схем — компьютер очень прост. Электронная схема понимает только две команды: включено и выключено, символически обозначаемые при помощи цифр 1 и 0. На данном уровне общение с машиной идет с помощью цепочек нулей и единиц. Команда — это понятный процессору набор двоичных цифр или битов (разрядов). Таким образом, команда представляет собой просто число в двоичной системе счисления или двоичное число. Компьютеры называются цифровыми, потому что на машинном языке для обозначения как команд, так и данных используются цифры.

Когда-то давно, программисты «общались» с компьютерами на языке двоичных чисел. Это не слишком удобно, поэтому был изобретен более высокий уровень абстракции — язык ассемблера, представляющий собой символическую форму двоичного языка компьютера. Ассемблером называется программа, транслирующая символическое представление команд в двоичную форму.

Для большинства программистов язык ассемблера — также не вполне естественный, поэтому был создан еще более высокий уровень абстракции — язык программирования высокого уровня (ЯВУ). В настоящее время насчитываются сотни таких языков; наиболее известные из них — Basic, C, C++, Cobol и RPG. Программа, принимающая на входе текст на одном из языков высокого уровня и транслирующая его в операторы языка ассемблера, называется компилятором.

Иллюстрация многоуровневой абстракции — написание программы на языке высокого уровня. Компилятор выполняет преобразование программы на ЯВУ в язык ассемблера, который затем переводит свои команды в двоичный код, понятный процессору. Замечу, что некоторые компиляторы генерируют команды непосредственно на машинном языке, минуя уровень ассемблера.

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

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

Похожа на эмуляцию интерпретация программ. Программа-интерпретатор выбирает инструкции по одной и исполняет эквивалентную им последовательность команд более низкого уровня. Некоторые из новейших ЯВУ, используемых в распределенных вычислениях, например Java, разработаны так, чтобы их было легко интерпретировать. Большинство командных языков также интерпретируемы. Введите «dir» в командной строке DOS на любом ПК и на экране появится содержимое каталога. Если после этого нажать клавишу Enter, интерпретатор командной строки DOS считает введенную команду, а затем выполнит последовательность инструкций, необходимых для ее выполнения. Такой интерпретатор команд есть в большинстве операционных систем. В микропрограммируемой машине интерпретация обычно поддерживается специальным оборудованием. Микропрограмма для различения такой аппаратной формы интерпретации называется эмулятором.

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

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

Поделитесь на страничке

Следующая глава >

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *