Добрый день.

Имеется цель.
Есть жгучее желание привести в нормальный человеческий вид груду вордовско-экселевских спецификаций на систему, оставленных в разное время разными авторами (в том числе и мной) в разных формах и стилях.
Параллельно планируется плотно посмотреть собственно UML. Не до уровня сертификации OMG, но до уровня относительно свободного владения.
** Возможно я лукавлю и целью является именно "плотно посмотреть UML", благо под рукой гора подходящих кейсов. Но я уже убедил себя в обратном 


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

Опыт.
До недавнего времени напрямую в UML моделировать ничего не доводилось, максимум - небольшая диаграмма классов в Visio для небольшой же интеграции. Также встречал общие описания нотации с минимальными примерами в литературе. Это всё.
Для рабочих же целей использовались EPC и BPMN в зависимости от требований к детализации для согласования с пользователями + те же спецификации в Ворде для разработчиков.
** Здесь предлагаю не халиварить - если всё работает и всех устраивает - "ничего не меняй" 

Взяты книги:
-- Рамбо, Блаха "UML 2.0 Объектно-ориентированное моделирование и разработка"
Временно отложена - библии нужно смотреть уже при плотной работе, а не при освоении.
-- Буч,Рамбо,Якобсон "Язык UML руководство пользователя"
Прочитаны первые 5 глав и также есть желание отложить:
- Неудачный перевод, в книге почти не оставлено ссылок на родные английские термины, для работы в не русифицированном ПО их приводится переводить обратно и оставлять заметки на полях, а затем смотреть как и где это реализовано.
- Очень растянута и многократно пережевывается теоретическая часть. Слово "блоки" бесит уже к 60-й странице.
- Слабые примеры, строить тестовую модель параллельно с чтением очень сложно.

Средство моделирования.
Предварительно выбран Star UML. Просто потому, что имеет легкую бесплатную и недорогую платную версии. Для освоения - в самый раз, а о покупке монстров типа Rational речи пока не идет. Ломать ничего не собираюсь, триальные версии - под вопросом.

Что ищется.
Фактически нужен вводный практикум - небольшая задача, хотя бы классический "заказ поставщику" с хорошо разобранными (что делаем и почему) шагами создания модели - диаграмм, связей и прочего, после выполнения которой уже можно осознанно строить собственную модель,  параллельно сверяясь с литературой. На практике этот метод нравится больше всего.
Идеально - в виде электронной или бумажной книги.
Допустимо - в форме видеокурса.
Возможно - очные курсы небольшой продолжительности.
Бюджет, повторю, есть, но ограниченный. Потому что личный.

Буду благодарен за содержательные ответы.

Из книг лучше порекомендую Мартина Фаулера. Есть в электронном виде: http://www.books.ru/books/uml-osnovy-3-e-izdanie-fail-pdf-595320/?show=1

Он выделяет три уровня моделирования на UML (или "режима применения UML"):
- Эскизы
- Проектирование
- Программирование

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


И... вау! Они реанимировали StarUML! А мы его уже было похоронили... Я только не понял, бесплатная версия - это то, что у них называется V1?

greesha

Спасибо за ссылку, ушел покупать

И ...

И... вау! Они реанимировали StarUML! А мы его уже было похоронили... Я только не понял, бесплатная версия - это то, что у них называется V1?

Да, бесплатная версия - "V1". По ней даже нарыл студенческий курс и русскую документацию.

Насчет реанимации - это я не в курсе Но ничего страшного - меня зомби не смущают, доводилось работать на очень разном ПО, хелпы например на Serna пишутся, хотя и сайта разработчика уже нет.
Гораздо больше на данный момент ценно, что полная версия понятна по интерфейсу и весит всего 70$. Если пообвыкнусь за  триальный период - и купить не жалко. Понятное дело, что например Sparx выглядит куда мощнее и даже (через пень правда но ..) держит привычный BPMN. Но и денег на Corporate-версию (а ниже - нет смысла, ибо если уж брать, то хотя бы с моделированием GUI) нужно будет уже у шефа просить, сам не потяну наверное. А триала всего 30 дней.

Короче, я безусловно с удовольствием приму советы по выбору ПО, но на данный момент мне вполне комфортно.

Насчет реанимации - это я не в курсе Но ничего страшного - меня зомби не смущают, доводилось работать на очень разном ПО.
Гораздо больше на данный момент ценно, что полная версия понятна по интерфейсу и весит всего 70$. Если пообвыкнусь за  триальный период - и купить не жалко. Понятное дело, что SPARX например выглядит куда мощнее и даже (через пень правда но ..) держит привычный BPMN. Но и денег на Corporate-версию (а ниже - нет смысла, ибо если уж брать, то хотя бы с моделированием GUI) нужно будет уже у шефа просить, сам не потяну наверное. А триала всего 30 дней.

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

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


Если вы до сих пор использовали eEPC и BPMN, то вы, наверное, описывали в первую очередь бизнес-процессы? Тогда UML, может быть, разочарует. Он хоть и унифицированный, но в нём нет элементов, специфичных именно для бизнес-процессов. Ну, то есть, найти в нём при желании можно всё, но представление будет не таким удобным и наглядным, как при использовании специально "заточенных" на бизнес-процессы нотаций.

Если вы до сих пор использовали eEPC и BPMN, то вы, наверное, описывали в первую очередь бизнес-процессы? Тогда UML, может быть, разочарует. Он хоть и унифицированный, но в нём нет элементов, специфичных именно для бизнес-процессов. Ну, то есть, найти в нём при желании можно всё, но представление будет не таким удобным и наглядным, как при использовании специально "заточенных" на бизнес-процессы нотаций.

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

