Текст книги "Основы проектирования корпоративных систем"

Портал должен обеспечивать требования единства входа и управления ресурсами. Это достаточно важно, поскольку количество, большие объемы данных и быстрый их рост приводят к тому, что неизбежно возникают дублирование, противоречие информации, при этом иногда сотрудники намеренно могут искажать информацию или уничтожать ее. В некоторых случаях это происходит непреднамеренно, скажем, в разных информационных системах информация о сотрудниках вводится различным образом. Ее можно ввести, с одной стороны, в системе учета кадров, с другой – в системе учета зарплаты, с третьей – это может быть система электронной почты, но на самом деле это все один и тот же сотрудник, который относится к одному и тому же подразделению. Но как определить, что он действительно один и тот же? Допустим, мы хотим отправить электронное письмо человеку по фамилии Иванов, но таких людей в корпорации может быть достаточно много. И вполне может быть, что мы с этим человеком никогда не встречались лично, так как он работает где-то в филиале. Прежде всего следует убедиться, что это именно тот человек, и мы не отправим ему информацию, которая находится вне рамок его служебных полномочий. А если системы разрозненные и имеют противоречия, может случиться так, что на самом деле мы отправим письмо другому человеку, проконсультировавшись, скажем, с ответственным не за систему электронной почты, а за систему документооборота или систему управления персоналом. Поэтому обеспечение единой точки входа управления ресурсами – очень важное требование. До того как вести внедрение любой системы, нужно провести анализ тех систем, которые функционируют в корпорации. Прежде всего имеет смысл оценить системы класса учета планирования и управления ресурсами – Enterprise Resource Planning Systems (ERP).

На рис. 17.1 представлены некоторые системы с точки зрения магического квадрата Gartner Group. Здесь две оси – прикладная технологичность и инструментальная технологичность. То есть насколько легко настроить информационную систему, поскольку большинство информационных систем корпоративного типа представляет собой некий набор из строительных блоков, которые можно объединить. Кроме того, насколько эта система является технологичной в прикладном плане, т. е. если изменились бизнес-задачи или бизнес-процессы, насколько сложно будет адаптировать систему к этим требованиям.

Рис. 17.1. Классификация корпоративных систем. «Магический» квадрат Gartner Group

Естественно, это срез корпоративных систем на некоторый момент времени. Здесь можно увидеть Axapta, но не увидеть Dynamics, так как это было раньше, до того, как Dinamics появился на рынке, но показано, что Oracle Applications является достаточно хорошим решением именно с точки зрения адаптируемости к изменениям бизнеса. В любом случае это хороший выбор. SAP на тот момент, когда проводился анализ, был слишком дорогим решением. Да, он обеспечивал технологичность, адаптируемость, но это решение в разы превосходило Oracle по стоимости. Сегодня ситуация уже иная, и они близки по стоимости, а по возможностям SAP, наверное, немного опережает Oracle. Представленная ситуация – это исторический слайд примерно десятилетней давности: ситуация была иной, и анализ был проведен именно тогда, т. е. это некоторая ретроспектива. В результате удалось выявить целый ряд преимуществ, которые связаны с подходом Oracle. Что еще важно по сравнению с SAP – это наличие собственной СУБД корпоративного типа, с которой проводится интеграция на уровне внутренних механизмов, и соответственно эффективное взаимодействие. Таким образом, объединяются СУБД, система класса ERP и CASE-средства, среди которых существуют средства Oracle Designer, Oracle Developer (или, на момент, когда шло внедрение, Oracle Developer 2000) и портальные решения Oracle Portal, т. е. все вместе дает возможность построить достаточно мощное корпоративное решение на единой платформе. На сегодня, кстати, в ряде случаев оправдано решение на основе технологий Microsoft.

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

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

