Рубрика «UML»

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

Зачем нам UML? Или как сохранить себе нервы и время - 1

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

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

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

Читать полностью »

Введение

В рамках предыдущих статей мы описали: область применения, методологические основы, пример архитектуры и структуры. В данной статье, я хотел бы рассказать как описывать процессы, о принципах сбора требований, чем отличаются бизнес требования от функциональных, как перейти от требований — к коду. Рассказать о принципах применения Вариантов Использования (Use Case) и как они нам могут помочь. Разобрать на примерах варианты реализации шаблонов проектирования Interactor и Service Layer.

likeyourgrandmom

Примеры приведенные в статье даны с использованием нашего решения LunaPark, оно поможет вам с первыми шагами в описанных подходах.

Отделяем функциональные требования от бизнес требований.

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

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

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

Читать полностью »

UML&Enterprise Architect: проектируем целевой процесс при создании автоматизированной системы - 1
Советский плакат «Автоматическую систему управления производством — народному хозяйству!», художник Р. Сурьянинов, 1972

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

Предыстория

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

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

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

Читать полностью »

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

От моделирования процессов к проектированию автоматизированной системы (Часть 2) - 1
Использована иллюстрация к "Сказке о царе Салтане" А.С.Пушкина, изд."Детская литература", Москва, 1949 год, Ленинград, рисунки К.Кузнецова

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

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

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

Читать полностью »

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

От моделирования процессов к проектированию автоматизированной системы (Часть 1) - 1
Использована иллюстрация к "Сказке о царе Салтане" А.С.Пушкина, изд."Детская литература", Москва, 1949 год, Ленинград, рисунки К.Кузнецова

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

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

Читать полностью »

PlantUML — все, что нужно бизнес-аналитику для создания диаграмм в программной документации - 1

Введение

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

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

Читать полностью »

Здравствуйте, уважаемые читатели. Представляю вашему вниманию перевод статьи From Draw.io to Vue.js app автора Francesco Zuppichini.

Это моя первая публикация на Хабре и я решил начать с перевода статьи об одном классном инструменте, который позволяет сгенерировать Vue.js приложение из UML диаграммы.
Удивлены? Я был просто восхищен, когда наткнулся на него.

Конечно же, как и в любой бета версии, там есть над чем поработать. Например первым делом я связался с автором и сказал, что хочу внести исправления в структуру шаблона компонентов и именование путей. Автор вышел в течении часа на связь, выложил код на GitHub и написал небольшой туториал. После принятия PR было получено разрешение на перевод статьи, с указанием ссылки на оригинал.

Кому интересно — прошу под кат.

Читать полностью »

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

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

Как проектируют программы: от UML до автоматного подхода - 1Читать полностью »

image

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

Уже несколько лет я, как аналитик, довольно широко использую в своей работе сценарии использования (СИ) и диаграммы СИ для документирования требований. Вообще, у сценариев использования есть разные названия. Их называют use cases, варианты использования и даже прецеденты. Помню, как в середине 2000-х, на некоторых аналитических ресурсах шло жаркое обсуждение того, как же перевести термин use case на русский язык. Вот тогда это страшное слово «прецедент» и появилось, даже более того, некоторые товарищи утверждали, что русский язык ущербен и не позволяет передать все тонкости понятия use case. Но как показало время, понятие сценарий использования (или вариант использования) вполне себе подходит и довольно приятно на слух.
Читать полностью »