Методики описания архитектур. Модели Захмана и Gartner, методики META Group и togaf. Методики Microsoft и другие. Выбор оптимальной методики

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

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

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

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

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

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

Gartner называет в технологической архитектуре шесть архитектурных компонент (сервисов), в каждом из которых выделяется определенное количество технологических "строительных блоков" (bricks) [4.24]:

• Сервисы данных: системы управления базами данных (технологии баз данных и методы доступа к базам), хранилища данных (хранилища и витрины данных), системы поддержки принятия решений (Business Intelligence – средства анализа и средства подготовки отчетов).
• Прикладные сервисы: языки программирования (языки для программирования серверной части, языки для программирования клиентской части, интегрированные среды), средства разработки приложений (средства моделирования баз данных, репозитории, методики разработки приложений, средства обеспечения качества), системы коллективной работы (средства групповой работы и электронной почты, средства управления документами), архитектура приложений (модель компонент, серверы приложений, серверы поддержки тонких клиентов), геоинформационные системы и средства.
• Программное обеспечение промежуточного слоя (middleware).
• Вычислительная инфраструктура: операционные системы и аппаратное обеспечение (приложения для настольных систем, операционные системы для настольных систем, мобильные устройства – ноутбуки, беспроводные устройства, персональные цифровые помощники, серверы приложений/данных, сетевые операционные системы, принтеры), среда для web-инфраструктуры (браузеры, web-порталы, web-серверы, средства управления и создания контента, серверы каталогов, форматы публикации информации), системы хранения (Storage Area Network – сети хранения данных, накопители на магнитных лентах, накопители на оптических дисках и CD, системы хранения высокой надежности RAID), средства системного управления (средства сетевого управления, администрирование IP), топологии (топология распределенных приложений).
• Сетевые сервисы: локальные сети (протоколы, кабельные системы, топология), глобальные сети (транспорт, протоколы), технологии доступа (пользователи с удаленным доступом, эмуляция терминалов и шлюзы, беспроводные технологии для локальных и глобальных сетей, интегрированные средства передачи данных и голоса, обеспечение доступности, средства видеоконференций), голосовые технологии (голос/данные поверх IP-протокола, голосовая почта), сетевое аппаратное обеспечение (концентраторы, маршрутизаторы и пр.).
• Сервисы безопасности: авторизация, аутентификация (внутренняя и внешняя аутентификация, PKI), сетевая безопасность (Network Firewall, Internet Firewall), физическая безопасность центров обработки данных, прочие сервисы безопасности (обнаружение вторжений, защита от вирусов).

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

Для оценки состояния технологической инфраструктуры предприятия в терминах, понятных бизнес-руководству, и с точки зрения потенциальных возможностей реализации различных бизнес-стратегий, можно использовать подход, предложенный Питером Кином (Peter Keen) [4.26]. Он основан на использовании двух критериев:

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

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

Основными характеристиками адаптивной системы (см. также [4.27]) являются:

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

Другая важная проблема – необходимость повышения эффективности использования существующих вычислительных ресурсов. Действительно, типовая загрузка мейнфреймов составляла порядка 80%, сейчас же характерными значениями являются порядка 40% для RISC-серверов и всего лишь 15% для Intel/Windows серверов. Это является следствием достаточно распространенной практики "каждому приложению – свой сервер". Но если для небольших организаций такой подход еще, в принципе, допустим, учитывая относительную дешевизну серверов уровня рабочей группы, то при количестве приложений в несколько десятков управление становится слишком неудобным, сложность – избыточной, надежность – низкой, а совокупные затраты – неприемлемо большими. Для решения этой задачи предложили свои решения практически все ведущие производители, включая HP (концепция Adaptive Enterprise, архитектура Darwin), IBM (On Demand), Sun (N1), Microsoft (Dynamic Systems Initiative) и другие.

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

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

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

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

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

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

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

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