Здесь надо смотреть примерно сверху вниз, это как раз и будут слои архитектуры или один из возможных взглядов на эти слои. В самом низу находится СУБД Oracle, начиналось все с 8i, 9i и затем 10g. В основе проекта был конструктор модульный, который назывался Oracle Application версии 11. Это ряд модулей, в первую очередь финансового учета, планирования и управления. Это «Основные средства», «Расчеты с поставщиками», «Расчеты с заказчиками» и ряд других модулей OLAP. Средство Oracle Express позволяет анализировать сценарии развития при внедрении той или иной модели, той или иной конфигурации. CASE– и RAD-связка инструментальных средств используется для проектирования и быстрого прототипирования Oracle Designer Developer 2000. На самом верху находился Oracle Portal, который давал возможность персонализированного доступа, причем, что важно, на любой платформе, это могли быть Unix-системы и системы Microsoft, использовалась технология Java сервлеты, вернее сказать, портлеты в случае портала, и достаточно хорошие возможности разграничения доступа, персонализации и поддержки различных профилей доступа пользователей.

Какие цели ставил перед собой проект? Это прежде всего консолидация отчетности, унификация хранения и обработки данных, которые до этого хранились в разных форматах, в разных системах, что-то в Excel, что-то в Access, что-то в Word, в разных филиалах по-разному. Несмотря на то что существовали инструкции, консолидацию приходилось вести вручную. Сейчас этот процесс во многом автоматизирован.

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

Ниже представлена временная диаграмма развития проекта:

• 1997 г. – начало проекта;

• 1998 г. – внедрение основных блоков КИС;

• 2000 г. – синхронизация КИС и бизнес-процессов;

• 2002 г. – проектирование расширений КИС на основе интернет-технологий;

• 2003 г. – веб-сайт www.itera.ru и интранет-портал;

• 2004 г. – публикация консолидированных отчетов;

• 2005–2009 гг. – развитие проекта.

В качестве интернет-надстройки использовался Oracle Portal. При этом основным приложением было семейство Oracle Applications версии 11, а в качестве СУБД – Oracle (версии 8–10).

Подводя итоги, следует сказать о результатах, которые удалось получить при реализации корпоративного программного комплекса в нефтегазовой группе «Итера». Во-первых, накоплен позитивный опыт совместного использования целого ряда программного обеспечения. От Oracle это СУБД Oracle, ERP Oracle Applications, OLAP-система Oracle Express, Oracle Forms, Oracle Reports, CASE-средства Oracle Designer, Oracle Developer 2000, Oracle Portal и др. Решен ряд задач оперативного и аналитического финансового учета. Построен информационный интранет-сервер на основе технологии Oracle. В целом все эти задачи были успешно решены, было решено расширять направление Интернет-интранет-сервисов и подключать новые системы на этой основе. Был сделан вывод о том, что интернет-расширения будут способствовать сохранению инвестиций и снижению совокупной стоимости внедрения.

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

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

Применяемые методологии во многом не адекватны различным стандартам. Существует большое количество разных протоколов взаимодействия, разных стандартов хранения данных, взаимодействия между этими данными, вспомним язык IDL, на котором описываются интерфейсы CORBA-систем. Есть более стандартизованные подходы, но они либо не всеми приняты, либо приняты в разной мере, скажем, подходы к сервис-ориентированной архитектуре, подходы к проектированию интерфейсов для баз данных, стандарт ANSI SQL, к сожалению, многими производителями СУБД воспринимается по-разному и нельзя еще говорить о том, что он в полной мере реализован.

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

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

Таким образом, целью работы по построению интегрированного подхода к созданию такого гетерогенного программного модуля корпоративного типа являются исследование, обоснование и разработка методологии для построения крупномасштабных корпоративных информационных систем, предназначенных для сбора, анализа и генерации отчетно-статистической информации, которая практически апробирована построением быстрых прототипов, полномасштабных реализаций на основе интернет-порталов. Данная цель детализируется следующими задачами. Это: 1) разработка методологий, т. е. общего подхода, концептуальной схемы, методов и поддерживающей их математической модели для построения такого рода систем; 2) создание инструментальных средств, поддерживающих эти модели (чтобы не быть голословным и не говорить о проектировании только на уровне математики, только на уровне тех моделей объектов, которые используются); 3) практическая апробация построения быстрых прототипов и 4) полномасштабная реализация. При этом используются теоретические основания, прежде всего теория конечных последовательностей в форме λ-исчисления.

