1021

Варианты Использования (Use Case) / Re: Варианты использования CRUD

« : 22 Апреля 2013, 16:47:55 »

Весь use case «Обновить реестр читателей», внутри — «Обновить карточку читателя».

Понял согласен

1022

Варианты Использования (Use Case) / Re: Варианты использования CRUD

« : 22 Апреля 2013, 16:47:04 »

А применять в каком случае? Описать подробно  разработчику или  учесть для себя что есть действия?
Также важен вопрос о доступности всех операций всем. Или например, частично (редактировать может только тот-то).
Если много проверок, ограничений и сложные действия , то лучше CRUD описать по отдельности каждое действие пользователя.
И как сказано на  BeamTeam универсального решения нет.

В типовом случае типа работы со справочником: ввод, изменение и уадление данных по такой-то теме.

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

Поскольку у меня нет большой практике реальных проектов ведомых по use cases, а в учебных эту проблему решаем путем простой декомпозиции, то и есть непонятки использования

1023

Варианты Использования (Use Case) / Re: Варианты использования CRUD

« : 22 Апреля 2013, 16:40:04 »

"Обновить данные читателя" а добавление, удаление, чтение описать в альтернативных сценариях(если оно нужно).
Перерегистрация = "Обновить данные читателя"

Не совсем понял вашу мысль, уважаемый.

1024

Варианты Использования (Use Case) / Re: Варианты использования CRUD

« : 22 Апреля 2013, 16:39:04 »

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

Денис, а в каком месте обновить вместо изменить? в названии всего ВИ или и в его частях?

1025

UML SysML и пр. / Re: Помогите пожалуйста посторить диаграмму состояний

« : 22 Апреля 2013, 16:37:48 »

Попыталась по рекомендации Galogen задать автомат для объекта Заявка (см. вложение). Что то меня в нем смущает. В правильном ли направлении я двигаюсь?

И неслучайно.

У вас события и состояния перемешаны.

Пример: Принято от заявителя - это событие, а состояние в котором она будет висеть Ожидает регистрации, т.е.

Заявитель создает заявку и жмет кнопку SUBMIT типа я разместил свою заявку, генерирую событие Приянто от заявителя с переводом в состояние Ожидает регистарции.

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

Далее
Поступает из внешней системы сообщение с результатом обработки и заявка из В работе переходит в Исполнено - это кажется нормальным, но
почему из Исполнено по тому же самому событию (как оно вообще возникнет в этом случае) переход в Ожидает выдаче, а еще дальше по тому же событию + еще иному в Закрыта - это не понятно

1026

Варианты Использования (Use Case) / Re: Варианты использования CRUD

« : 22 Апреля 2013, 11:29:39 »

Хочу обновить эту тему.

Поскольку все равно до конца не укладывается как правильно и корректно применять подход к написанию CRUD ВИ, стоит ли связываться.
Есть паттерн, описанный в названной в данной теме книге  Gunnar Övergaard, Karin Palmkvist - "Use-Cases Patterns and Blueprints", глава 20. CRUD.

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

Имя:  Изменить записи о читателях
ID: 1
Краткое описание:  Вариант использования описывает операции с   
регистрационным       
списком
Действующие лица: Библиотекарь
Предусловие: -
Постусловие: Записи читателя изменятся в соответствие с выполненным
действием

Основной поток:

•   Система запрашивает требуемое действие
•   Библиотекарь выбирает действие, после чего выполняется один из подчиненных потоков (Добавить/Удалить/Изменить/Перерегистрация читателя)

ID: 1.1 Добавить читателя

•   Система запрашивает фамилию, имя и отчество читателя
•   Библиотекарь вводит запрашиваемые данные
•   Система создает новую запись о читателе в регистрационном списке
•   Система возвращает номер читательского билета зарегистрированного читателя

ID: 1.2 Удалить читателя

•   Система запрашивает номер читательского билета
•   Библиотекарь вводит номер
•   Система ищет читателя в регистрационном списке, после чего удаляет записи, ему соответствующие

ID: 1.3 Изменить данные читателя

•   Система запрашивает номер читательского билета
•   Библиотекарь вводит номер
•   Система ищет читателя в регистрационном списке, после чего запрашивает новые данные
•   Библиотекарь вводит новые данные о пользователе
•   Система сохраняет изменения

ID: 1.4 Перерегистрация читателя

•   Система запрашивает номер читательского билета
•   Библиотекарь вводит номер
•   Система ищет читателя в регистрационном списке, после чего обновляет его дату регистрации

Альтернативный поток событий

ID: 1.5 Читатель не найден
         Если обнаруживается, что введенный номер читательского билета не соответствует ни одному читателю, то система выдаст сообщение об ошибке и предложит ввести номер заново либо отменить действие. При отмене выполнение варианта использования завершается   

1027

Sparx / Re: Как унаследовать атрибуты от класса к его объекту?

« : 21 Апреля 2013, 01:05:10 »

Связь в итоге получается Dependency? Проводите ее и указываете этот стереотип вручную?

Да нет, связь там нарисована для красоты и смысла. И да проводится чисто вручную

Т.е. на одной диаграмме показан класс и инстанциорованный от него объект. Зависимость ничего не меняет в функциональности инструмента.

1028

Sparx / Re: Как унаследовать атрибуты от класса к его объекту?

« : 21 Апреля 2013, 01:03:45 »

Спасибо, по виду полная жесть, но буду пытаться )

Да ну- чего проще:) Никакой жести.
Берешь класс из проектного обозревателя и тащишь его на диаграмму (объектную) и там кидаешь как instance. Затем Advance -> Set Run State
Набьешь руку - будешь деньги брать

А если у родительского класса есть атрибуты, значениями которых являются объекты другого класса, то можно ли до них будет дотянуться из дочернего объекта?

Та разница то в чем? Все равно руками вбивать будешь.

Пример: человек живет в городе, есть куча людей и куча городов, у класса Человек заводим атрибут Город и связываем его с классом Город. Соотв-но, надо чтобы каждый конкретный человек был связан с конкретным городом. Как это можно реализовать?

Не у класса Человек будет атрибут Город типа Город, связывать будешь класс Человек и класс Город, а не атрибут - связь - это и есть атрибут

Счас нарисую

Не забывай между классами - ассоциация
между объектами - связь - она не кратна

И то что ты делаешь - это иллюстрация ДК, т.е. диаграмма объектов

1029

Sparx / Re: Как унаследовать атрибуты от класса к его объекту?

« : 20 Апреля 2013, 23:52:34 »

Марина все проще и сложнее.

1. http://www.uml2.ru/forum/index.php?topic=312.msg30830#msg30830
2. Не надо включать отображение унаследованных атрибутов и так отобразяться

1030

UML SysML и пр. / Re: (UML2 Activicy diagram) Есть ли в это диаграмме аналог "OR" как на IDEF3?

« : 20 Апреля 2013, 20:31:57 »

Вот как описывают подсистему расчет зарплаты в сомой 1С. Хотел эту схему представить в UML2

И?

1031

UML SysML и пр. / Re: Помогите пожалуйста посторить диаграмму состояний

« : 19 Апреля 2013, 13:30:16 »

А как было бы всем проще, если бы, невыёживаясь, сначала построили таблицу переходов по состояниям: )

Так я девушке это предлагал. Но ...

1032

UML SysML и пр. / Re: Помогите пожалуйста посторить диаграмму состояний

« : 18 Апреля 2013, 23:16:18 »

Результатом заявки может быть талон, приказ, мотивированный отказ поэтому он рассматривается как отдельный объект, а не как отдельный атрибут заявки. При этом жизненный цикл заявки (набор его состояний) будет зависеть от того, какое состояние имеет результат обработки.

Все это РАЗНЫЕ объекты. КАк состояние талона (и какие они могут быть?) влияет на состояние заявки?

Как это отражается на диаграмме состояний?

это и есть само состояние - фиксированный набор значений атрибутов и связей объекта

Говорит ли это о том, что в этом случае для объекта Заявка должны быть разработаны две диаграммы состояний? Одна для статусов Черновик... Зарегистрирована... и вторая со статусами Просрочена, Не просрочена?

Это зависит от целей моделирования и специфицирования. Но я не вижу оснований для противопоставления одной группы состояний другой.

Для того, чтобы отразить начальное состояние для отсчета срока обработки заявки. Т.е. есть правило, что заявка должна быть обработана в течение 10 дней. Отсчет срока начинается после того, как она будет зарегистрирована. Здесь я ввожу подсостояние "Не просрочена". Если это не верно, то прошу подсказать как надо?

Момент регистрации заявки  и есть момент начала срока ее исполнения. КАк только возникает таймаут - 10 дней, зарегистрированная заявка, но не исполненная попадает в положение просрочена

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

Ну и что.
смотрите Запланирована - (бла бла) - Выполняется -- прошло 10 дней) - Просрочена (слать нотификацию пока ...) - Выполнена
Или Запланирована - (прошло 10 дней) -  Просрочена (слать нотификацию пока ...) - Выполнена
или Запланирована - (прошло 10 дней) -  Просрочена (слать нотификацию пока ...) - Отменена
чем плохо?

1033

UML SysML и пр. / Re: Помогите пожалуйста посторить диаграмму состояний

« : 17 Апреля 2013, 22:12:20 »

1. Показать как изменяется состояние "Заявки" в зависимости от изменения состояния "Результата обработки заявки" 

А почему результат обработки заявки рассматривается как отдельный объект?

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

Состояние - это набор значений и связей объекта (набор значений атрибутов иными словами). Пусть у вашей заявки есть атрибут Статус = каким то статусам, и вдруг есть еще флаг = логический. Ясно, что сочетание этих значений и определяет отдельное состояние.

Но заявку можно рассматривать по-разному.
Скажем если для заявки важны
Не просрочена
и Просрочена - то мы имеем два состояния. Нахождение в 1 начинается при создании заявки и прохождению по ее ЖЦ, пока не возникнет событие времени after(установленный срок). При наступлении этого событие каждая заявка из состояния Не просрочена перейдет в Просрочена с каким то важным результатом

Правда не понятно зачем нужно состояние Не просрочена, достаточно иметь состояние Просрочена.
Однако вопрос - а что у вас происходит с просроченной заявкой? Она продолжает выполняться?

1034

Обучение / Re: Требуются задачи на моделирование конечных автоматов или диаграмм состояний

« : 17 Апреля 2013, 13:22:17 »

Мне кажется, это больше походит на диаграмму деятельности.
Кроме того  тут явные ошибки, что еще за зависимости в диаграмме автоматов?
Состояние какого объекта модулируются?

Как-то не очень понятно Статусы заявки и результатов. Имхо
Отдельно Заявка
Отдельно Результат

Также есть и другие синтаксические ошибки, на переходах, что указано?

Т.е. я бы разделил эти две диаграммы автоматов.
Тщательно продумал состояния и события переходов из одного состояния в другое

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

Ну и матчасть http://uml3.ru/library/uml_for_developers/05.Behaviour_modeling.pdf

1035

UML SysML и пр. / Re: (UML2 Activicy diagram) Есть ли в это диаграмме аналог "OR" как на IDEF3?

« : 07 Апреля 2013, 19:55:25 »

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

Немного стало яснее. Мне кажется, использование распараллеливания здесь не допустимо. Мне кажется и использование асинхронного OR в IDEF3 не будет правильным. По сути тут идут два процесса: начисление и удержание. Они могут быть выполнены различными документами, что вы представляете как 7 разных действий или деятельностей, а действительно ли они разные эти действия?

Вот в BPMN есть такой ad hoc процесс, мне кажется, это отражает вашу особенность наилучшим образом, но как простым способ изобразить в ДД - не знаю.

Скажите, пожалуйста, каким образом возникает потребность использования одного из 7 документов или нескольких для определения назначений и удержаний?