1

Методологии / Re: Помогите выбрать модель .

« : 23 Мая 2012, 02:14:09 »

Если нужно изобразить один процесс, который использует разные модули, можно использовать диаграмму деятельности (activity) c  дорожками (swimlines) для каждого модуля.

2

Для всех / Re: Модель обработки информации

« : 22 Мая 2012, 23:04:25 »

Предполагаю что USeCase, тогда прецедент - работа (функция), а что есть внешний вход и внешний выход, что управление, а что механизм?

Судя по использованной терминологии, Вы пытаетесь найти в UML аналог функциональной диаграммы нотации IDEF0. Точного аналога нет, поскольку UML создавали с другой целью и на другой парадигме.
По большому счету, практически любая система обрабатывает информацию, и для моделирования можно использовать все диаграммы UML. Разные типы диаграмм дают взгляд на систему с разных сторон: статический/динамический аспект, структурный, поведенческий, взаимодействия, и пр. Чтобы определиться, какого типа диаграмму Вам использовать, нужно знать, что Вы моделируете и зачем. Вот статья, которая может помочь (англоязычная, не нашла ничего на русском) http://blog.architexa.com/2010/04/determining-which-uml-diagram-to-use/

Успехов.

3

Примеры / Re: Вопросы по use-case

« : 22 Мая 2012, 01:09:30 »

apheyhys, давайте поговорим про кладовщика. Вы создали UC "собрать заказ". Это хороший пример бизнес-операции. А как система будет в этом участвовать? Вероятно, кладовщик получит информацию о заказе через систему, пойдет ногами и укомплектует заказ руками, а потом поставит в системе галочку, что заказ собран. (Это я просто придумываю на ходу, а Вы можете описать этот процесс по-другому, Вам же больше известно о системе). Так вот "получить запрос на сбор заказа" и "поставить галочку" - операции с использованием системы и их надо отразить в UC диаграмме. Я бы не стала создавать для них два UC, а сделала бы один "Обработать новый заказ", в котором "получить запрос" будет пред-условие, а "поставить галочку" один из шагов. Очевидно, должен быть другой UC, который посылает эти запросы кладовщику на сбор заказов, чтобы пред-условие когда-нибудь выполнилось.

Альфия, интересно: в первом обзаце нВы не рекомендует использовать понятие оформить счет, правильно полагая, что это возможно не цель. Но далее советуете использовать оформить отгрузку, хотя с т.зр. бизнеса - отгрузить звучит лучше. Понятно, что вярд ли система используется, чтобы отгрузить , но выдать товар она тоже не поможет имхо, вот оформить продажу(покупку) звучит лучше, верно?
если это RR 2003(а судя по рисунку это так), то там только пакетом можно создать рамку

Эдуард, рада, что про "Оформить счет" Вы со мной согласны.
Вы рекомендуете заменить "оформить отгрузку" на "оформить продажу", если я правильно поняла? Наверно можно. Я только думаю, что отгрузка в данном случае есть только один шаг в процессе продажи. Продажа начинается оформлением заказа покупателем, затем идет проверка заказа менеджером, затем отправляется запрос кладовщику, который его собирает, и только потом происходит отгрузка, что означает окончание такой длинной транзакции одной продажи. Так что я стою на своем "Оформить отгрузку"

4

Для всех / Re: Вопрос про нтацию IDEF0 ///

« : 21 Мая 2012, 21:48:25 »

Я бы просто не стала обобщать слабо связанные функции в одну "предоставить услугу", а создала бы три отдельные функции. 

5

Примеры / Re: Вопросы по use-case

« : 21 Мая 2012, 21:41:22 »

По диаграмме:
1. Use-case диаграммы не используются для описания процессов. Для этого есть другие типы диаграмм - процессов (не UML) и действий (UML). Поэтому, попытка изобразить на use-case диаграмме некую последовательность действий - подход неправильный.
2. Для названия UC нужно использовать глаголы.
3. Название UC должно отражать цель операции для бизнеса. Оформить счет или накладную - не очень правильная цель с точки зрения бизнеса. Может лучше сказать "Выдать товар" или "Оплатить товар" и внутри этих операций будет шаг "оформить счет (или накладную)"?
4. Как отгрузка товара или доставка товара отражается в системе? Названия "отгрузить товар" и "доставить товар" звучат как операции вне системы. Название должно отражать то, что происходит внутри системы. Например, "отчитаться о доставке" или "оформить отгрузку".

Про рамку - зависит от вашего инструмента. Чем вы пользуетесь? Выглядит как Rational Rose. Рамка должна быть в панели инструментов.

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

Успехов.

6

Задачи студентов / Re: Курсовая - система защиты дома

« : 18 Мая 2012, 20:12:03 »

И 2 стрелки из одного состояния в другое - не понятны.

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

Успехов,
Аля.

7

Задачи студентов / Re: Курсовая - система защиты дома

« : 18 Мая 2012, 01:38:25 »

Чтобы построить диаграмму состояний, Вам надо написать, ну или просто продумать, разные сценарии действий с системой. Например, сначала хозяин находится дома и система отключена. Это хороший кандидат на начальное состояние “Отключено”. Что потом может произойти? Хозяин дома решил уйти и включил систему в режим охраны. (Вот Вам, кстати, и пользователь, который взаимодействует с системой.) Состояние можно назвать “Охрана”. Стрелка должна связать эти два состояния с описанием условия перехода “введен код установки на охрану”. В простом случае, хозяин возвращается домой и отключает сигнализацию. Значит нужна стрелка в обратную сторону, чтобы показать, что из состояния “охрана” система может вернуться в состояние “отключено”. Не забудьте указать условие перехода, например, “введен код для снятия с охраны”. Теперь рассмотрим другие сценарии. Например, ветром открылось окно. Система перейдет в состояние “Тревога”. Что дальше происходит? Приезжает охрана (еще один пользователь!) и переводит систему в состояние “отключено”? Продолжая рассуждать таким образом, вы и нарисуете всю диаграмму. А заодно найдете пользователей и их варианты использования.

