вторник, 18 декабря 2018 г.

Разработка систем на основе моделей в 1С !

Часто про моделирование - как средство разработки систем и приложений говорят, как о технологии будущего. Что на самом деле не так. Это технология будущего, но будущего, которое уже наступило. Ярким примером использования данной технологии является платформа 1С: Предприятие.

Платформа 1С предоставляет возможности разработки бизнес приложений на основе модели.
Вот выдержки из описания платформы, которая очень четко определяет 1С:Предприятие как систему разработки на основе моделей:

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

Платформа и прикладные решения

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

Метаданные - способ описания прикладного решения

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

Построение прикладного решения на основе модели

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

Данное описание взято с сайта 1С по ссылке

Я уже писал ранее, что 1С разрабатывает новые средства разработки на замену 1С. Конфигуратора на базе технологий Eclipse для создания моделей
https://trip-to-mbsd.blogspot.com/2018/01/1-enterprise-development-tools-eclipse.html

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


четверг, 15 февраля 2018 г.

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

Сегодняшний микро-пример - это пример описания физической структуры в Capella на примере модели окна в стене из бруса.

Для установки окна в проем окна сначала устанавливается окосячка и уже в нее устанавливается окно. Детали окосячки соединяются с помощью замков, 3D модель которых выглядит вот так. Если кликнуть по модели ниже, то ее можно будет повертеть в браузере.


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



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



Пенный шов между окном и четвертью в окосячке отображен на следующей диаграмме

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




Как выглядит полная физическая струкутра окна окосячки можно представить по скриншоту браузера модели. 





суббота, 10 февраля 2018 г.

Модель в Capella - это модель экземпляров

Начиная использовать Capella важно сразу разобраться, какие элементы в модели являются определениями, а какие элементы являются экземплярами.  Для этого важно понимать отличие между такими понятиями как класс\объект\экземпляр. Начиная работать в Capella изначально предполагаешь, что создавая некоторое структурное или функциональное описание в Capella, ты создаешь модель определений. А дальше возникает вопрос а как теперь создать модель, которая содержит несколько экземпляров на основе этих определений? Например, как создать модель, которая содержит несколько экземпляров подсистем или несколько экземпляров функций.

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

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

И большинство из перечисленных выше элементов являются "экземплярами", а не определениями.

Модели систем в Capella предназначены для описания РЕАЛЬНЫХ систем. Реальных не в смысле механических и т.п. Реальныеми могут быть и программные системы. Реальных в смысле не абстрактных, а тех которые существуют в мире, либо должны быть созданы. 

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

Модель физической архитектуры системы, также как и сама система состоит из конкретных экземпляров. Каждому элементу модели Capellaa в реальном мире существует или будет создан конкретный объект. Например в модели экземпляров для дома, будут включены элементы всех 100 розеток, элементы портов для всех 100 розеток, отдельные функции для всех 100 розеток, отдельные порты для всех 100 розеток, отдельные связи, которые свяжут эти 100 розеток с конкретными коммутаторами и т.д.

С физической архитектурой более менее понятно. Но и описания более высокого уровня в Capella являются моделями экземпляров. Моделями экземпляров в Capella также являются операционная архитектура, модель системного анализа, логическая архитектура. Логическая архитектура содержит конкретные экземпляры логических подсистем. Если таких подсистем несколько, то модель логической архитектуры будет содержать несколько ЭКЗЕМПЛЯРОВ подсистем и связанных с ними элементов модели (вложенных экземпляров, функций экземпляров, портов экземпляров, связей экземпляров).

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

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

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

Всегда ли нужно разделять определения элементов и экземпляры в модели? Нет, не всегда, а только тогда, когда предполагается наличие нескольких экземпляров данного элемента. Если в модели экземпляров квартиры все шкафы уникальны, то можно сразу создавать в модели экземпляров описания экземпляров. А вот для одинаковых стульев лучше создать определение и в модели экземпляров создавать элементы на основе определений.

