Практика и перспективы применения технологии построения и унификации архитектурных моделей больших информационных систем с применени - umotnas.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Название работы Кол-во страниц Размер
Билет 20 Понятие модели. Информационная модель. Виды информационных... 1 82.32kb.
Проектирование Информационных Систем Лектор: Пальмов В. С. V курс. 4 506.3kb.
О выборе методологии построения информационных моделей контрольно-пропускных... 1 90.42kb.
1. Лекция: Современные технологии объектно-ориентированного анализа... 1 221.77kb.
Понятие модели. Информационная модель. Виды информационных моделей... 1 30.13kb.
Case-технологии. Современные методы и средства проектирования информационных... 7 1895.52kb.
Рабочая программа наименование дисциплины: Новые информационные технологии 1 105.75kb.
Лекция: Основные понятия технологии проектирования информационных... 16 2814.61kb.
Разработка методов и моделей принятия решений c применением искусственного... 1 287.47kb.
Жижина Екатерина Анатольевна Теория и практика применения международных... 1 39.98kb.
Способы и средства защиты информации Технологические аспекты защиты... 1 63.62kb.
Технология разработки программных продуктов 1 374.61kb.
Викторина для любознательных: «Занимательная биология» 1 9.92kb.

Практика и перспективы применения технологии построения и унификации архитектурных - страница №1/1



Практика и перспективы применения технологии построения и унификации архитектурных моделей больших информационных систем с применением стандартов FEA и MDA - на примере АСУ РЖД

С.А.Кинаш, ВНИИАС МПС России, Москва

Применение архитектурного подхода при построении автоматизированных систем за последние 5-6 лет вошло в обычную практику и по оценкам экспертов до 30% повышает эффективность инвестиций в информационные технологии.

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

В одном из широко используемых стандартов построения архитектуры государственных предприятий Federal Enterprise Architecture Framework (FEAF), разработанном в 1999 г. Советом руководителей информационных служб при федеральном правительстве США, архитектура предприятия на самом верхем уровне детализации состоит из шести взаимосвязанных компонентов: бизнес-архитектуры предприятия, системной архитектуры АСУ, их существующего и целевого состояния, этапов перехода от существующей архитектуры к целевой архитектуре и корпоративных стандартов, в соответствии с которыми строится и развивается архитектура предприятия (рис.1):

Рис. 1. Основные компоненты архитектуры предприятия



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

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

Современный конкурентный рынок требует от компаний способности оперативно адаптироваться к постоянно изменяющимся условиям бизнеса. Такая потребность вызвала появление новых подходов построения гибких к изменениям систем, основанных на применении сервисной архитектуры (Service oriented architecture, SOA) и архитектуры, управляемой событиями (Event driven architecture, EDA) (рис. 2).



Рис. 2. Сервисно-событийная архитектура предприятия

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

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

При построении архитектуры АСУ РЖД планируется использовать оба архитектурных подхода, как дополняющие друг друга. Прикладные сервисы, источники и подписчики событий будут взамодействовать по логически единой корпоративной сервисно-событийной шине по стандартным протоколам IIOP и SOAP, поддерживаемой инфраструктурными системными сервисами объектного межпрограммного взаимодействия (рис. 3).

Рис. 3. Целевая сервисно-событийная арихитектура АСУ РЖД

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

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

В связи с этим, в 2004-2005 годах по заказу Департамента корпоративной информатизации (ЦКИ) был создан Реестр автоматизированных систем и архитектурных моделей (Реестр АС) и реализована технология, объединяющая процессы проектирования и унификации архитектурных моделей АСУ РЖД (рис.4).

Рис. 4. Технология проектирования и унификации

архитектурных моделей АСУ РЖД

Системными архитекторами и группой системного анализа создаются общие унифицированные модели АСУ РЖД и модели их соответствия частным моделям АС. При моделировании применяется подход Захмана и стандарт MDA (Model Driven Architecture). Часть работ по унификации может быть выполнена непосредственно системными архитекторами с участием представителей заказчиков и разработчиков АС. Оставшиеся более сложные работы оформляются в форме проектов заданий на унификацию и направляются для рассмотрения и утверждения руководству ЦКИ.

Работы по формированию Реестра АС начались в 2004 г. В 2005 году была проведена инвентаризация и паспортизация эксплуатируемых и создаваемых систем, построены модели приложений систем АСУ РЖД до уровня программных компонентов. В 2005 году началось формирование общей модели НСИ, с 2006 года – общей унифицированной модели данных и общей унифицированной функциональной модели.

Планируется, что в первую очередь объектами унификации будут наиболее значимые для ОАО «РЖД» автоматизированные системы, а также те, интеграция которых является приоритетной. В будущем, автоматизированные системы и их компоненты смогут сразу проектироваться как часть общей унифицированной модели АСУ РЖД, что изначально обеспечит совместимость их моделей, позволит без дополнительных затрат выполнять их интеграцию и поддерживать единое информационное пространство компании.