LINEBURG


<< Пред. стр.

страница 8
(всего 11)

ОГЛАВЛЕНИЕ

След. стр. >>

каркасная модель, описывающая компоненты и показывающая их совместную работу. Такой
каркас модели RM-ODP может служить базой для разработки других, более детальных стандар-
тов.
Понятие "стандарты открытой распределённой обработки данных" (ODP — Open Dis-
tributed Processing standards) определяется в ISO 10746 как модель RM-ODP и те стандарты, ко-
торые прямо или косвенно согласуются с ним. Открытая распределённая обработка данных
(open distributed processing)— распределённая обработка, сконструированная в соответствии со
стандартами ODP. Система открытой распределённой обработки данных (ODP system)— сис-
тема, которая согласуется с требованиями стандартов ODP.
Основным содержанием модели RM-ODP является:
• разделение спецификации систем открытой распределённой обработки данных на
пять так называемых "точек зрения" (viewpoints), упрощающих описание слож-
ных систем;
• набор общих средств описания систем с каждой из этих "точек зрения"— так на-
зываемые "языки" (languages);
• инструментарий для спецификации инфраструктуры распределённых систем че-
рез обеспечение так называемой "прозрачностей распределения" (distribution
transparencies) — эти качества являются выборочными, для каждой конкретной
системы могут достигаться только те из них, которые необходимы;
• принципы оценки соответствия систем критериям ODP. Современные распреде-
лённые системы обработки данных являются, как правило, сложными системами.
Они строятся для решения многоцелевой задачи, включают большое число слож-
но взаимосвязанных компонент.
Полная спецификация распределённой системы может потребовать очень большое ко-
личество информации, что не осуществимо на практике. Более того, система сложна настолько,
что не может быть описана специалистами одного профиля. Для описания различных аспектов
системы используются различные средства, различные языки описания.
В соответствии с моделью RM-ODP система открытой распределённой обработки дан-
ных может быть описана с пяти "точек зрения":
• организационной (enterprise), которая рассматривает систему с точки зрения приклад-
ных целей её деятельности (бизнес-процессов);
• информационной, которая рассматривает систему с точки зрения информации, которую
необходимо хранить и обрабатывать в системе — этот взгляд интересует аналитика при созда-
нии информационного наполнения системы;
• вычислительной, которая рассматривает систему как набор объектов, которые взаимо-
действуют через интерфейсы, т.е. производит функциональную декомпозицию системы;
• инженерной, которая рассматривает механизмы, поддерживающие распределённый
характер системы — этот взгляд интересует системного программиста;
• технологической, которая детально рассматривает компоненты, из которых конструи-
руется распределённая система (аппаратное и программное обеспечение) — этот взгляд необ-
ходим системному интегратору при выборе технологий для создания работающей и экономиче-
ски эффективной системы обработки данных.
Дополнительно в модели описываются так называемые "функции ODP". Это собрания
функций, требуемых от открытых распределённых систем обработки данных для поддержания
нужд инженерной и вычислительной точек зрения. Основные группы функций — следующие:
функции управления, координации, обработки транзакций, репликации данных, защиты. По-
следние делятся на семь групп: функции контроля доступа, аудита, аутентификации, целостно-
сти, конфиденциальности, неотказуемости и управления ключами. Они детально рассматри-
ваются в стандарте ISO 10181 — OSI Security Frameworks for Open Systems и стандарте ISO
11770 — Security techniques — Key management.
Каждая "точка зрения" — это абстрактный взгляд, который охватывает вся систему в це-
лом. Они должны рассматриваться как "проекции" определённых свойств, определённых сто-
рон единого целого. Все "точки зрения" объединяет единый подход объектного моделирования,
описанный в первой части стандарта.
Вторая часть стандарта содержит определение концепций и аналитический каркас для
нормализованного описания произвольной распределённой системы обработки данных — это
описательная модель.
Третья часть содержит спецификацию требуемых характеристик, которые квалифици-
руют распределённые вычисления как открытые, используя для этого методики описания из ч.
2 — это предписательная модель.
Часть 4 содержит формализованную концепцию моделирования ODP. Каждая "точка
зрения" интерпретируется в терминах различных стандартизованных формальных описатель-
ных методик. В этой же части стандарта устанавливается взаимосвязь с другой объектной мо-
делью — CORBA, разработанной организацией Object Management Group.