Для описания процессов и согласования их с пользователями - действительно в данный момент применяются EPC и BPMN (второй еще и для прогонов моделей, но это отдельная тема, и судя по всему, не особо местная). Они действительно имеют нужный набор привычных пользователям артефактов.
Хотя например Use Case - диаграммы я бы возможно попробовал применять (не зря же Вигерс с Кокберном прочитаны), да и насчет  Activiti - диаграмм можно подумать.

Но ...
У меня сейчас завал именно в документировании конечных спецификаций на ПО. Выложить безусловно не могу (под подпиской), однако, полагаю, Вам и не нужно на живых примерах объяснять что получается когда средствами Ворда (пусть и с любовно вылизанными и уже визуально привычными всем стилями) описывается внутри одного документа несколько таблиц, запросов, пользовательских интерфейсов, связей между ними, а затем идут еще и XSD-схемы для внешней интеграции ... Документ то остается и разработчики по нему пишут, но перечитывать и поддерживать такое становится .... минимум неудобно.

Попробуйте modelio

А еще у Visual Paradigm есть комьюнити эдишн

Есть такая книга Джозефа Шмуллера "Освой UML за 24-часа". Мне она нравится. Также могу порекомендовать курса Виктора Малышко http://sp.cs.msu.ru/ooap/

Galogen

Есть такая книга Джозефа Шмуллера "Освой UML за 24-часа". Мне она нравится. Также могу порекомендовать курса Виктора Малышко http://sp.cs.msu.ru/ooap/

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

С вопросами, я так понимаю, здесь не возбраняется появляться ? 2 ответа за день - реально хорошая статистика для специализированного форума, живущего с 20** какого-то года.


Благодарю за помощь.

С вопросами, я так понимаю, здесь не возбраняется появляться ?

Всегда готовы помочь, если сможем.

Ок.
Коллеги, я правильно (с ужасом) понимаю, что ни в одном моделлере нет возможности обозначить связь "поле к полю" ?

Допустим.
Есть 2 таблицы - шапки и строки заказов.
Есть интерфейс - тупая XSD на их базе (другие источники не берем). Имена полей XSD диктуются соглашением по EDI и в корень не соответствуют именам полей таблиц.

Обозначить что откуда берем (минимум 5 полей из шапки и 7 полей из строк) таки надо. Причем однозначных связей нет, на некоторых - дополнительные условия.
... не получается сделать мнемонически понятным.

Андрей, ну почему, я вам такое в любом векторном редакторе нарисую, хоть в Google Draw.

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

Если прям совсем хочется рекомендую поискать по словам Data Mapping Diagram.

Если я правильно понял, то можно имитировать такие связи через квази-внешние ключи в каком-нибудь дизайнере схем данных, начиная с MS Access.

Андрей, ну почему, я вам такое в любом векторном редакторе нарисую, хоть в Google Draw.

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

Если прям совсем хочется рекомендую поискать по словам Data Mapping Diagram.

Денис,
я повторю написанное выше.

Есть желание подредактировать проектную документацию в целях приведения её к единому стилю оформления.
То есть некий шаблон ФС на внедрении безусловно был, но именно шаблон, а не жесткое Соглашение. Поэтому сколько людей - столько и творческих личностей.  Диаграммы процессов одного уровня например - в чем угодно: BPMN, EPC, простая блочная, фотография флипчарта ...
Как следствие - читать, а уж тем более сопровождать эту документацию дальше - неудобно. Отнимает время.

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

Но есть процессы, завязанные на внешнюю интеграцию.
Пример:
Продажа товара.
Касса бьет чек
Покупатель предъявляет бонусную карту
Касса отправляет запрос в процессинговый центр
Процессинговый центр отвечает списанием и (или) накоплением бонусов
Покупатель оплачивает остаток
Касса закрывает чек.
Данные уходят на сервера - кассовый, ERP, BI.

Возврат товара
Подробностей не будет, также как и описания ряда сопутствующих процессов. Повторю, я серьезно отношусь к подписке о неразглашении, а там есть ряд любопытных выстраданных и вылизанных ноу-хау.
Да и не суть.
Суть в том, что нам нужно отсторнировать бонусные операции: начисленное - отнять, потраченное - вернуть.
Для этого существует некий набор ключевой информации.
2 сквозных процесса (возврат и продажа, подготовку данных не трогаем). Минимум 4 (на самом деле - больше) системы, часть которых находится во внешнем мире с внешними разработчиками.
А нам нужно гарантированно протащить ключи через все эти системы, причем часть этих ключей - должны быть во всех системах, часть - избыточны в других системах, а часть - просто не должны попадать никуда кроме обмена 1 к 1.

Повторю, карта связей - тяжелая. И желательно чтобы все разработчики всех систем могли посмотреть весь DataFlow, а не только свой интерфейс. Тогда и только тогда возникнет понимание. А когда программист понимает что он делает - качество измеримо повышается.

..
Этот процесс - не единичен. Есть еще несколько весьма развесистых клюкв.
Последовательность вордовских таблиц не спасает, так как вся связь остается только в 1 голове - голове автора, остальные ее теряют очень быстро, как показывает практика.
Ну в общем в данный момент это действительно решено через Схему Данных в Акцессе. Но неудобно это, хотелось получить возможность работы в одной среде.

Речь о подобном?
http://www.sparxsystems.com/enterprise_architect_user_guide/12.0/modeling_basics/connect_to_element_feature.html