В рамках предприятия целесообразно создать репозиторий шаблонов. Характерное для предприятия число различных шаблонов составляет порядка 30. Это включает шаблоны использования унаследованных и старых клиент/серверных систем, модели для будущей архитектуры (например, сервис-ориентированной) и т.д.

В зависимости от этого уровня можно рассматривать элементы языка шаблонов различной степени абстракции – идиомы, шаблоны дизайна (design patterns) и рамочные модели (frameworks).

Шаблон высокого уровня может объединять конкретное прикладное ПО, операционную систему, сервер СУБД, аппаратную платформу или несколько распределенных платформ, интерфейсы, метаданные и т.п. Типичными примерами являются шаблон B2B (Business-to-Business) для взаимодействия с Клиентами/Поставщиками или B2E (Business-to-Employee), описывающий взаимодействие между информационной системой и сотрудниками.

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

Большой интерес при создании бизнес-архитектуры предприятия представляют бизнес-шаблоны. В соответствии с [4.34] описание бизнес-шаблона включает:

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

В качестве другого примера рассмотрим возможности предложенных компанией IBM "шаблонов для электронного бизнеса" [4.40].

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

• бизнес-шаблоны (Business pattern) предназначены для описания взаимодействия между участниками процесса;
• шаблоны дизайна (Design pattern) отражают внутреннюю компонентную структуру системы;
• шаблоны уровня приложений (Application pattern) определяют различные варианты взаимодействия между пользователями, приложениями и данными в системе, а также соответствующий прототип уровня выполнения;
• шаблоны уровня выполнения (Runtime pattern) описывают привязку компонент системы к физическим узлам и определяют конкретные возможные продукты и их комбинации.

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

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

Под сервис-ориентированной архитектурой понимается подход к проектированию прикладных информационных систем, который руководствуется следующими принципами [4.44]:

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

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

MDA является еще одной важной архитектурной концепцией создания информационных систем. Концепция MDA была предложена консорциумом OMG (Object Management Group, http://www.omg.org/), в который сегодня входит более 800 известных производителей программного и аппаратного обеспечения. MDA является определенным обобщением идей SOA, с одной стороны, и повторно используемых программных компонент (шаблонов, паттернов) с другой, предназначенным прежде всего для повышения гибкости разрабатываемых приложений масштаба предприятия, чтобы обеспечить простоту обеспечения соответствия требованиям бизнеса в условиях изменения используемых инфраструктурных платформ.

MDA по определению является открытой и "нейтральной" по отношению к используемым технологиям интеграции. Она основана на следующих принципах [3.18]:

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

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

• методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META Group и другими;
• модель Захмана;
• методика TOGAF;
• методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.
• Федеральная Архитектура Госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве Обороны США DoDAF (Department of Defence Architecture Framework).

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

Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем.

Итак, в своей работе [5.3] Дж. Захман определил Архитектуру предприятия как "набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)". Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции. Захман предложил вместо традиционного подхода, связанного с рассмотрением отдельных аспектов работы системы как бы в различные моменты времени, использовать рассмотрение системы с различных перспектив.

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

увеличить изображение
Рис. 8.2. Модель Захмана

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

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

• используемые данные (что?)
• процессы и функции (как?)
• места выполнения этих процессов (где?)
• организации и персоналии–участники (кто?)
• управляющие события (когда?)
• цели и ограничения, определяющие работу системы (зачем?)

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

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

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

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

Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.

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

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

Так, первая колонка отвечает на вопрос "ЧТО?" и определяет используемые в системе данные. Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. Следующая колонка (вопрос "ГДЕ?") определяет пространственное распределение компонент системы и сетевую организацию. Колонка таблицы, отвечающая на вопрос "КТО?", определяет участников процесса. Пятая колонка отвечает на вопрос "КОГДА?" и определяет временные характеристики бизнес-процессов и работы системы. Последняя колонка ("ПОЧЕМУ?" или "ЗАЧЕМ?") служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем.

Основными характеристиками данной модели Захмана, как отмечено в [5.6], являются следующие:

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

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

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

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

Date: 2015-09-05; view: 5098; Нарушение авторских прав