3.5.2. Модель TOGAF
Модель TOGAF (The Open Group Architectural Framework) — документ, разрабатывае-
мый международной организацией The Open Group. TOGAF на сегодняшний день — наиболее
полно представленная модель открытых распределённых вычислений. Фактически в ней обоб-
щается опыт всех предыдущих поколений моделей, которые могут быть выведены из неё как
частные случаи. И, что особенно важно, TOGAF формулирует принцип невозможности по-
строения единой универсальной архитектуры для всех открытых систем, тем самым объясняя
многообразие созданных моделей.
В модели TOGAF не используются в явном виде определения "открытые", "распределённые" по отноше-
нию к системам обработки данных. Однако, открытый характер систем и распределённый характер обработки
данных в общем случае подразумеваются как обычные и даже необходимые свойства компьютерных информаци-
онных систем. В целом модель TOGAF отражает возрастающее движение к модульности и стандартизации интер-
фейсов в информационных системах.
Основой модели TOGAF являются модель POSIX OSE, модель XAF организации Х/Ореn и модель управ-
ления информацией TAFIM Министерства обороны США. Вторая версия TOGAF появилась в 1996 г., третья — в
1997 г., четвёртая — в 1998 г. В конце 1999 г. вышла пятая редакция модели.
Модель TOGAF представляет больший интерес с инженерной точки зрения, чем очень
абстрактная и формальная модель RM-ODP.
Документ состоит из четырёх основных частей. Первая часть — "введение" — описыва-
ет ключевые принципы, положенные в основу архитектуры современных информационных
систем вообще и подхода модели TOGAF в частности. Вторая часть — "Метод разработки ар-
хитектур" (ADM — Architecture Development Method) — является ядром модели TOGAF. Она
описывает шаги, которым необходимо следовать в разработке архитектуры любой информаци-
онной системы, содержит принципы конструирования архитектуры, формально описывает цикл
разработки системы. ADM опирается на другую важную составляющую модели — "Фундамен-
тальную архитектуру" (TOGAF Foundation Architecture), которая изложена в одноимённой
третьей части документа. Четвёртая часть документа — "Информационная база ресурсов" (Re-
source Base) — описывает набор инструментов и методик, доступных для использовании при
практическом применении модели TOGAF и, в частности, методов ADM. Кроме того, документ
содержит многочисленные приложения, примеры практического применения модели TOGAF,
сравнение её с другими моделями.
Рассмотрим кратко те части документа, которые представляют наибольший интерес:
концепцию организационного континуума (ЕС), нормативную техническую модель и метод де-
композиции систем на так называемые "архитектурные взгляды".
Архитектура определяется как формальное описание системы. Она является как бы де-
тальным планом, на основе которого система может быть организована и реализована таким
образом, что позволяет делать заключения о структурных свойствах системы. Любой сложной
информационной системе необходима архитектура для обеспечения стратегического контекста
её эволюции. Архитектура даёт описание компонентов, которые слагают информационную сис-
тему, прав и обязанностей каждого компонента и сложных взаимосвязей между ними, а спо-
собность видеть взаимосвязи между элементами целой информационной системы ведёт к луч-
шему пониманию глобальных проблем, таких как обеспечение безопасности информации и ад-
министративное управление системой.
Модель TOGAF утверждает: непрактично пытаться описать единую, универсальную ар-
хитектуру для открытых информационных систем. Неверно было бы строить одну архитектуру
для всех целей и пытаться рассматривать информационную систему с одной точки зрения даже
внутри одного предприятия, не говоря уже о существенно более сложных, глобальных инфор-
мационных системах. Существует непрерывное и бесконечное множество — континуум архи-
тектур, которые конструируются из каркасной модели посредством набора более узких моделей
и строительных блоков. Такую каркасную модель под названием "архитектурный каркас" (ar-
chitectural framework —AF) описывает TOGAF.
AF является инструментом для конструирования широкого ранга архитектур, оценки
различных архитектур, выбора и построения корректной архитектуры для информационной
системы конкретной организации. С помощью AF путём выбора или модификации его компо-
нентов может быть описано сразу целое семейство связанных архитектур. Преимущества AF
заключаются в следующем:появляется возможность использования общих принципов, предпо-
ложений и терминологии внутри семейства архитектур, определения единой структуры для
них, разработки информационных систем в соответствии с общими принципами и содействия
таким образом лучшей интеграции и взаимодействию систем.
Организационный континуум (ЕС — enterprise continuum) — комбинация двух взаимо-
связанных и взаимодополняющих друг друга концепций (рис. 15):
континуума архитектур (architecture continuum — А С) и континуума решений (solutions contin-
uum — SC). Под континуумом архитектур понимается широкий диапазон, непрерывное мно-
жество различных типов архитектур, которые могут быть синтезированы для всевозможных
информационных систем на различных этапах их разработки, конструирования, выбора состав-
ных частей и моделей. Континуум архитектур отображает поступательное движение от абст-
рактного к конкретному, которое имеет место при создании архитектуры каждой информа-
ционной системы, на основе последовательной детализации и перехода от предельно общей
модели (такой как TOGAF TRM) к архитектуре реальной информационной системы. В этом
множестве архитектурных моделей может быть (условно) выделено несколько "опорных то-
чек":
• Фундаментальные архитектуры (foundation architectures — FA) — это архитектуры
функций, которые поддерживаются всеми общесистемными архитектурами вместе взятыми
(см. далее), т.е. все потенциально возможные функции, которые может выполнять какая бы то
ни было информационная система. Иными словами, FA описывают полную вычислительную
среду. Примером FA является фундаментальная архитектура самой модели TOGAF.
• Общесистемные архитектуры (common systems architectures — CSA) — это архитекту-
ры, которые руководят выбором и интеграцией определённых сервисов из FA для создания ар-
хитектуры, полезной для решения широкого класса взаимосвязанных задач: архитектура защи-
ты, архитектура административного управления, сетевая архитектура и т.п. Каждая из них не-
полна, если рассматривается с точки зрения общей функциональности информационной систе-
мы, но полна в рамках определённой проблемы: обеспечение безопасности информации, управ-
ляемости системы, организация телекоммуникационной среды и т.п. Решения, реализующие
каждую такую архитектуру, составляют "строительные блоки" информационной системы. Они
оказываются совместимыми с другими "строительными блоками" и могут быть использованы в
любых комбинациях для создания функционально полных информационных систем. Примером
служит архитектура модели IT DialTone, описывающая глобальную информационную среду на
базе сети Internet (см. п. 3.5.3). Кроме того, The Open Group работает над несколькими архитек-
турными моделями такого класса, связанными с административным управлением системами,
беспроводными коммуникациями, защитой данных.
• Индустриальные архитектуры (industry architectures — IA) — архитектуры, которые
руководят интеграцией общесистемных компонентов (компонентов из архитектур класса CSA)
с компонентами архитектур из класса IA и созданием целевых решений для потребителя внутри
определённой отрасли, например, для банковской сферы, нефтехимической, газовой промыш-
ленности, авиакомпаний и т.д.
• Архитектуры организаций (organization architectures — ОА) описывают и руководят
окончательным развёртыванием компонентов информационной системы, из которых слагается
необходимое решение для определённой организации. Компоненты могут приобретаться поль-
зователем в виде готовых решений, соответствующих архитектурам перечисленных выше клас-
сов, либо разрабатываться им самим.