Если с понятиями определение - экземпляр все более менее понятно, то чуть сложнее с понятиями класс\объект\экземпляр. Когда мы определяем абстрактную табуретку (класс) мы говорим, что табуретка включает абстрактные ножки (объекты). Ножки - объекты внутри описания класса - это не экземпляры. В описании класса всего 4 объекта ножки. А в 10 табуретках 40 экземпляров. При описании классы мы определяем для него свойства такие как цвет, текстура. Для объекта можно задать некоторые конкретные значения свойств класса. Например для объектов ножек табуретки можно задать цвет. Но при изготовлении табуреток цвет конкретных экземпляров будет отличаться.

Подход к работе с определениями\экземплярами в Capella отличается от других инструментов. Большинство элементов модели -это конкретные экземпляры. Необходимо сразу понимать это и тогда сложностей с определениями и экземплярами в модели не будет.

четверг, 25 января 2018 г.

Микро примеры по использованию языка Capella (snippets)

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

Я планирую делать и выкладывать само-говорящие микро примеры по использованию языка Capella. Микро примеры позволяют не углубляясь в теорию кратко проиллюстрировать возможности языка. Микро примеры не потребуют от меня больших усилий и позволят не откладывать на потом передачу знаний, полученных мною при изучении Capella при создании "больших" моделей.

Первый микро пример иллюстрирует следующие функциональные взаимодействия:
- функциональное взаимодействие человека с воздухом в помещении
- функциональное взаимодействие человека с диваном и откидным стулом
- функциональное взаимодействие дивана и стула с основанием и стеной

Зелеными прямоугольниками на рисунке изображены функции. Синими/голубыми - компоненты. Компоненты выполняют функции, которые находятся внутри.

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


Видео демонстрация учебной модели

Доступна видео демонстрация модели
Управление железнодорожным переездом для Capella
https://www.youtube.com/watch?v=4jSoVNb4gaQ



Размещение функции по компонентам структуры в Capella

Сделал небольшую презентацию которая иллюстрирует как выглядят функциональныные/структурные описания в Capella.
Презентация


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


Возможность исполнения/анимации разрабатываемых моделей и инструментов

http://gemoc.org/ - фреймворк для разработки языков/инструментов моделирования, позволяющий добавить возможность исполнения/анимации к разрабатываемым моделям/инструментам.

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

По ссылке презентации об исполнении моделей Capella
http://gemoc.org/pub/anr/finalworkshop/2016-03-anr-gemoc-workshop-final-experimentations.pdf

понедельник, 22 января 2018 г.

Ускоряем контекстное меню в Capella Project Explorer

В последних версиях Capella Project Explorer контекстное меню,  используемое для создания элементов и диаграмм, стало работать ну очень медленно. Пришлось искать решение. И решение было быстро найдено.

Замедление меню имеет место в Capella версий 1.1.x (Eclipse Mars) и 1.2.x (Eclipse Neon).

Разработчики Capella быстро отреагировали и нашли решение для ускорения меню.
https://bugs.polarsys.org/show_bug.cgi?id=1916

В моем случае работа меню была восстановлена после следуюших действий:
- Обновление Java 8 Update 151 to Java 8 Update 161
- Добавление дополнительного флага в eclipse.ini

В Eclipse Mars и Neon есть проблема со скоростью работы динамических меню. Пока в Eclipse реализован workaround. Для его применения в текущей версии Capella необходимо добавить в файл eclipse.ini флаг:

-Declipse.workaround.bug467000=true
В результате eclipse.ini для Capella 1.2.0 должно выглядеть вот так:
-startup
plugins/org.eclipse.equinox.launcher_1.3.201.v20161025-1711. jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1. 401.v20161122-1740
-vmargs
-Dosgi.requiredJavaVersion=1.8
-Declipse.workaround.bug467000=true
-Xms1000m
-Xmx3000m
-Xss4m

Данный workaround будет включен в следующей версии Capella, а пока нужно добавлять вручную. 

Поддержка клавиатуры для создания элементов модели Capella

Реализовал поддержку клавиатуры для создания новых элементов модели в Capella Project Explorer.

