Проектирование информационных систем на основе моделирования

1.

Проектирование
информационных систем на
основе моделирования
Е.А.Черкашин, В.В.Парамонов,
Р.К.Федоров
Дни науки в ИДСТУ СО РАН.
Иркутск - 2015

2.

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

3.

Информационные системы
Проектирование ИС охватывает три основные области:
проектирование объектов данных, которые будут
реализованы в базе данных;
проектирование программ, экранных форм, отчетов,
которые будут обеспечивать выполнение запросов к
данным;
учет конкретной среды или технологии, а именно:
топологии сети, конфигурации аппаратных средств,
используемой архитектуры (файл-сервер или клиентсервер), параллельной обработки, распределенной
обработки данных и т.п.
http://intuit.ru

4.

Современные условия
Проблемы, возникающие на всех стадиях ЖЦ:
1. «Ленивый заказчик»: заказчик отказывается готовить
техническое задание и фиксировать требования.
2. Динамичность предметной области (структура,
свойства): энергетика (С.Ковалев), синтез планов
диагностики (А.И.Берман, О.А.Николайчук и др.).
3. Динамичность технологий разработки ПО, методов
интеграции данных (NoSQL БД. map-reduce и т. д.).
4. Разнообразие платформ реализации: серверная
часть, клиентская часть, планшеты, телефоны, датчики,
исполняющие устройства.
ЖЦ: формирование требований к системе, проектирование, реализация, тестиро
http://intuit.ru
5.Формализация предметных областей ИС и технологий
разработки — экономический эффект.

5.

Проектирование
Необходимо построить ряд согласованных моделей в
соответствии с жизненным циклом.
1. Анализ терминов, объектов и свойств предметной
области. Результат — Онтология предметной области.
2. Моделирование бизнес-процессов — SADT (IDEF0),
BPMN-2.0, ARIS — формулирование требований.
3. Архитектура — Концепция реализации и
взаимодействия.
4. Информационная модель — Объекты хранимых
данных.
5. Уровень бизнес-логики — Концепция реализации
логики.
ЖЦ: формирование требований к системе, проектирование, реализация, тестиро
http://intuit.ru
6. Интерфейсы и реализация — Программный код.
7. …..........

6.

Онтологии
В саду растут 8 слив и яблони, яблонь
на 4 больше, чем слив.
Сколько деревьев растет в саду?
Дерево
Дополнительная
информация
Слива
disjoint
Яблоня

7.

SADT,
IDEF0
Более общее описание
Более детальное описание
Структурная
декомпозиция
Блок A4 декомпозируется
в этой диаграмме
Номер блока показывает посл
"6 Decomposition Structure" by itl.nist.gov - FIPS Publication 183. Licensed under Public Domain via Wikimedia Commons - https://c

8.

OMG BPMN 2.0.
Моделирование БП
в динамике
t

9.

ERдиаграммы

10.

UML2.0

11.

Model Driven Architecture

12.

Разработка ПО, управляемая
моделированием
CIM концептуальная модель, внешние спецификации,
интерфейсы и требования к ПО. Скрывает особенности
структурных элементов.
PIM представляет структурный аспект ПО и, в некоторой
степени, семантический; не содержит информации о
аспекте реализации на целевой архитектуре (UML Class
Diagram).
PSM – модель, описывающая, аспекты реализации ПО.
Исходный код генерируется в соответствии с этой
моделью при помощи шаблонов (например, DDL).
PM (PDM) описывает как структуры PIM
трансформируются в структуры PSM. PD – модель
процесса реализации.

13.

Model Driven Architecture
PIM
PM

14.

Пример реальной PIM

15.

Порождающее
программирование
как инструмент MDE

16.

17.

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

18.

Направления использования
●Декларативное моделирование - общая тенденция совершенствования
средств разработки программных систем
oВизуальное проектирование информационных систем (UML, ER) и
протоколов обмена информацией;
oПрограммирование, управляемое данными (DDA, MDATTR);
oИнтерфейсы доступа к данным (FlexT);
oКонфигурирование [состава] прикладных пакетов: организация процесса
разработки ПО;
oРезультат планирования действий (problem solving).
oРазработка и использование выразительных языков представления
предметной области Domain-specific language (DSL), Language-oriented
programming (LOP).
Решение задач в общем виде с дальнейшей высокоуровневой
оптимизацией программ
oПорождение частных случаев программ. Смешанные вычисления,
Суперкомпиляция.
oЯзыки программирования D, C++ средства настраиваемого (generic)
программирования.

19.

20.