Итак, теория конечных последовательностей в форме лямбда-исчисления, теория категорий, теория переменных доменов и семантических сетей. Какие практические задачи возникают при этом? Это, конечно, создание единого информационного пространства с тем, чтобы каждый сотрудник корпорации из каждой точки земного шара мог получить доступ к тем данным, которые нужны ему для выполнения производственных функций в любой момент времени и с использованием различных устройств доступа. Должна быть осуществлена унификация доступа, сбор и анализ данных для построения консолидированных отчетов, генерация этих самых отчетов, естественно, на том уровне доступа, который имеет каждый сотрудник, и интеграция гетерогенных корпоративных информационных систем, составляющих программные комплексы. Кроме того, должны быть созданы инструментальные средства, которые поддерживают работу в этом пространстве. Системы управления контентом и средства интеграции данных – это те самые Concept-Modeller и информационная система для управления контентом. Должна быть спроектирована архитектура на основе портальных систем, интернет-порталов и, естественно, эта методология, этот подход должны быть апробированы с построением как быстрых прототипов, так и полномасштабных реализаций. В итоге получается корпоративная культура нового сетевого типа, т. е. в определенном смысле происходит виртуализация ресурсов и доступ к ним посредством единообразного интерфейса из любой точки земного шара в любое время, глобальная доступность. По сути, получается виртуальное рабочее место для каждого сотрудника, которому нужно получить доступ, вообще говоря, в достаточно разных условиях. Если говорить о нефтегазовой компании – это могут быть полевые условия. Люди, которые занимаются геологоразведкой, могут передавать данные, обобщать их, анализировать и смотреть перспективы продолжения разведки в том или ином регионе, в том или ином конкретном месте. Это может быть возможность получения консолидированных отчетов или отчетов на своем уровне для каждого типа, для каждой роли в корпорации, для каждой позиции, для сотрудников, которым нужны кадровые либо финансовые данные, и для топ-менеджеров, которые могут получить своего рода dashboard – приборную панель, на которой они могут видеть основные показатели развития корпорации и управлять ими, иметь обратную связь.

Общая схема методологии (рис. 17.2) включает шесть этапов, которые представлены шестью секторами на схеме. Это, начиная с 12 часов, сектор «предметная область», которая представлена на естественном языке, ее формализация в виде концептуальной модели, поддержка CASE-средств первого и второго уровня: первый уровень – это специфика рассматриваемого подхода, которая дает возможность объединить формальную математическую модель с традиционными CASE-средствами, второй уровень – это традиционное, привычное нам CASE-средство, и, наконец, стандартное построение быстрых прототипов в полномасштабной реализации в форме схемы баз данных и информационных систем при помощи CASE-средств. Каждый этап детализируется рядом уровней – это объекты, связи, события в среде и примеры средств управления этими объектами как на уровне модели, так и на уровне реализации в виде инструментальных средств и компонентов программных систем. Уровни поэтапно детализируются от периферии к центру.

Рис. 17.2. Схема методологии построения КИС в нефтегазовом секторе

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

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