Рис. 15. Организационный континуум

Под континуумом решений понимается последовательный путь практической реализа-
ции архитектур из соответствующего уровня континуума архитектур, "население" логических
моделей, абстрактных по своей сути, конкретными продуктами и системами информационных
технологий. Из них, как из "строительных блоков", постепенно "вырастает" реальная информа-
ционная система, которая решает все задачи информационного обеспечения деятельности
предприятия (организации, учреждения). В континууме решений также (условно) выделяется
несколько "опорных точек":
• Продукты и сервисы — это раздельно существующие (разработанные или приобретён-
ные потребителем) аппаратные, программные или вспомогательные модули. Под последними
понимаются различные услуги на рынке информационных технологий: обучение пользователей
и персонала, консультации, системная интеграция, техническое обслуживание и т.п. Продукты
— это мельчайшие единицы, которые выполняют для потребителя какие-либо функции обра-
ботки, передачи, хранения данных.
• Системные решения — это реализации CSA, составляемые из набора продуктов и ус-
луг, которые могут быть определённым образом оценены или сертифицированы на соответст-
вие некоторым требованиям или задачам, сформулированным в CSA, например, на соответствие
критериям защищённости информации, высокой производительности и т.п.
• Индустриальные решения — это реализации IA, которые обеспечивают универсальные
"пакеты" компонентов и услуг, общих для определённой отрасли промышленности. Они могут
"набираться" из стандартных продуктов и решений, но могут требовать и специального аппа-
ратного и программного обеспечения. Например, в банковской сфере — банкоматы и пластико-
вые карты с соответствующим ПО.
• Решения для организаций — это реализации ОА, которые обеспечивают требуемые
функции для данной, конкретной организации. Они содержат наибольшее количество неповто-
римого, уникального содержания, чтобы максимально полно отвечать требованиям всех дело-
вых процессов, должностных лиц и потребителей данной организации (предприятия, учрежде-
ния). Они могут сочетать внутри себя массовые, стандартные продукты и системы информаци-
онных технологий с единичными, разрабатываемыми под нужды одной, единственной ор-
ганизации.
Фундаментальная архитектура TOGAF — это архитектура общих сервисов и функций,
обеспечивающих базис, на котором могут быть синтезированы более специфичные архитекту-
ры и архитектурные элементы. Она состоит из трёх компонент: нормативной технической мо-
дели (Technical Reference Model — TRM), информационной базы стандартов (Standards Informa-
tion Base — SIB) и информационной базы строительных блоков (Building Blocks Information
Base — BBIB). TRM обеспечивает классификацию и моделирование общих сервисов платфор-
мы. SIB представляет собой базу данных стандартов. Она может быть использована для опреде-
ления конкретных сервисов и других компонент специфичной архитектуры, которая выводится
из общей фундаментальной архитектуры TOGAF. Наконец, BBIB содержит информацию о
строительных блоках, которые могут быть использованы в конструировании архитектур.
TRM и SIB не являются строго обязательными для любой информационной системы. Потребитель вправе
выбирать или разрабатывать такую техническую модель своей системы и такие правила её организации, которые
лучше всего удовлетворяют его запросам. TRM и SIB, специфицированные The Open Group, отображают сложив-
шуюся общемировую практику создания крупномасштабных информационных систем. TRM — достаточно общая
модель, поэтому она может быть рекомендована как каркасная модель информационной системы в подавляющем
большинстве случаев, за исключением, быть может, специализированных закрытых информационных систем: бор-
товых систем, систем управления технологическими процессами. При условии, если техническая модель и набор
используемых стандартов совместимы между собой, TOGAF ADM остаётся действительным, каковы бы ни были
их особенности.
Основное назначение TRM — описание функций платформы приложений, которые необ-
ходимы для поддержки приложений. TRM помогает осуществить классификацию информаци-
онных систем и, в особенности, сервисов платформ приложений. При разработке нормативной
модели преследовалась цель обеспечить согласованное описание компонентов и структуры ин-
формационной системы, пригодное для их классификации, и наглядное представление этой
классификации в виде графической модели (рис. 16).
Пять основных элементов TRM: прикладное ПО (AS), платформа приложений (АР), ком-
муникационная инфраструктура, интерфейс платформы приложений (Application Platform Inter-
face — API), интерфейс коммуникационной инфраструктуры (Communications Infrastructure In-
terface — CII).
Как и в модели OSE, в TOGAF TRM не рассматривается конкретная структура платфор-
мы приложений. Основное отличие, однако, состоит в том, что последняя специфицирует пол-
ный набор стандартных сервисов из двенадцати групп сервисов, которые могут предоставлять-
ся платформой приложениям в любой потенциально возможной информационной системе. Реа-
лизация того или иного сервиса в конкретной системе определяется целями и задачами этой
системы. Кроме того, определяются понятия "качества сервисов". Они применяются ко всем
категориям сервисов и влияют на способ реализации и взаимодействия этих сервисов в кон-
кретной информационной системе. Качества сервисов, размещённые по четырём категориям,
описывают свойства, которые должны быть обеспечены однородно и взаимосвязанно через все
категории сервисов, например, безопасность сервисов.
Рис. 16. Нормативная техническая модель TOGAF

