Рубрика «UML»

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

Мы часто изобретаем собственный язык, без знания которого диаграмма не считывается. Это системная проблема, даже архитекторы ею страдают. Например, я видел диаграмму, к которой авторы нарисовали легенду, чтобы сделать понятной для непосвящённых. Но всё учесть не смогли. Сидишь и думаешь: «Что значит эта стрелочка? Какое отношение между этими двумя сущностями?»

Язык диаграмм - 1

Задача передачи мысли от одного разработчика другому с помощью диаграмм стоит давно. Умные дяденьки не раз её обдумывали и изобрели специальный универсальный язык диаграмм — UML (Unified Modeling Language): это такой междисциплинарный способ рисования схем, который одинаково понятен всем, кто этот язык знает.

Расскажу, как с этим живётся на практике.
Читать полностью »

UML умер, а никто и не заметил? - 1

UML, нам будет тебя не хватать
Unified Modelling Language (UML), разработанный Rational Software и принятый в качестве стандарта Object Management Group (OMG) в 1997 году, призван был стандартизировать множество различных типов графических нотаций, принятых в отрасли разработки ПО.

Моя история отношений с UML началась почти десяток лет назад, когда я стал евангелистом этого языка как моста между ИТ и бизнесом. Я никогда не был полностью убеждён в ценности UML как нотации для моделирования конкретных программных продуктов; моя цель заключалась в использовании UML для описания требуемых структурных и поведенческих свойств, ожидаемых от проектируемой системы.
Читать полностью »

Интернет полон статей про UML, вы найдете сотни примеров для каждого вида диаграмм, и без проблем создадите свои, нотация не сложная. Но так ли уж необходимо тратить на это время? Наш богатый опыт говорит «Да». Если у вас в команде более 2 человек и проект от 3 месяцев, то уже имеет смысл отрисовать 2-3 вида диаграмм. В одной нашей команде более 30 человек, проект длительностью более 3 лет, и мы используем...2-3 вида диаграмм.

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

Студенты пишут Uart драйвер для STM32F411 - 1

Доброго здравия всем!

Сегодня я хочу вам рассказать, как постепенно студенты учатся разрабатывать ПО для микроконтроллера на примере драйвера UART на STM32F411. Код и архитектуру с небольшими моими изменениями и доработками я попытаюсь привести здесь.

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

Данная статья не претендует на истину, а лишь показывает подход к реализации некоторых задач, в данном случае реализацию Uart драйвера на С++.

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

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

Зачем нам 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 — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js