UML Design *

1. Введение

Услышав из авторитетных уст, что «автоматы — вещь событийная» [3], понял, что конечные автоматы заклеймили окончательно. Судите сами: в библиотеке Qt реализована событийная модель автоматов [1], в UML — они же [2], смотрим на автоматы пакета расширений Simulink-Stateflow системы MATLAB [4] (далее просто Stateflow) и там о событиях и т.д. и т.д. В таком контексте утверждение д.т.н. А.А. Шалыто трактовать по-другому сложно, т.к. ничего иного уже не может быть, потому что быть не может.

Но, если вспомнить теорию конечных автоматов (ТКА), то в ней о событийных автоматах нет ни слова! Но чтобы противоречить теории нужны веские аргументы. А есть ли основания сомневаться в профессионализме Д. Харелла, как создателя нотации, на которой базирует свои идеи язык UML, пакет Stateflow, которые в свою очередь небезызвестны А.А. Шалыто? Ведь, UML, Stateflow, SWITCH-программирование и иные варианты автоматного программирования существуют и в той или иной мере успешно работают.

Так можно ли снять «клеймо событийности» с модели конечных автоматов, отделив «котлеты от мух»? Т.е. разделить теорию автоматов и вычислительные модели, подобные модели Д.Харела. И считать, что последние, хотя и используют терминологию теории автоматов, представляют, судя по их реализации, развитие модели блок-схем программ.

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


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

Программисты, не использующие UML, делятся на несколько групп:

• начну писать код, а в процессе пойму, что да как;
• почитаю форумы, хабр, medium, stack overflow, книгу, записи на стенах, знаки свыше…;
• поспрашиваю у коллег, может, кто-то знает, как решить подобную задачу;
• начну рисовать квадратики и схематично покажу, какое видение задачи сформировалось у меня в сознании.

Советский плакат «Автоматическую систему управления производством — народному хозяйству!», художник Р. Сурьянинов, 1972

«Рассказ о моделировании именно сложных систем»

Предыстория

К одной из моих статей по моделированию «сказочной» предметной области (часть 1, часть 2) был оставлен комментарий, цитирую:

«Было бы здорово увидеть рассказ о моделировании именно сложных систем».

И я пообещала подобрать что-то из реальной жизни.

Уточняем описание функций системы с помощью диаграммы Sequence (продолжение "Белки")

В данной статье рассмотрим, как можно детализировать (уточнить) описание автоматизируемой функции с помощью UML Sequence Diagram — диаграммы последовательности.

В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].
Полную спецификацию UML см. здесь [2].

Для начала поясню, что мы будем детализировать.
В 1-ой части статьи "От моделирования процессов к проектированию автоматизированной системы" мы моделировали процессы «сказочной» предметной области — строчки про белку из "Сказки о царе Салтане" А.С.Пушкина. И начали мы с диаграммы Activity. Потом во 2-ой части мы разработали функциональную модель с помощью диаграммы Use-case, на Рисунке 1 представлен фрагмент.

Рисунок 1. Связь требования и функции

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

• с какими компонентами интерфейса будет взаимодействовать наш пользователь;
• какие управляющие компоненты нам понадобятся;
• что мы будем хранить;
• какими сообщениями будут обмениваться пользователь и компоненты системы для выполнения функции.

Сравнение двух подходов структурирования диаграммы Activity (по мотивам "Белки")

В 1-ой части статьи "От моделирования процессов к проектированию автоматизированной системы" мы моделировали процессы «сказочной» предметной области — строчки про белку из "Сказки о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди" А.С.Пушкина. И начали мы с диаграммы Activity, договорившись о структурировании поля диаграммы с помощью «плавательных» дорожек – Swim lanes. Имя дорожки соответствует типу элементов диаграммы, которые присутствуют на этой дорожке: «Входные и выходные артефакты», «Шаги процесса», «Участники» и «Бизнес-правила». Этот подход отличается от стандартного, когда дорожки обозначаются именами участников процесса, таким образом закрепляя за ними определенные зоны ответственности в процессе.

В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].

Подробнее о применяемых подходах к моделированию см. [2].

Полную спецификацию UML см. здесь [3].

«Один день из жизни белки» или от моделирования процессов к проектированию автоматизированной системы учёта материальных ценностей «Белка-1.0» (Часть 2)

Использована иллюстрация к "Сказке о царе Салтане" А.С.Пушкина, изд."Детская литература", Москва, 1949 год, Ленинград, рисунки К.Кузнецова

Краткое содержание предыдущей серии

В 1-ой части мы использовали «сказочную» предметную область, вдохновленные примерами изучения диаграмм UML с опорой на сюжеты сказок (см., например, здесь [1]). До начала моделирования мы договорились относительно использования некоторых элементов диаграммы Activity и начали формировать соглашение по моделированию. С учетом этих договоренностей мы на 1-ом этапе описали процесс в виде диаграмм Activity, а на 2-ом этапе выделили шаги процесса, для которых требуется (и возможна) автоматизация.

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

«Один день из жизни белки» или от моделирования процессов к проектированию автоматизированной системы учёта материальных ценностей «Белка-1.0» (Часть 1)

Использована иллюстрация к "Сказке о царе Салтане" А.С.Пушкина, изд."Детская литература", Москва, 1949 год, Ленинград, рисунки К.Кузнецова

При чем тут «белка»?