Успехов,
Аля.

8

Идеи и мозговой штурм / Re: Соотношение теории и практики. Или как сдвинуть себя с места

« : 27 Апреля 2012, 01:28:15 »

Помнится, я свой первый use-case раз пять переписала, постоянно заглядывая в книгу Коберна... И все равно, что-то в нем казалось неправильным.
Могу Вам только пожелать найти хорошего наставника из числа коллег, когда начнете работать, чтобы избежать как можно больше ошибок в начале карьеры.

9

Примеры / Re: Проект на создание программы «Учет успеваемости студентов».

« : 27 Апреля 2012, 01:15:19 »

Какой прекрасный пример неправильной диаграммы ВИ в ответе #3! Дорогие студенты, хотите знать, что в ней неправильно? Этот форум как раз для такого типа обсуждений. Готовое решение для целого проекта в рамках форума предоставить сложно.

10

Задачи студентов / Re: UseCase diagram. Правильно ли?

« : 18 Апреля 2012, 01:01:47 »

Практикуется ли вообще, такой подход?

Практикуется, конечно. Если диаграмма содержит слишком много элементов, ее даже рекомендуется разбить на несколько. Это относится к любому типу диаграмм (класса, ВИ, бизнес-процессов). Вопрос, сколько элементов считается много и по какому принципу разбивать.
Я считаю, "много" для разного типа диаграмм означает разное. Например, для диаграммы ВИ, больше 15 ВИ я считаю уже много. Для классов - до 50 классов вполне читабельно.

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

Успехов.

11

Задачи студентов / Re: Класс и его атрибуты.Диаграмма классов

« : 16 Апреля 2012, 23:12:04 »

Согласна с Elf. Я это и пыталась сказать. Дмитрий, Вам надо выяснить, нужен ли для заказчика какой-то уникальный код (ID), который будет виден и использоваться пользователями системы. Например, этот код заказчика можно будет печатать на счетах фактурах рядом с названием заказчика. Наличие такого кода может облегчить поиск заказчика в системе. Если нет, то ID для этого класса указывать на диаграмме классов не нужно.

12

Задачи студентов / Re: UseCase diagram. Правильно ли?

« : 16 Апреля 2012, 23:01:21 »

Как вы думаете, правильным ли решением будет отдать данные прецеденты только одному актеру, например Время.
А для Админа тогда будут иные прецеденты?

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

Я бы вам предложила немного сместить ваш фокус в отношении видов требований, которые вы хотите отразить на этой диаграмме. Функции такого рода, как резервное копирование, относятся в поддержке функционирования системы, а не к предметной области бизнеса. Я их называю системными требованиями. Поэтому, я бы рекомендовала забыть про них на некоторое время и сконцентрироваться на функциях для поддержки бизнеса. После того, как вы определитесь с требованиями бизнес уровня и уровня пользователей, приступайте к требованиям системного уровня.

13

Задачи студентов / Re: UseCase diagram. Правильно ли?

« : 16 Апреля 2012, 03:07:46 »

1. На этой диаграмме подозрительно много ВИ. Эдуард Вам замечательно описал, как избавиться от лишних. Еще уберите вторичных актеров и диаграмма облегчится.

2.  Тот факт, что будет использоваться браузер или другие системы, не нужно показывать на диаграмме ВИ. Это не ее цель. Для этого можно использовать контекстную диаграмму, например. Только если внешняя система является первичным актером, ее нужно отразить на диаграмме. В вашем случае это может быть Консультант Гарант, если взаимодействие происходит независимо от пользователя. Но если обновление будет по расписанию, то тогда первичным актером будет Время и Консультант Гарант опять же можно не показывать.

3. "Составить расписание" и "Произвести резервное копирование" - независимые в контексте этой диаграммы ВИ. У них разные первичные актеры, Админ и Время, и между ними не нужно показывать связь совсем.

4. Ответ в п. 3.

Успехов.

14

Задачи студентов / Re: Класс и его атрибуты.Диаграмма классов

« : 16 Апреля 2012, 02:47:20 »

1. ID заказчика может быть нужен как некий код, который будет известен и заказчику и пользователям системы. Это не исключает необходимости в уникальном ключе для хранения данных о заказчиках в БД.
2. Адрес и телефон скорее всего будут отдельными классами (или классом?), просто потому что у заказчика может быть больше чем один адрес (офиса, доставки, склада, юридический и пр.), и уж конечно больше чем один телефон. А как же про адрес электронной почты? А другие способы связи, типа skype, не понадобятся? Можно все эти виды контактной информации обобщить в один класс с указанием типа связи.

15

Примеры / Re: Модель прецедентов использования - практический вопрос

« : 12 Апреля 2012, 00:38:55 »

Предлагаю такие ВИ: “Создать трансляцию”, “Изменить настройки трансляции”, “Удалить трансляцию”. Соответсвенно, актерами у всех трех ВИ будет Автор, а Модератор – актер только для двух последних ВИ. Зритель будет актером для ВИ “Посмотреть трансляцию”.

Другой способ. Можно создать ВИ более высокого уровня "Транслировать" и "Модерировать" для актеров Автор и Модератор соответственно. ВИ более низкого уровня  “Создать трансляцию”, “Изменить настройки трансляции”, “Удалить трансляцию” вызывать из них. Точнее, ВИ "Создать" будет вызываться только из ВИ "Транслировать".