Семинар: Архитектурное описание для корпоративных и инженерных информационных систем. Подход ArchiMate

Семинар Архитектурное описание для корпоративных и инженерных
информационных систем. Подход ArchiMate
Докладывает: Марк Акоев (40 мин представление стандарта и демонстрация
примеров, плюс обсуждение).
Семинар состоится 02 марта 2012 года в 18:00 по адресу:
главный корпус УрФУ, ауд. И-426*. Контактный телефон: 375-97-18.
Приглашаются все желающие.

На семинаре будет дан обзор языка ArchiMate (стандарт Open Group).
Язык предназначен для описания архитектуры информационных систем (как
связи бизнес-слоя), использующихся программных систем и оборудования,
на котором информационные системы функционируют.

Обзорная информация о языке http://ailev.livejournal.com/940819.html

Бесплатный инструмент создания диаграмм редактора (Archi):
http://archi.cetis.ac.uk/

Презентация, примеры и звук будут выложены тут.

* ул. Мира 19, главный корпус УрФУ, в главном корпусе направо, на
второй этаж по лестнице, по коридору прямо, дойти до лестницы и на 4
этаж налево. Для прохода через охрану необходимо иметь при себе
документы государственного образца с фотографией, удостоверяющие
личность (паспорт, студенческий, водительское удостоверение).

==========
Зачем нужен еще один язык описания архитектуры?
Те компании которые примеряют архимейт, выигрываю в следующем:

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

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

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

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

Доводы за и против использования смотрим тут:
http://ailev.livejournal.com/940819.html

update
Слайды http://www.slideshare.net/Marcus.Akoev/ss-11830985

Мечта о системе управления показателями

решил зафиксить мысль, тк в конторе мысль не нужна.

Цель снизить затраты на механическую обработку данных в аналитике.

Задача: уметь хранить, извлекать и обрабатывать данные собираемые из статистических рядов. Источники стат рядов: данные предоставляемые статистическими ведомствами, результаты опросов и прочее.

Потребители: аналитики и работники служб отчетности в организации.

Почему нужен новый продух и нет радости от существующего, например от SQL баз? Проблема в том, что SQL не проходит по двум причинам: 1) данные между рядами из разных источников могут быть противоречивы, в РМД можно противоречивы данные хранить, но хочется упростить затраты на создание схемы данных учитывающей неконсистентность данных с точки зрения полноты и точности; 2) заранее не известно какие данные может потребоваться хранить в системе и выделять из данных ключи и поддерживать ссылочную целостность.

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

Требования для системы управления показателями:

1. нужно уметь формировать систему показателей: для каждого показателя указать что это, как собирается, кто источник данных, когда порождены, единицы измерений, как связаны с другими показателями (связь по ссылочной целостности, вычисляются, проверяются и пр). то есть система показателей образует онтологию   (в смысле машиночитаемое описание представлений о мире, проще не парится и брать в качестве основы промышленный стандарт ISO 15926). С онтологией системы показателей нужно уметь работать: изменять, трансформировать и версионировать (тут засада, проблема не обсуждалась на уровне теории, типа мне про это не известно :( ). Задача решаемая, топовые онтологии есть (ISO 15926, Gellish), ПО для работы есть (triple store), будет проблема с версионированием, но можно найти решения для работы.

Работа архитектора над такой системе будет сводится к продумыванию изменений онтологии при появлении новых параметров.

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

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

Результат отдали наружу, и зачем где и как соврали, можем даже написать почему соврали.

3. Для сбора данных из КИС пишем конекторы, которые сосут данные, для людей модуль опросы. Важно значения живут в моделе Bunge-Wand-Weber (то есть тройками значение-отношение-значение), но хранятся в РБД, схема которой изменяется с изменением данных без потерь значений и информации автоматом по онтологии. Очень напоминает то что делается в платформе (речь идет о внутреннем фреймворке используемом на фирме), только на более высоком уровне. Плюс работа с данными строится в терминах привычного языка выборок который работает напрямую с РБД, проблему с модификациями запросов нужно думать. Технологии тоже уже есть, некоторые в экспериментальном виде.

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

То что написано выше напоминает то как работают финансовые и прочие аналитики, но у них нет явной задачи работать с противоречивыми значениями и темпоральной логикой над ними я пытался найти в мире статистики похожую систему, но не нашел возможно системы пока в зачаточном состоянии.
Ближайшее что нашел это  http://wikiposit.org/w , но немного не то нет возможности связать данные из разных наборов, например вытащить все что есть по перечню вузов.

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

много буков, и счастья нет :)