Сразу поясню, при чем тут «белка». Наткнувшись в Сети на забавные проекты для изучения UML с опорой на предметную область, заимствованную из сюжетов сказок (например, здесь [1]), я для своих студентов тоже решила подготовить подобный пример, чтобы можно было изучить для начала всего три вида диаграмм: Activity Diagram, Use-case Diagram и Class Diagram. Умышленно не перевожу на русский язык названия диаграмм, чтобы избежать споров о «трудностях перевода». Что для чего – поясню немного позже. В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [2] – хороший инструмент за разумные деньги. А в рамках учебных занятий применяю Modelio [3], неплохое бесплатное средство объектно-ориентированного проектирования, поддерживающее стандарты UML2.0 и BPMN, без излишних наворотов в части изобразительных возможностей, но вполне достаточное для изучения основ языка.

В некотором царстве, в некотором государстве... понадобилось мне добавить триггер в модель на pgModeler. Что сделать достаточно легко. А вот добавить триггерную функцию… Тоже легко, но пришлось немного поразбираться с параметрами, предлагаемыми для заполнения/выбора в интерфейсе.

pgModeler — это весьма неплохой инструмент для проектирования баз данных, который умеет генерировать sql-скрипты для PostgreSQL. Подробно об этом инструменте и его возможностях можно почитать на официальном сайте.

Однажды в студёную зимнюю... день понадобился мне бесплатный инструмент для проектирования баз данных. Такой, который бы ещё и скрипты умел генерировать. Очень нравится Visual Paradigm, но стоит он, конечно, как самолёт. Поэтому, вооружившись гуглом и советами знакомых разработчиков, отправился я на поиски.

В итоге набрёл на весьма неплохой инструмент pgModeler. Единственное, не очень понравилось, что sql-скрипты он умеет генерировать только для PostgreSQL. Но т.к. на тот момент (да и сейчас, а то и потом) использовалась эта база данных, то этого инструмента было вполне достаточно.

Введение

Я — системный аналитик, и моя работа заключается в том, чтобы проектировать автоматизированные информационные системы. Впрочем, нет, она заключается в том, чтобы писать и писать документы. Третий раз слово «писать» повторять не буду — все-таки, не «Илиада». Но занудность формы чем-то определенно роднит проектную документацию с древнегреческой поэмой, особенно если речь идет о работе с государственным заказчиком.

Диаграммы — глоток творчества в этом море текста. О диаграммах и пойдет речь в данной статье. Если точнее — о PlantUML — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.

Дорогой Хабр, мы решили поделиться заметками и нашим базовым рецептом о приготовлении проектов в Sparx Enterprise Architect. Причем под проектом мы подразумеваем создание какой-либо информационной системы. Впереди вас ждет рассказ о том, как у нас все организовано – примеры диаграмм, структура проекта в Enterprise Architect, немного о требованиях, проектировании и постановках на разработку.

Источник

Введение

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

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



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

С тех пор как я начал выполнять обязанности системного архитектора, мне чаще приходится рисовать прямоугольники и стрелки, чем писать программный код. С этим можно было бы бороться, например, бессонными ночами участвовать в проектах с открытым исходным кодом, создавать подтверждения осуществимости концепции и демонстрационный код, но и там тоже нужно рисовать прямоугольники, чтобы продемонстрировать архитектуру. Эта статья посвящена визуализации обмена сообщениями в распределенных системах, сервис-ориентированной архитектуре (SOA) и микросервисным приложениям при использовании методологии разработки agile (этот термин потерял свое значение, но более подходящего в данном случае нет).

Предисловие

Не секрет, что современный разработчик старается повысить эффективность и призывает себе на помощь библиотеки и каркасы.

Слово framework(каракас) настолько вошло в обиход, что стала встречаться путаница — что можно назвать каркасом, а что таковым не является?

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

Здравствуйте. Эта статья — небольшой обзор инструмента, который помогает разбираться с устройством и структурой данных пакетов и классов внутри СУБД Caché.

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

Тех, кто обучается или ведёт обучение по технологиям InterSystems, днями просматривает или изменяет коды разных проектов и просто заинтересованным лицам — приглашаю ознакомиться с Caché Class Explorer!

Сегодня напишем преобразование, которое создаёт преобразование. Лично мне это напоминает «Начало» Кристофера Нолана, где люди видели сны во снах.

Это 7-ая статья цикла по модельно-ориентированной разработке. Я уже полгода пытаюсь написать статью с серьёзным примером разработки, управляемой моделями. Но каждый раз пониманию, что сначала необходимо рассказать о технологиях в целом, разобрать какой-нибудь очень простой пример. Так и в этот раз, хотел только начать статью с «Hello World», а в итоге этот простой пример вырос в здоровенную статью.

Это третья статья цикла, посвященного разработке, управляемой моделями. В предыдущих статьях мы разбирались с OCL и метамоделями, создавали свою метамодель для языка Anchor с древовидным редактором. Сегодня сделаем редактор Anchor-диаграмм.

Это вторая статья цикла, посвященного разработке, управляемой моделями. Сегодня мы создадим метамодель, основанную на метаметамодели Ecore. Вскользь затронем моделирование данных, а именно Anchor, 6НФ и концептуальное моделирование.

На наш взгляд, объектный язык ограничений (Object Constraint Language, OCL) должен знать каждый, кто занимается моделированием или кому интересна модельно-ориентированная разработка. Однако, он незаслуженно обделен вниманием в сети вообще, а, уж, в русскоязычном сегменте информации просто мизер. Что это за язык и зачем он нужен, описано в этой статье. Статья не претендует на фундаментальность, полноту охвата, точность определений и т.п. Её задача: 1) на простых примерах познакомить с OCL тех, кто никогда не слышал об этом языке, 2) а для тех, кто о нём слышал, возможно, открыть новые способы его применения.