Давно мучился от того, что в менеджере модели Capella нельзя было создавать элементы модели с использованием клавиатуры, а только с помощью контекстного меню.

Создавать элементы с помощью контекстного меню само по себе медленно, а тут еще возникла проблема, что контекстное меню стало очень долго появляться. Как оказалось, проблема производительности возникла из-за Java 151 updata. Обновление до Java 161 решило проблему.

Но благодаря этой проблеме, я наконец-то реализовал поддержку клавиатуры для создания элементов модели в Capella Project Explorer.

Вот так это теперь выглядит



Выложил update site с плагином по ссылке (версия 0.2)
https://yadi.sk/d/IOs23v7q3RgFjg

В данной версии доступны следующие команды с клавиатуры:
- Ins - добавить элемент\пакет того же типа после выбранного элемента\пакета
- Alt-Ins - добавить дочерний элемент\пакет того же типа для выбранного элемента\пакета
- Ctrl-Ins - добавить элемент с типом по-умолчанию в выбранный пакет

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

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

Разработчики пишут, что в Thales для создания модели использую диаграммы, а браузер модели не используют. Мне это не понятно и кажется не правильным. Однако, после выкладывания начальной версии плагина, разработчики Capella написали мне, что в будущем можно будет интегрировать мой код по поддержке клавиатуры в Capella.

пятница, 19 января 2018 г.

1С: Enterprise Development Tools основана на Eclipse, EMF, Xtext

Новая среда разработки для 1C Предприятия основана на Eclipse и технологиях EMF и Xtext!

Язык программирования 1С в редакторе ниже реализован с использованием EMF и XText



Обзор среды разработки 1С: Enterprise Development Tools
http://v8.1c.ru/overview/release_IDE/

Статья на Хабре про технологии Eclipse для 1С: Enterprise Development Tools
https://habrahabr.ru/company/1c/blog/323508/

среда, 17 января 2018 г.

Интеграция стандартных/DSL языков в редакторы на основе технологии языковых серверов

Технология языковых серверов позволяет разрабатывать стандартные/DSL текстовые языки один раз и использовать их в различных редакторах, таких как Eclipse, Visual Studio Code и т.д. Технология языковых серверов изначально разработана Microsoft, сделана open source, и поддержана в других проектах.

Microsoft разработала новый редактор Visual Studio Code, который изначально основан на технологии языковых серверов.
https://code.visualstudio.com/

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

На следующей странице доступен список языков, для которых реализованы языковые сервера. Список достаточно внушителен.
https://langserver.org/

Примечательно, что над разработкой редактора Visual Studio Code работает Erich Gamma, один из ключевых разработчиков Eclipse.

Технология языковых серверов теперь поддержана и в Eclipse в рамках проекта LSP4E
https://projects.eclipse.org/projects/technology.lsp4e
Пока это версия 0.4, версия 1.0 ожидается летом 2018 года.
Например, в результате данной поддержки в Eclipse становится возможным использовать Net языки, такие как C#
https://marketplace.eclipse.org/content/acute-c-edition-eclipse-ide-experimental

Ранее я писал про технологию Xtext, которая позволяет создавать собственные DSL и редакторы для них. Ранее речь шла от редакторах в рамках Eclipse. Теперь же применение данных DSL расширяется.

Возможность генерации языковых серверов для собственных DLS теперь включена и в средства разработки Xtext. Это позволяет разрабатывать собственные DSL, доступные как в Eclipse, так и в Visual Studio Code
https://www.eclipse.org/community/eclipse_newsletter/2017/may/article5.php

Учебная модель управления железнодорожным переездом для Capella

Новая учебная модель Level Crossing Traffic Control для Capella доступна по ссылке.
Данная модель ииспользуемая для иллюстрации Arcadia в книге
Model-based System and Architecture Engineering with the Arcadia Method

Данная модель описывает систему управления железнодорожным переездом и включает все уровни описания : от операционного анализа до организационного (EPBS). Это самая большая и наиболее полная модель Capella, доступная в открытом доступе. Рекомендую.


среда, 10 января 2018 г.