"Внешняя среда" в ранних версиях модели TOGAF понималась точно так же, как и в мо-
дели OSE. Это — все внешние объекты, с которыми АР обменивается информацией, причём
обмен производится через ЕЕ1. В дальнейшем (очевидно, под влиянием модели IT DialTone —
см. п. 3.5.3) под "внешней средой" стала подразумеваться прежде всего коммуникационная ин-
фраструктура, к которой "подключена" рассматриваемая информационная система. Вероятно,
это можно мотивировать следующим образом. Предполагается, что в подавляющем большин-
стве случаев информационные системы не являются изолированными. Они имеют выход во
"внешний мир", в том числе в сеть Internet — одну для всех пользователей информационных
систем. Все же остальные объекты внешней среды: пользователи и средства обмена данными
— свои для каждой информационной системы. К тому же пользователи рассматриваются во
всех моделях информационных систем опосредованно — постольку, поскольку они сами явля-
ются "средствами" хранения, ввода/вывода и обработки информации, а средства обмена дан-
ными имеют на сегодняшний день существенно меньшее значение, чем коммуникационные
средства.
В TRM даётся детальная классификация сервисов АР. Перечислим основные группы, по
которым размещаются сервисы в модели.
• Сервисы графики и изображений обеспечивают функции, требуемые для создания,
хранения, восстановления и манипулирования графическими образами.
• Сервисы обмена данными обеспечивают специализированную поддержку для обмена
информацией между приложениями и внешней средой. Обмен данными может производиться
как между приложениями на одной платформе, так и на разных — гетерогенных платформах.
Они включают сервисы распознавания типа и конверсии документов, сервисы обмена графиче-
скими данными (векторной и растровой графикой), сервисы обмена специализированными ти-
пами данных (факс, аудио, видео), гипертекстовые функции, сервисы обмена электронными до-
кументами и ряд других, которые в настоящее время относятся к прикладному ПО, но имеют
тенденцию к включению в АР, такие как редакторы текста, издательские системы, мультиме-
диа-сервисы и т.п.
• Сервисы управления данными обеспечивают управление данными, независимое от про-
цессов, создающих их, поддержку и разделение данных между процессами. Сюда включены
сервисы словаря (репозитория) данных (т.е. хранение данных о данных — метаданных), систе-
мы управления базами данных, объектно-ориентированные СУБД, сервисы управления файла-
ми и некоторые другие.
• Сервисы интернационализации операций — это набор сервисов и интерфейсов, позво-
ляющих пользователю определять, выбирать и изменять различные аспекты сред приложений,
связанные с культурными особенностями той или иной страны.
• Сервисы пользовательского интерфейса предназначены для человеко-машинного
взаимодействия и включают текстовый интерфейс, графический интерфейс, сервисы печати,
"помощь" в режиме on-line и др. сервисы.
• Сервисы размещения ресурсов и директориальные сервисы (location and directory)
включают сервисы именования и адресного поиска ресурсов, директориальные сервисы, серви-
сы фильтрации информации, регистрации и учёта.
• Сервисы программной инженерии (software engeneering) — это инструменты для разра-
ботки и поддержки сложных комплексов ПО: языки программирования, сервисы связывания
объектного кода, средства автоматизации проектирования ПО (CASE-системы), сервисы проек-
тирования пользовательского интерфейса, сервисы отображения интерфейсов с языков про-
граммирования на сервисы АР и др.
• Сервисы обработки транзакций предназначены для поддержки обработки информации
в транзакциях в режиме on-line.
• Сервисы защиты — это особая группа сервисов, так называемые межкатегориальные
сервисы. Такое название они получили потому, что механизмы их реализации могут быть ча-
стью множества сервисов различных категорий. Эта категория включает в себя сервисы иден-
тификации и аутентификации, сервисы контроля точек входа в систему, сервисы аудита, серви-
сы контроля доступа, объектные сервисы контроля доступа, сервисы обеспечения неотказуемо-
сти, сервисы шифрования, сервисы обеспечения доверенных каналов связи (trusted communica-
tion services), сервисы доверенного восстановления данных (trusted recovery services), сервисы
управления защитой. Сервис шифрования является основой ряда других сервисов, таких как
сервисы идентификации и аутентификации, сервисы контроля доступа, сервисы контроля точек
входа в систему и др.
• Сервисы административного управления системами и сетями. Их назначение — эф-
фективное управление ресурсами информационной системы для достижения целей среды от-
крытых систем. В эту группу входят сервисы управления пользователями, конфигурацией, про-
изводительностью, доступностью и надёжностью системы, учётом деятельности пользователей,
безопасностью системы, сервисы управления сетями, дисками, печатью, резервным копирова-
нием и восстановлением информации, инсталляцией и лицензированием ПО, ёмкостью памяти
и некоторые другие.
Следующие две категории сервисов условно помещены в нижний уровень платформы
приложений, так как они, как правило, являются основой реализации всех вышеперечисленных
сервисов.
• Сетевые сервисы обеспечивают поддержку распределённых приложений, требующих
доступ к данным и взаимодействие приложений в гомогенных или гетерогенных сетевых сре-
дах. Сетевые сервисы состоят из интерфейсов и протоколов. Они включают: коммуникацион-
ные сервисы — интерфейсы и протоколы для надёжной, прозрачной передачи данных между
абонентами сети, в том числе низкоуровневые функции, дающие прямой доступ к коммуника-
ционным протоколам, и высокоуровневые функции (передача файлов, удалённый вход пользо-
вателя в систему, удалённое исполнение процессов и др.), сервисы управления сообщениями,
сервисы организации групповой работы, видеоконференции, сервисы широковещательного
распространения информации, телефонии, сервисы почтовой рассылки. В последней редакции
модели в эту же группу были включены и сервисы, связанные с организацией распределённых
вычислений, т.е. такие, которые поддерживают приложения, физически "распылённые" между
множеством платформ, но поддерживающие общую среду обработки информации: распреде-
лённые сервисы времени, распределённые сервисы данных, распределённые файловые сервисы,
распределённые сервисы именования, сервисы доступа к удалённым процессам, сервисы уда-
лённого вывода и распространения информации.
• Сервисы операционной системы ответственны за управление аппаратными ресурсами
платформы, включая процессор, память, файлы, ввод/вывод. Они экранируют приложения от
особенностей аппаратного обеспечения той или иной платформы. Сервисы ОС включают: низ-
коуровневые сервисы ядра ОС, объектные сервисы ядра, интерпретаторы команд и утилиты,
сервисы пакетной обработки, сервисы синхронизации файлов и директорий.
Объектное обеспечение сервисов не выделяется как отдельная категория в TRM, так как
все индивидуальные объектные сервисы включены в различные другие сервисные категории.
Объектные сервисы обеспечивают способы создания, размещения, именования объектов и свя-
зывания их в распределённой среде.
Модель выделяет следующие категории "качеств", присущих сервисам:
• доступность, куда входят понятия управляемости, обслуживаемости, производитель-
ности, надёжности, восстанавливаемости, удобства размещения сервисов;
• гарантированность, куда включаются безопасность, целостность и уровень доверия к
системе;
• используемость (лёгкость действий пользователей);
• адаптируемость, а именно способность к взаимодействию, масштабируемость, пере-
носимость, расширяемость функций системы.
Очень важным элементом модели является SIB — это систематизированное собрание
большого числа стандартов, наработанных за долгие годы различными международными орга-
низациями, апробированных или широко принятых в промышленности, выбранных членами
The Open Group в качестве ядра для реализации открытых информационных систем. В SIB все
стандарты классифицированы по категориям сервисов, соответствующих TRM.
Так как современные информационные системы являются сложными системами, для
описания тех или иных аспектов системы используются различные средства, различные инст-
рументы описания (ср. с моделью RM-ODP — п. 3.5.1).
Исторически сложилось несколько довольно самостоятельных отраслей, связанных с
информационными технологиями. В связи с этим модель TOGAF вводит несколько так назы-
ваемых "взглядов" (views) на информационную систему. Напомним, что в RM-ODP также есть
понятия "точек зрения" (viewpoints), под которыми понимается "набор концепций, структур и
правил, формирующих соответствующий язык [описания]": организационной, информацион-
ной, вычислительной, инженерной и технологической. "Точки зрения" RM-ODP не вполне сов-
падают со "взглядами" модели TOGAF. Более корректно, по-видимому, сравнивать их с раз-
личными уровнями детализации, которые используются моделью TOGAF для описания "строи-
тельных блоков".
Функциональный взгляд (function view) рассматривает операционные аспекты системы,
отталкиваясь от описания существующей среды информационных технологий и требований к
функциям системы. Это взгляд со стороны специалиста в той предметной области, нужды ко-
торой обслуживает система.
Взгляды на реализацию (implementation views)— это описание строения системы с точки
зрения различных специалистов по информационным технологиям:
• Взгляд на административное управление системой (management view) — это рассмот-
рение системы с точки зрения лиц, ответственных за её эксплуатацию: долгосрочное планиро-
вание целей деятельности информационной системы, оперативно-диспетчерское управление,
конфигурирование и администрирование ПО и др.
• Взгляд на защиту (security view) имеет целью обеспечить контролируемое использова-
ние информации в системе, сосредотачиваясь на аспектах защиты информации внутри инфор-
мационной системы организации.
• Взгляд на строение программного обеспечения (builder's view) охватывает те стороны
создания и функционирования информационной системы, которые важны для разработчиков
ПО: переносимость, способность к взаимодействию, методы разработки сложных программных
систем и пр.
• Взгляд на управление данными (data management view) изучает процессы хранения, дос-
тупа, обработки, архивации, передачи данных, в том числе средства и методы систематизиро-
ванного хранения и управления данными, защиту, администрирование данных.
• Пользовательский взгляд (user view) включает эргономические аспекты работы пользо-
вателя: удобство, простоту видения системы, среду работы пользователей.
Физические взгляды (physical views) — это взгляды на систему с точки зрения физиче-
ской её организации и размещения в пространстве:
• Взгляд на организацию вычислений (computing view) — это множество различных спо-
собов, которыми программные и аппаратные компоненты могут быть собраны в работоспособ-
ную структуру. Здесь рассматриваются различные модели организации вычислений: «клиент -
сервер», иерархическая , одноранговая («peer-to-peer»), объектная модель, мобильные вычисле-
ния.
- Коммуникационный взгляд (communications view) рассматривает географический аспект
организации системы, её коммуникационную инфраструктуру. Последняя рассматривается
здесь с двух позиций:
- физически — как состоящая из трёх уровней: локального, регионального и глобально-
го, на каждом из которых используются вполне определённое коммуникационное оборудова-
ние, методы передачи данных, среды распространения сигнала;
- логически — как состоящая из пяти архитектурных уровней на базе расширенной мо-
дели ISO/OSI: уровня передачи (transmission level) — ниже физического уровня модели OSI,
уровня сетевых переключений (network switching level) — с 1-го по 3-й уровень OSI, уровня
обмена данными (data exchange level) — с 4-го по 7-й уровни модели OSI, сервисов прикладно-
го уровня модели OSI и уровня прикладных программ.

3.5.3. Модель IT DialTone

<< Пред. стр.

страница 8
(всего 11)

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign