361

Примеры / Re: Нет ни малейшего понимания.

« : 11 Октября 2016, 00:13:47 »

Такой вопрос: какие диаграммы сочетаются с user stories?

Я не совсем верно выразился, хотел сказать, что user stories не следует путать с use cases, которые являются частью uml и соответственно остальные диаграммы выстроены вокруг use case view.

Если же user stories рассматривать как описание требований, то дальнейшая их проработка может быть выполнена многими диаграммами как в uml, так и в других языках и нотациях.

Не совсем ясная ориентированность на Uml. Ну и в любом случае, если Вы планируете  его как-то использовать, следует познакомиться с его синтаксисом, семантикой и прагматикой использования.

Поищите в сети книгу Скотта Амблера Гибкое моделирование. Возможно натолкнет Вас на какие-то идеи.

362

Примеры / Re: Нет ни малейшего понимания.

« : 09 Октября 2016, 23:46:24 »

Как раз от PM исходит желание перейти на использование uml. На данный момент есть куча тикетов с неописанными требованиями. Мне предстоит создать варианты user stories.   
Пошел изучать Вигерса.

Все-таки стоит понимать, что user stories и uml мало сочетаются.  И реально узнайте, что хотят получить  от вас программисты.

363

Примеры / Re: Курсовой проект - Книжный магазин

« : 08 Октября 2016, 20:58:44 »

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

Согласен. Ошибки присутствуют. Но коли уж обратили на них внимание, может быть представите вариант лишенный недостатков? Ну помните, картинка лучше 1024 слов

364

Примеры / Re: Нет ни малейшего понимания.

« : 08 Октября 2016, 20:54:53 »

Добрый вечер.

Описание задачи какое-то сумбурное. Реально ваша команда работает по scrum?

Для справки. Если вы хотите использовать uml, то сначала просто ознакомьтесь что это такое, возможностей море. Можно просто начать с youtube. Можете посмотреть эту книгу http://book.uml3.ru. Можете посмотреть эту библиотеку знаний http://uml-diagrams.org,

Функциональные требования выражаются use cases. Требования к структуре данных обычно выражаются в виде диаграммы классов, используя классы предметной области. Приведенная задача предполагает построение диаграммы классов (или диаграммы объектов).
Для начала нужно понять какие понятия (сущности) фигурируют в предметной области. Судя по задаче есть Услуга, есть Клиент.

Клиент получает 1 или несколько Услуг в ходе Посещения (эта сущность придумана мною, у вас может быть что-то боле точное).
Одна и та же Услуга может оказываться разным Клиентам.

Из этого простого примера можно сделать примерно такое заключение: Клиент (1) - (1 - *) Посещение (0 -*) - (1) Услуга
Услуга может описываться через атрибуты:
Вид услуги
Наименование услуги
Стоимость единицы услуги

Клиент (ФИО, адрес - если вообще нужно)

Посещение
Дата
Время
Кто оказывал услугу
Общая стоимость

Все сущность и атрибуты должны быть аккуратно прописаны в модели или словаре данных с указанием типа данных, диапазона значений, правил и ограничений

365

Примеры / Re: Помогите разобраться в терминах

« : 07 Октября 2016, 11:55:47 »

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

При этом в uml существуют стереотипы для пакетов система и подсистема. Компонент  символизирует некоторую четко очерченную часть системы с определенной функциональностью и интерфейсом. Поскольку часто компонент = черный ящик. важно понимать его назначение и видеть внешне проявляемые свойства: сервисы и функции.

366

Sparx / Re: FAQ - Sparx Enterprise Architect

« : 30 Сентября 2016, 15:06:49 »

Всем доброго дня ..
столкнулся с проблемой в написании сценариев а именно
1. Пишу шаги сценария 1...2....3....4
2. Для шага 3 делаю Alternate и пишу туда наименование альтернативы и уже в самой альтернативе описание

проходит некоторое время и мне нужно убрать альтернативу как таковую...

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

Как боротся с таким? как удалить альтернативу???

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

367

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 29 Сентября 2016, 11:22:39 »

"Rational Edge" 11.2002

Спасибо, но разве это метод H. E. Eriksson'а and M. Penker'а У них нотация обозначения вроде бы совершенно иная?

368

Примеры / Re: Deployment Diagram. Первый блин. Просьба покритиковать.

« : 28 Сентября 2016, 21:32:51 »

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

Т.е. если используется модуль то отображается его реализации (exe файл, библиотека, dll и т.п.), а между артефактом и компонентом отношение манифестации (http://www.uml-diagrams.org/deployment-diagrams.html#manifestation, http://book.uml3.ru/sec_1_5#p8)

Ну, а с точки зрения понятности - ну почти все понятно, кроме документа и справочника (но возможно мне только не совсем понятно)

369

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 28 Сентября 2016, 15:52:49 »

Нотация не виновата. Метод H. E. Eriksson'а and M. Penker'а позволяет использовать нотацию и [конкретно] диаграмму вариантов использования для бизнес-моделирования.

А не могли бы привести примеры или указать на ссылку?

370

Бизнес-анализ и Целеполагание / Re: Как перейти из основн сценария об общих полях к сценарию о заполнении уникальных

« : 27 Сентября 2016, 21:10:43 »

Не очень понятно зачем Вы это делаете, пытаясь описать как используется система сейчас с помощью юзкейса. В лучшем случае это некий конкретный сценарий использования системы = инструкция по заполнению. В этом ситуации тривиальные и банальные реакции системы отражать не стоит. Почему бы Вам в таком стиле не писать: Пользователь вводит первый символ наименования автомобиля - Система отображает введенный символ в указанном поле; Пользователь вводи второй символ наименования автомобиля - Система отображает введенный символ в указанном поле; И в чем тут преимущество или польза?

Точно также и с заполнением всего остального. Это не вариант использования. Это просто инструкция по заполнению формы. Мне не понятна задача.

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

Опять же вы можете посмотреть на примеры 2 и 3 в ранее предлагаемой небольшой заметке.

371

Бизнес-анализ и Целеполагание / Re: use case как описать что процесс может при необходимости повторяться

« : 27 Сентября 2016, 15:42:50 »

Посмотрите, пожалуйста, небольшую заметку http://www.uml2.ru/faq/faq-uc/73/. Пример 3. Это Вам поможет?

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

372

Проектирование / Re: Моделирование отношений между таблицами БД

« : 17 Сентября 2016, 19:38:57 »

Модель неполная, приведена для примера.
Благодарю за помощь!

Ясно. Рад был помочь.

373

Проектирование / Re: Моделирование отношений между таблицами БД

« : 16 Сентября 2016, 23:38:21 »

Galogen, спасибо.
1. Что на Ваш взгляд требует изменения?
2. Буду признателен за ссылку. Не нашёл этих обозначений.

Попробуйте скачать Erwin - там есть community edition и есть способ отображения этих процедур. В целом они стандартные:
I:R - insert restrict
D:R - delete restrict
U:R update restrict
если R заменить на C- это будет каскадная процедура - то что нужно для первого вашего требования
Там есть и другие правила
Set null
set default

а так вообще 6 правил рассматриваются
3 со стороны родителя (вставка, обновление и удаление)
3 со стороны дочерней сущности

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

374

Проектирование / Re: Моделирование отношений между таблицами БД

« : 16 Сентября 2016, 17:50:46 »

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

375

Обучение / Re: Кто есть кто на русскоязычном рынке обучения ИТ-аналитиков

« : 02 Сентября 2016, 16:01:47 »

Почему я везде пишу "работа"? Ну так кроме как там, я себя ИТ-аналитиком и не называю. Да и там редко. Чуждое это словосочетание для отечественного уха.

А чем, разрешите поинтересоваться, Вы себя называете, видите?