2506

Для всех / Re: Ищу материал для курсовой.

« : 27 Апреля 2010, 23:14:43 »

Не, на ВОДКУ точно не дадим.

Реально материла много, совет погуглить наверное многих достает, но это действительно отличное средство.

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

2507

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

« : 27 Апреля 2010, 13:25:15 »

Zicom Mentor Actor-а определяет так:
Эктор (actor) - это множество логически связанных ролей, исполняемых при взаимодействии с прецедентами или сущностями (система, подсистема или класс). Эктором может быть человек или другая система, подсистема или класс, которые представляют нечто вне сущности.

Но эктор - это все-таки одна роль, у Вас же их несколько Менеджер Кассир Кладовщик - какова логика объединения их и каково название этого эктора

2508

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

« : 27 Апреля 2010, 13:22:11 »

1. Менеджер вводит КП
2. Система регистрирует КП в журнале КП
3. Менеджер печатает КП
4. Система формирует печатную форму ххх
5. Кассир отражает прием предоплаты
6. Кладовщик регистрирует отгрузку товаров со склада
7. Система уменьшает количество  товаров на складе, снимает резервы по КП (глупость конечно по КП товар резервировать, но для упрощения считаем что резервы именно КП образованы)
8. Кладовщик печатет ТОРГ 12
9. Система формирует на основании данных документа печатную форму ххх
10. Кассир принимает осташиеся денежные средства от клиента.

Цель достигнута - все хозяйственные операции по продаже товаров зафиксированы.

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

Менеджер, Кассир, Кладовщик , Система - это исполнители процесса продажи, они внутри некой общей системы - назовем ее склад оптовой продажи

2509

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

« : 27 Апреля 2010, 09:01:06 »

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

Сергей, мне вовсе не хочется вести с Вами спарринг. Я вовсе не хочу навязать Вам свою точку зрения. Вы обратились на форум с вопросом в чем собственно суть use case. На мой взгляд, возможно кто-то меня тоже поддержит, Вы не правильно понимаете суть вариантов использования.

Вы пытаетесь сказать, что любой процесс (в частности бизнес-процесс) можно выразить через вариант использования. На самом деле это далеко не так.

Группа пользователей <> внешняя система. А приведенный Вами пример вовсе не подтверждает Вашу логику.

Вариант использования - это сборник сценариев, главным образом описанных текстом, может быть отражен в виде диаграмм видов деятельности и диаграмм последовательности.

Потому я Вам просто предлагаю записать Ваш ВИ Продажа товара с предоплатой. Причем запишите основной поток событий.

2510

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

« : 26 Апреля 2010, 21:46:22 »

Эдуард, смею возразить, что "Подготовить коммерческое предложение", "Принять предоплату", "Оформить отгрузку товара" - это набор функций, который в случае высокоуровневых средств разработки, как 1С: Предприятие 8, описывать смысла нет. Например "Подготовить коммерческое предложение" по сути 2 функции "Ввод информации о предложении в БД", "Печать предложения" (ну или отправка по почте и т.д.). Ввод и печать платформа 1С предоставляет практически "по-умолчанию" - зачем описывать то, что не может быть изменено? Упомянуть о потребности в возможности выполнения системой таких действий нужно - для этого как раз ВИ я и использую.

ну это как Вам нравится, Сергей. Только тогда не называйте это вариантом использования системы. Раз Вы интересуетесь сутью, то суть в том, что ВИ  есть цель пользователя, но не совокупности пользователей.

Продать товар с предоплатой - чья в данном случае цель? Менеджера ? Кассира? Кладовщика?

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

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

Это тянет на бизнес-вариант использования, но в этом случае все действующие лица, которые у Вас обозначены - это business workers - т.е. исполнители процесса, сидят внутри процесса, но не снаружи. А весь БВИ описан как прозрачный ящик, в то время как СВИ пишется как черный ящик: действия пользователя и реплика системы.

Потому возможно не следует называть это ВИ.

2511

Обсуждение статей / Re: Конференция DevConf 2010, Мск, 17 мая