Language-Oriented Programming
Правила трансформации
К исходному коду DSL применяются различные трансформации (упрощения,
оптимизации),
осуществляется
проверка
корректности,
а
затем
производится генерация кода.
to-python:
Entity(x, p*, r) ->
$[ class [x](models.Model):
[p'*]
def __unicode__(self):
return "[x]: {0}".format([to-string])
]
with
to-string := <to-string-repr> r;
p'* := <to-python> p*

21.

22.

23.

24.

Анализ конфигурации (ИС ПРР)
Конфигурация в МДА синтезируется в результате
интерпретации модели.
class RulesMixing:
def rule_primitive_class(self, cls, oid, oidType):
"""
primitive_class(Cls, OIDAttr, OidType):element(Cls, 'Class'), \+stereotype(Cls, 'abstract'), stereotype(Cls, 'OODB'),
\+internal_only(Cls), stereotype(Cls, 'primitive'),
attribute(Cls, OIDAttr),
type(OIDAttr, OidType),
stereotype(OIDAttr, 'OIDkey'),!.
"""
self.BASE_CLASS = cls
self.BASE_CLASS_NAME = self.getName(cls)
self.OID_NAME= self.getName(oid)
self.OID_TYPE = self.coerceAttrType(oid, oidType)
return self.BASE_CLASS.getName(), cls, oid, self.OID_NAME

25.

26.

MDA: достоинства и недостатки
•Этап проектирования ПО не зависит от платформы
реализации; можно заменять одну целевую платформу (PM
или ее части) другой без изменения PIM.
•Знания программиста представлены формально в виде
PM.
•Повышается уровень автоматизации разработки ПО на
этапах проектирования.
•Использование MDA в несложных проектах увеличивает
время разработки ПО;
•Ограничено применение MDA для развития уже созданных
программных систем и баз данных;
•Изменения сгенерированного программного кода по PIM
игнорируется процедурами трансформации.

27.

Актуальные задачи MDA
* Разработка процедур трансформации
моделей состояния (BPMN-2.0, UMLдиаграммы состояний и т.п.).
* Внесение изменений в данные при
изменении структур данных.
* Конструктивный синтез процедур,
обеспечивающих верификацию и
обеспечение выполнимости ограничений.
* Распространение изменений PSM в PIM
и PM (в т.ч. декомпиляция).

28.

Трассировка объектов в MDE
CIM
PIM
PDM
PSM
Исходный
Код
Шаблоны
кода

29.

ГеоАРМ: Автоматизация привязки
данных к ГИС
Выразительные средства языка описания
БД обеспечивают возможность настройки
большого перечня параметров приложения.
конструкции языка позволяют
детально описать структуру БД (уровень
Schema),
представление информации
пользователю (уровень Display).
Для существующих баз данных первый
вариант спецификации получается в
результате анализа структуры БД. Далее
уточняется разработчиком.

30.

Описание таблицы
30

31.

Описание представления
31

32.

33.

Редактор БД (табличный режим)
Интерфейс для работы с БД создаётся динамический по
спецификации
33

34.

Редактор БД
(режим редактирования записи)
За автоматическую
расстановку элементов на
форме отвечает менеджер
компоновки, управляющий
размерами и положением
визуальных компонентов
при изменении размеров
формы.
34

35.

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

36.

Взаимодействие с Картографическим модулем
36

37.

Построитель отчётов
•Реализован в виде надстройки.
•Использует шаблоны MS Word,
содержащие элементы разметки
текста (метки).
•Поддерживает условия.
•Поддерживает склонение по
падежам (padeg.dll).
•Поддерживает вставку
пространственных данных (при
вызове из картографического
модуля)
37

38.

Глава 4.Применение инструментальной
системы «ГеоАРМ»
Для оценки эффективности было проведено сравнение ГеоАРМ и MS
Access на примере разработки ПБД для БД «Pubs».
БД «Pubs» имитирует хранилище издательской компании и состоит из 11
таблиц.
Количество операций на этапах создания ПБД "Pubs"
20
18
18
16
14
12
10
7
8
6
3
4
2
1
1
6
4
3
0
3
0
0
0
Создание
подключения
Уточнение
связей вида LR
Уточнение
Разработка Разработка форм
связей вида DR представлений
ГеоАРМ
MS Access
Реализация
связей DR в
формах
38

39.

40.

Стоимость внесения изменений
Заключение

41.

Заключение
MDE (MDA,DDE) — средство борьбы со
сложностью и неопределенностью в
процессе проектирования и реализации
ИС.
Проблемная область MDE полна
различных задач и фундаментальных
проблем, которыми стоит заниматься.

42.

Вопросы.