В целом можно выделить следующие преимущества разработанных моделей и методологий. Прежде всего, с точки зрения моделей реализуется событийно-ориентированное управление гетерогенными высокодинамичными хранилищами объектов данных и метаданных, т. е. корпоративным контентом, который является, как мы уже говорили, гетерогенным и включает элементы с различной степенью структурированности. Поддерживаются разнородные архитектуры, т. е. гетерогенные архитектуры, как у унаследованных систем, так и у современных интернет-систем или систем клиент-серверного типа. В результате реализации внедрение ускоряется по срокам и улучшается по стоимости примерно на 30–40 %, естественно, если мы говорим о гетерогенных системах, которые объединяют различные поколения информационных систем, различную степень структурированности информации. В моновендорном решении от Oracle такой подход кроме утяжеления и дополнительных затрат ничего не даст. Но если говорить о действительно гетерогенной системе, то в итоге облегчается модернизация, адаптация, расширение, развитие информационной системы, возможен реинжиниринг, т. е. обратное проектирование от CASE-схемы данных информационных систем до уровня модели, и верификация на математически строгом языке. Мы можем доказывать корректность и соответствие спецификации программной системы просто математическим языком так же, как происходит доказательство теорем.

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

Своеобразие этого подхода и полученных результатов состоит в следующем. Реализуется, как мы уже говорили, событийно-ориентированное управление гетерогенным, высокодинамичным хранилищем. Поддерживаются разнородные архитектуры, в том числе и унаследованные. Обе модели данных поддержаны инструментальными средствами как для представления интеграции данных, так и для манипулирования ими для управления контентом. В последнем случае используется оригинальная модель в форме абстрактной машины на состояние. Практическая значимость сводится к тому, что при корректном применении методологии для гетерогенных комплексов программных систем обеспечивается существенное ускорение и упорядочивание внедрения реализаций, которое в терминах совокупной стоимости владения и возврата на инвестиции обеспечивает по сравнению с существующими коммерческими аналогами преимущества порядка 30–40 %. Кроме того, обеспечиваются облегчение, расширение, модернизация, адаптация, оптимизация производительности информационных систем.

Кратко расскажем о тех вычислительных моделях, которые лежат в основе этой методологии. Прежде всего, каждый объект данных представляет собой тройку с последовательной конкретизацией по схеме класс – объект – значение. Под классом понимается совокупность объектов в интегрированной предметной области, объект – это частичная конкретизация с означиванием ряда метаданных до шаблона информационной системы управления контентом, значение – это полное означивание до веб-страницы, до страницы портала, которая автоматически генерируется в информационной системе управления контентом на основе того или иного шаблона. При этом обеспечиваются следующие преимущества: во-первых преемственность с традиционным подходом к объектно-ориентированному анализу и проектированию OOAD (Object Oriented Analysis and Design), во-вторых, известные ранее модели данных на основе концептуального проектирования, на основе переменных доменов, на основе теории категорий и других подходов обобщаются на случай интернет-порталов, интернет-среды. Возможно непрерывное, от модели до реализации, итеративное, с последовательным улучшением проектирование расширяемых и интероперабельных информационных систем, т. е. компонентно-взаимодействующих систем, которые могут изменяться и наращиваться на основе ряда стандартов и подходов, таких как CORBA, в частности. Поддерживается обработка данных с явным разделением на frontend и backend, т. е., по сути, пользовательский интерфейс и системный с применением событийно управляемых процедур и вычислительных систем на основе динамического SQL.

Концептуальная схема построения модели данных может быть проиллюстрирована примером (рис. 17.3), который показывает двухкратную свертку, класс UML, который описывает объект данных, фотоизображение конкретизируется при первом соотнесении а₁ до слота в шаблоне, при этом означиваются такие параметры, как линейные размеры по вертикали/горизонтали и глубина цвета. Финальная конкретизация дает для данного объекта значение в форме фотоизображения, а для страницы в целом выдает веб-страницу, в данном случае биографию руководителя группы компаний «Итера» Игоря Викторовича Макарова.

Рис. 17.3. Концептуальная схем построения модели данных

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