« : 26 Апреля 2010, 15:40:20 »

Которая была на ТЛ 2010, только переработанная.

Ты советы принимаешь?

2512

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

« : 26 Апреля 2010, 15:36:01 »

Про что такое use case на форуме не мало было тем - поищите - use case, вариант использования.
К тому же книг не мало.

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

Исходя из описания процесса я вижу как минимум трех пользователей - участников процесса: кассир, кладовщик и менеджер.

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

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

Кассир как мы видим может Принять предоплату. Принять доплату

Кладовщик Оформить отгрузку товара (результатом которой будет документ ТОРГ-12, и некоторые изменения в БД)

2513

Консалтинг и Внедрение / Re: Выбор системы электронного документооборота

« : 26 Апреля 2010, 12:44:40 »

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

Есть типа требование минобра на наличие подобных средств автоматизации.
На самом деле я не считаю, что вузу 100% нужна подобная программа, можно все решить и более простыми средствами: excel, почта, wiki и т.п.

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

Посмотрел в интернете - выбор бесплатных очень ограничен, может посетители форума что-то подскажут?

2514

Обсуждение статей / Re: Конференция DevConf 2010, Мск, 17 мая

« : 26 Апреля 2010, 12:35:09 »

Особенной изюминкой данной конференции будут Мастер Классы, на одном из которых выступлю я.

Саша, ты просто герой. Столько выступлений! Какова тема выступления?

2515

Задачи студентов / Re: Помогите чайнику нарисовать UML диаграмму

« : 25 Апреля 2010, 14:09:50 »

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

Возьмите инструмент и осуществите обратное проектирования вашего кода. Вот и будет диаграмма классов

2516

Задачи студентов / Re: нужен совет , как собрать Схему для БД по страхованию

« : 25 Апреля 2010, 14:07:50 »

Какой подход используется? Семантическое моделирование или нормализация отношений?

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

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

Поскольку у вас отношений не так много, имеет смысл составить табличку с утвержедниями типа:
Полис участвует в 1 или более страховом случае
Каждый страховой случай связан с только с одним полисом

Потом проанализируйте эти утверждения - корректны ли они.

Неплохо бы составить ряд вопросов на которые ваша БД должна отвечать и попробовать составить запросы на получение этих ответов

2517

Конференции Семинары и Тренинги / Re: Встреча Сообщества после Training Labs 2010

« : 23 Апреля 2010, 13:29:38 »

Я не против, просто будет ли кому интересен мой доклад

2518

Управление Проектом / Re: Управление изменениями в рамках проекта

« : 22 Апреля 2010, 20:17:36 »

хотелось бы услышать методы как определить аналитику время, которое он будет затрачивать в процессе реализации ТЗ?

А при чем тут аналитик? ТЗ реализует разработчик - проектировщик и/или программист

2519

UML SysML и пр. / Re: usecases. ассоциация актера с актером

« : 22 Апреля 2010, 15:53:24 »

Power Designer не дает так нарисовать, например.

+ Power Designer'у
 

Эдуард, поясни плиз, насчет классификатора, не понятно.

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

Может просто в Парадигме можно рисовать все что угодно, но потом положено нажать кнопочку типа Check Model, которая покажет все ошибки?

К сожалению не нашел. В ЕА есть такая кнопка, хотя многие утверждают, что работает она так себе.
В VP есть кажется для BPMN, но вот в UML не нашел

2520

UML SysML и пр. / Re: usecases. ассоциация актера с актером

« : 22 Апреля 2010, 08:28:27 »

C Visual Paradigm не имел дела. Возможно, авторы Visual Paradigm имеют в голове какое-то расширение семантики ДВИ, если допускают рисование таких ассоциаций. А что написано в парадигмовской документации про такую ассоциацию, какой смысл они в эту черточку вкладывают?

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

Конечно можно (или нужно) включить некую проверку валидности связей на диаграмме, исходя из контекста такой диаграммы. Частично это есть. Еще один минус в непользу современных вендоров UML tools