Как построить четкие модели классов и получить реальные преимущества от UML. Часть 2
Вторая часть перевода статьи Леона Старра, инженера программных моделей. Первая часть вот здесь. В этой части — о семантике и о том, что отличает хорошую модель.
Как построить четкие модели классов и получить реальные преимущества от UML
Мне показался близким подход Леона Старра к объяснению чётких моделей классов и описанию их преимуществ. Настолько, что мы в Retail Rocket решили сделать перевод его большой статьи "How To Build Articulated UML Class Models". Будем выкладывать по частям, под катом — первая из трёх.
UML для самых маленьких: диаграмма классов
Аве, Кодер! Диаграмма классов UML иллюстрирует структуру системы, описывая классы, их атрибуты, методы и отношения между объектами.
Даже самые малые детки знают, что UML происходит от Unified Modeling Language, если по- русски, то — унифицированный язык моделирования, который, как гласит легенда, разработали, когда серьезные дяди и тети в конец задолбались плавать в разнообразии кружочков, черточек и облачков.
Для тех, кому лень читать:
Что находится между идеей и кодом? Обзор 14 диаграмм UML
Аве Кодер!
Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?
Этот цикл статей будет посвящен полезному, но порой ускользающему от молодой поросли знанию — диаграммам UML. И начну я его с обзора существующих диаграмм, поговорим немного об истории и зачем диаграмм должно быть так много.
Реализация инерционных алгоритмов на примере логического моделирование цифровых схем
1. Введение
Приступаем ко второй части темы, посвященной вложенным автоматам. В первой мы рассматривали рекурсивные алгоритмы, которые, имея модель вложенных автоматов и подключив возможности ООП, реализовать оказалось не столь уж сложно. Но возможности вложенных автоматов этим не исчерпываются. Так, при описании модели управления автоматных программ были определены инерционные алгоритмы, в основе которых также идея вложении автоматов. Инерционные алгоритмы сложно представить в рамках обычной блок-схемной модели вычислений, в которой совсем не предусмотрен возврат управления в точку, предшествующую вызову подпрограммы. Но надо сказать, что и у обычных автоматов предусматривается отмены переходов «на лету». Тем не менее, для автоматов подобное можно не только представить, но и реализовать.
UML для разработчиков
Нотация UML избыточна. С другой стороны она недостаточна для проектирования распределенных систем, и здесь нам помогает Archimate. В этой статье мы расскажем, что действительно полезно из всего этого многообразия, и рассмотрим на примере полный цикл создания диаграмм для проекта.
Автоматная модель управления программ
1. Введение
В [1] был дан ответ на вопрос, что считать автоматным программированием (АП), но не была подробно описана модель конечного автомата (КА) в качестве модели управления автоматных программ. При этом понятно, что чистый абстрактный автомат на эту роль не годится, т.к. ограничен числом каналов. Но и структурная модель автомата, как и соответствующая ей теория структурных автоматов, не позволяют пока дать ответ по выбору модели автомата.
Проблема начинается с того, что среди множества работ по теории конечных автоматов (ТКА) мало дающих определение модели структурного конечного автомата (СКА). Правда, можно понять, что структурный автомат — это [структурная] схема из элементарных автоматов (функциональных элементов), реализующая модель абстрактного автомата [2]. Напомним, что в соответствии с теорией все начинается с создания модели устройства в форме абстрактного автомата, а затем ставится задача синтеза цифровой схемы, которая его реализует [3].
Программирование на первый взгляд мало похоже на синтез цифровых схем. Но только на первый. Во-первых, там и там все начинается с алгоритма. Во-вторых, структурные вопросы организации и реализации цифровых схем и программирования имеют много общего, особенно в контексте параллельного программирования. Но тему параллелизма мы еще обсудим отдельно. Пока же наша задача выбрать и/или доработать модель конечного автомата, которая была бы понятна, удобна и приятна программистам, избалованных разнообразным программным инструментарием.
Правда, тут же закономерен вопрос — зачем еще один и довольно необычный «автоматный инструментарий»? На этот вопрос мы и попробуем ответить, дав определение модели [вложенного] автоматного управления, рассмотрев также ее преимущества по сравнению с обычной моделью программирования.
Автомат — вещь событийная?
1. Введение
Услышав из авторитетных уст, что «автоматы — вещь событийная» [3], понял, что конечные автоматы заклеймили окончательно. Судите сами: в библиотеке Qt реализована событийная модель автоматов [1], в UML — они же [2], смотрим на автоматы пакета расширений Simulink-Stateflow системы MATLAB [4] (далее просто Stateflow) и там о событиях и т.д. и т.д. В таком контексте утверждение д.т.н. А.А. Шалыто трактовать по-другому сложно, т.к. ничего иного уже не может быть, потому что быть не может.
Но, если вспомнить теорию конечных автоматов (ТКА), то в ней о событийных автоматах нет ни слова! Но чтобы противоречить теории нужны веские аргументы. А есть ли основания сомневаться в профессионализме Д. Харелла, как создателя нотации, на которой базирует свои идеи язык UML, пакет Stateflow, которые в свою очередь небезызвестны А.А. Шалыто? Ведь, UML, Stateflow, SWITCH-программирование и иные варианты автоматного программирования существуют и в той или иной мере успешно работают.
Так можно ли снять «клеймо событийности» с модели конечных автоматов, отделив «котлеты от мух»? Т.е. разделить теорию автоматов и вычислительные модели, подобные модели Д.Харела. И считать, что последние, хотя и используют терминологию теории автоматов, представляют, судя по их реализации, развитие модели блок-схем программ.
Зачем нам UML? Или как сохранить себе нервы и время
Зачастую это утверждение оказывается верным, если задача и правда небольшая и квалификации программиста достаточно для определения наиболее оптимального решения.
Программисты, не использующие UML, делятся на несколько групп:
- начну писать код, а в процессе пойму, что да как;
- почитаю форумы, хабр, medium, stack overflow, книгу, записи на стенах, знаки свыше…;
- поспрашиваю у коллег, может, кто-то знает, как решить подобную задачу;
- начну рисовать квадратики и схематично покажу, какое видение задачи сформировалось у меня в сознании.
UML&Enterprise Architect: проектируем целевой процесс при создании автоматизированной системы
Советский плакат «Автоматическую систему управления производством — народному хозяйству!», художник Р. Сурьянинов, 1972
«Рассказ о моделировании именно сложных систем»
Предыстория
К одной из моих статей по моделированию «сказочной» предметной области (часть 1, часть 2) был оставлен комментарий, цитирую:
«Было бы здорово увидеть рассказ о моделировании именно сложных систем».
И я пообещала подобрать что-то из реальной жизни.
Уточняем описание функций системы с помощью диаграммы Sequence
Уточняем описание функций системы с помощью диаграммы Sequence (продолжение "Белки")
В данной статье рассмотрим, как можно детализировать (уточнить) описание автоматизируемой функции с помощью UML Sequence Diagram — диаграммы последовательности.
В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].
Полную спецификацию UML см. здесь [2].
Для начала поясню, что мы будем детализировать.
В 1-ой части статьи "От моделирования процессов к проектированию автоматизированной системы" мы моделировали процессы «сказочной» предметной области — строчки про белку из "Сказки о царе Салтане" А.С.Пушкина. И начали мы с диаграммы Activity. Потом во 2-ой части мы разработали функциональную модель с помощью диаграммы Use-case, на Рисунке 1 представлен фрагмент.
Рисунок 1. Связь требования и функции
Теперь мы хотим уточнить информацию о выполнении данной автоматизируемой функции:
- с какими компонентами интерфейса будет взаимодействовать наш пользователь;
- какие управляющие компоненты нам понадобятся;
- что мы будем хранить;
- какими сообщениями будут обмениваться пользователь и компоненты системы для выполнения функции.
Два подхода к структурированию диаграммы Activity
Сравнение двух подходов структурирования диаграммы Activity (по мотивам "Белки")
В 1-ой части статьи "От моделирования процессов к проектированию автоматизированной системы" мы моделировали процессы «сказочной» предметной области — строчки про белку из "Сказки о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди" А.С.Пушкина. И начали мы с диаграммы Activity, договорившись о структурировании поля диаграммы с помощью «плавательных» дорожек – Swim lanes. Имя дорожки соответствует типу элементов диаграммы, которые присутствуют на этой дорожке: «Входные и выходные артефакты», «Шаги процесса», «Участники» и «Бизнес-правила». Этот подход отличается от стандартного, когда дорожки обозначаются именами участников процесса, таким образом закрепляя за ними определенные зоны ответственности в процессе.
В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].
Подробнее о применяемых подходах к моделированию см. [2].
Полную спецификацию UML см. здесь [3].
Ближайшие события
От моделирования процессов к проектированию автоматизированной системы (Часть 2)
«Один день из жизни белки» или от моделирования процессов к проектированию автоматизированной системы учёта материальных ценностей «Белка-1.0» (Часть 2)
Краткое содержание предыдущей серии
В 1-ой части мы использовали «сказочную» предметную область, вдохновленные примерами изучения диаграмм UML с опорой на сюжеты сказок (см., например, здесь [1]). До начала моделирования мы договорились относительно использования некоторых элементов диаграммы Activity и начали формировать соглашение по моделированию. С учетом этих договоренностей мы на 1-ом этапе описали процесс в виде диаграмм Activity, а на 2-ом этапе выделили шаги процесса, для которых требуется (и возможна) автоматизация.
Напомню, что автоматизировать мы собираемся деятельность по учёту материальных ценностей, которая возникает вот в этих процессах.
От моделирования процессов к проектированию автоматизированной системы (Часть 1)
«Один день из жизни белки» или от моделирования процессов к проектированию автоматизированной системы учёта материальных ценностей «Белка-1.0» (Часть 1)
При чем тут «белка»?
Сразу поясню, при чем тут «белка». Наткнувшись в Сети на забавные проекты для изучения UML с опорой на предметную область, заимствованную из сюжетов сказок (например, здесь [1]), я для своих студентов тоже решила подготовить подобный пример, чтобы можно было изучить для начала всего три вида диаграмм: Activity Diagram, Use-case Diagram и Class Diagram. Умышленно не перевожу на русский язык названия диаграмм, чтобы избежать споров о «трудностях перевода». Что для чего – поясню немного позже. В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [2] – хороший инструмент за разумные деньги. А в рамках учебных занятий применяю Modelio [3], неплохое бесплатное средство объектно-ориентированного проектирования, поддерживающее стандарты UML2.0 и BPMN, без излишних наворотов в части изобразительных возможностей, но вполне достаточное для изучения основ языка.
Создание триггерной функции в pgModeler
pgModeler — это весьма неплохой инструмент для проектирования баз данных, который умеет генерировать sql-скрипты для PostgreSQL. Подробно об этом инструменте и его возможностях можно почитать на официальном сайте.
Сборка pgModeler
В итоге набрёл на весьма неплохой инструмент pgModeler. Единственное, не очень понравилось, что sql-скрипты он умеет генерировать только для PostgreSQL. Но т.к. на тот момент (да и сейчас, а то и потом) использовалась эта база данных, то этого инструмента было вполне достаточно.
PlantUML — все, что нужно бизнес-аналитику для создания диаграмм в программной документации
Введение
Я — системный аналитик, и моя работа заключается в том, чтобы проектировать автоматизированные информационные системы. Впрочем, нет, она заключается в том, чтобы писать и писать документы. Третий раз слово «писать» повторять не буду — все-таки, не «Илиада». Но занудность формы чем-то определенно роднит проектную документацию с древнегреческой поэмой, особенно если речь идет о работе с государственным заказчиком.
Диаграммы — глоток творчества в этом море текста. О диаграммах и пойдет речь в данной статье. Если точнее — о PlantUML — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.
Готовим проект в Sparx Enterprise Architect. Наш рецепт
Легковесное ядро конечного автомата с автогенератором дерева для embedded проектов
Введение
В моей практике часто возникали ситуации, когда применение конечного автомата являлось наиболее верным решением, однако от него приходилось отказываться ввиду срочности разработки, сложности поддержки, или же по каким-либо иным причинам. В этом посте мне хотелось бы поделиться с вами разработанным мною решением, позволяющим без труда встраивать в свои проекты конечные автоматы с возможностью наглядного отображения структуры дерева.