Рассмотрим более подробно схему реализации инструментального средства ConceptModeller, которое поддерживает интеграцию различных информационных систем, входящих в состав корпоративного программного комплекса, и обеспечивает двунаправленное предметно-ориентированное проектирование с возможностью трансляции бизнес-ситуации на фреймах в UML-диаграммы и в термины традиционных CASE-средств. Поддерживаются форматы IBM Rational, Oracle Developer и Microsoft Visual Studio. Нужно заметить, что двунаправленный характер стрелок свидетельствует о возможности применения этого средства, естественно, с ручной работой и в обратном направлении, которое дает нам возможность получить из UML-диаграмм модельное представление предметной области. Поддерживается визуально-ориентированное проектирование.

Итак, средство визуального предметно-ориентированного проектирования информационных систем ConceptModeller имеет следующую краткую характеристику: язык разработки – C#, некоторые элементы логики были реализованы на языке XML. При этом, наверное, было бы целесообразно говорить о замене этого языка или об обновлении его до F#. Естественно, реализация произведена на базе операционной системы Windows, среда реализации – Visual Studio.NET, объем кода исследовательского прототипа составляет порядка 4500 строк, срок реализации – примерно один год, количество сотрудников, занятых в проекте, – 4. На рис. 17.4 обведены линией те этапы проектирования, которые реализует ConceptModeller.

Рис. 17.4. Двунаправленная схема CASE-проектирования в ConceptModeller

Точно так же на общей схеме (см. рис. 17.2) из шести этапов и шести уровней выделенным волнистой линией сектором обозначена сфера применения этого средства, которое позволяет нам сделать замкнутой всю схему проектирования корпоративных программных комплексов. Исследовательский прототип ConceptModeller (рис. 17.5) позволяет перейти от скриншота слева к скриншоту справа, т. е. от ситуативных описаний на базе фреймов. Здесь представлен ситуативный фрейм, который описывает поставку кандидатов на вакансии рекрутерами работодателю. Этот фрейм можно трансформировать в UML-диаграмму класса, обеспечивая при этом следующие преимущества. Во-первых, это адекватность разработанной математической модели предметной области на семантических сетях, поскольку фреймы прозрачно транслируются в предиктаты и лямбда-термы. Во-вторых, ориентированность на предметную область – пользователь оперирует понятиями естественного языка. В данном случае это recruiter, employer, manager и т. д. В-третьих, наглядность, поскольку используется средство визуального проектирования: пользователь не пишет текст, а работает с графическими примитивами, как и положено в CASE-средстве с визуальным интерфейсом, поддерживает современные стандарты проектирования, в частности UML, и реализованы интерфейсы с индустриально апробированными CASE-средствами, такими как IBM Rational, Microsoft Visual Studio, Oracle Developer. Поддерживается двунаправленный характер проектирования корпоративных систем, как мы видели на схеме работы ConceptModeller. Возможно проектирование как в сторону от модели к реализации, так и в обратную сторону. Обратный процесс, конечно же, требует ручной работы и определенной коррекции, если говорить о программной системе, которая была реализована на вне данной методологии на основе UML-диаграмм.

Рис. 17.5. Исследовательский прототип ConceptModeller

Другим инструментальным средством, которое поддерживает модель управления объектами данных и метаданных корпоративных систем, управления контентом, является информационная система для управления контентом сетевых ресурсов корпоративных систем. Она реализована в портируемом варианте и может работать под управлением как операционной системы Windows, так и операционной системы Unix, на языках Java и Perl, с возможностью использования СУБД MySQL и Oracle в более серьезном варианте и MySQL – в более легком варианте. Объем кода порядка 5000 строк, срок реализации – один год, количество сотрудников, занятых в проекте, – 5.

Переходя к деталям реализации, рассмотрим интерфейс предметно-ориентированного инструментального средства управления контентом корпоративных информационных систем. Здесь мы видим возможности интерфейса с разграничением на frontend и backend. Срез для пользователей корпоративного сайта представлен справа, некий временной срез страницы, которая динамически формируется на основе шаблонов и персональных предпочтений пользователя, а также устройств доступа к данным, естественно, при доступе с мобильного устройства, интерфейс будет выглядеть иначе.