181

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 14 Апреля 2011, 14:46:26 »

В дополнении к обсуждению. что вы думаете об этой диаграмме. Поясняет ли она действие 1 диаграммы UC и устраняет потребность во второй?

Вполне!

Примечание: Касается только UML2.
В узел (кроме Merge и Join) не может входить больше одного потока управления. Большинство инструментов это не контролируют. Но правилами это интерпретируется как последовательность двух элементов: Join и сам элемент, например, Action. Т.е. в данной ситуации управление никогда не будет передано из действия (и конец никогда не наступит!).
В данном случае (в UML2) стрелки от Начала и от Решения должны входить в Merge, а затем в первое действие.
То же относится к Финалу.

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

182

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 14 Апреля 2011, 14:19:12 »

Может быть, это старческий маразм, и я разучился ясно излагать свои мысли!

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

Наглядный пример - Use Case по UML и по Коберну. Это близкие, но разные понятия. В UML - это всегда "черный ящик", у Коберна - это может быть и "черный", и "прозрачный" ящик. В ядре UML есть только один уровень (взаимодействие пользователя с компьютерной системой), у Коберна их пять. В определении UML - это класс (набор экземпляров), у Коберна - это "соглашение о ...." (долго перепечатывать!).

Авторы во втором контексте - это авторы UML и понятия Use Case в смысле UML (Буч, Рамбо и Джекобсон, "три друга"). Они же - "инициаторы" создания RUP. В принципе, RUP можно рассматривать как описание технологии использования UML (сам язык, естественно, технологии иметь не может). Рекомендации RUP можно рассматривать как дополнительный материал, отражающий точку зрения авторов UML.
Можно и не использовать, воля ваша! Но это будет ваша концепция, ваш термин. Это язык! Кто-то Вас не поймет!

А теперь представьте себе автомат на вокзале, единственной функцией которого является возврат денег! Вы не согласны с рекомендацией RUP о существенности и планировании пошаговой поставки? Тогда другой пример, более строгий:

Представьте себе полноценный автомат, к нему подходит человек с целью возвратить свои деньги. Если автомат функционирует правильно, то он не отдаст чужие деньги. Т.о., полный процесс должен включать и засовывание монеток в монетоприемник! А это у вас отдельный Use Case?

Но Возврат денег вполне может рассматриваться как абстрактный Use Case, расширяющий основной UseCase при некоторых условиях (уровень рыбы у Коберна).

Еще раз прошу извинить за "мутный" язык. Простым языком говорить разучился. Жена меня называет "прикладной теоретик".

183

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 14 Апреля 2011, 12:38:45 »

Относительно степени детализации.

RUP (и "три амигос") рекомендует сначала определять субъектов, а уже потом - use cases.
Если Вы определили и согласовали субъектов, то дальше для определения степени детализации можно спокойно использовать определение. Никаких если уже не будет!

Ну и еще одна идея из RUP, которую я часто использую, если есть несколько уровней моделирования, например, "предприятие", "бизнес", "системы".

Каждый следующий уровень детализирует (и реализует) предыдущий:

- возможности предприятия (capability) -> функциональные области бизнеса -> системы
- операционные задачи -> BUC (бизнес-процессы) -> функциональные области систем
                                     действия диаграммы деятельности -> системные UC
                                                                                          действия диаграммы деятельности -> абстрактные UC (если существенные!)

Не надо на меня ругаться. Это схема размышлений, а не обязательное правило!!!
Но полезно!

184

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 14 Апреля 2011, 12:13:59 »

А вставление карты в картопринмник банкомата - это Use Case? Система выполняет обработку. И кому-то это надо!
А заполнение поля идентификатора пользователя в форме ввода - это Use Case? Система выполняет обработку. И кому-то это надо!

Абсурд!

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

Те, кто знаком с RUP (в разработке начальных версий которого участвовали те же авторы) знают, что Use Case - это элемент планирования результатов итераций, каждая из которых, по RUP, предусматривает выпуск системы (внутренней или внешней версии). Один из признаков прецедента, в таком случае: при пошаговой поставке можно выпустить продукт, выполняющий единственный Use Case!

Ну, и нужно различать Use Case от UML и от Коберна. У них разные определения. Но, с некоторыми натяжками, сопоставлять уровни UML и Коберна можно.
Я себе представляю примерно так:

   UML                        Коберн
 Capability UPIA         Облако
 BUC                        Змей
 Основной UC           Море
 Абстрактный UC       Рыба
 нет (Операция?)      РакИ не надо забывать, что эти уровни имеют своих субъектов:
- если первая диаграмма - бизнес, то субъект - клиент бизнеса, а не пользователь системы! Кто нибудь слышал, чтобы целью бизнеса было приобретение билета? Если только для перепродажи (раньше это называлось "спекуляция", теперь - "посредничество").

185

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

« : 14 Апреля 2011, 00:31:59 »

Я человек простой. Автор дал определение. Это аксиома. Спорить с этим определением не смысла. Придумай свой термин и дай ему определение и используй, как хочешь!

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

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

Что касается помещения на первую диаграмму абстрактных (не имеющих своих экземпляров) прецедентов включения из второй диаграммы, то я не знаю, Эдуард, что тебя возмутило?! Обычная практика выделения существенных общих частей, которые много где используются.

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

186

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

« : 13 Апреля 2011, 19:48:45 »

Use cases во второй диаграмме не подпадают под определение (пользователь хочет купить билет, а не копейка свои отдать!).

Если хочется подробнее, и процессы (и последующие решения по ним) из второй диаграммы предполагается иметь как авуары многоразового использования, их можно поместить на первую диаграмму с отношениями <<include>> от основного.

187

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

« : 13 Апреля 2011, 18:13:54 »

Это для какой категории читателей тест?

188

Управление Проектом / Re: Особенности работы с госзаказчиками

« : 21 Марта 2011, 14:52:23 »

Увы! Вы не одиноки!

189

Примеры / Re: Диаграма класов: обработка изображения

« : 21 Марта 2011, 10:06:27 »

На Ваших диаграммах представлен некий процесс, последовательность.

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

А вообще, уже началось перекачивание из пустого в порожнее. Пора кончать эту бодягу.
Если только для улучшения своей статистики!?

190

Примеры / Re: Диаграма класов: обработка изображения

« : 13 Марта 2011, 21:58:07 »

Легче нарисовать правильные диаграммы на UML и при рассказе объяснить, что есть что, чем придумывать новый язык, которого ты и сам не знаешь.

Будешь рисовать на UML, тебе здесь помогут.

191

Примеры / Re: Диаграма класов: обработка изображения

« : 13 Марта 2011, 20:03:21 »

Вот етого не понял! Обявлени отдельние класи в которих есть атрибути и операции что странного?

В этом странного, как раз, ничего нет. Странно, как оно работает?
Никто ничего не инициирует. Ничего классу не передает, не запрашивает.

Тут одно: или это диаграмма классов, тогда все неправильно.
Или это не диаграмма классов, тогда неплохо было бы понять, что обозначают те или другие "значки".
Например, те, что обозначены как зависимости. Они что делают (или не делают)?

Если Вы знаете UML, так нарисуйте на UML. Можно будет поговорить.

Я настоящего украинского, конечно, не знаю. Но смысл написанного здесь понимаю. Да и не украинский это. Я 9 лет в Украине прожил, даже гражанином был.

192

Примеры / Re: Диаграма класов: обработка изображения

« : 13 Марта 2011, 18:42:30 »

Извините, я не совсем понял, что вы хотите представить этой диаграммой классов?

Если динамику поведения: выполняется первый класс, потом, по условию, второй и т.д., то диаграмма классов для этого просто не предназначена!

Наверное, для этого нужно использовать диаграмму последовательности?

И вообще, какая-то странная ситуация! У класса, судя по картинке, есть атрибуты и операции. Как этот класс выполняется? Сам с собой взаимодействует?

И картинки очень слепые: ничего не разобрать.

Думаю, Вам надо почитать что-нибудь про UML, посмотреть примеры.

193

Идеи и мозговой штурм / Re: Я - заказчик, но мне нужно написать ТЗ на создание БД...

« : 09 Марта 2011, 22:38:32 »

Думаю, я не имею на этот лозунг авторских прав. Я его где-то услышал.
С Богом!

194

ПО Аналитика / Re: Как отобразить в Rational Software Modeler ....

« : 09 Марта 2011, 12:06:57 »

В проекте профиля при создании стереотипа Вы должны указать, к каким элементам этот стереотип можно применять. Сделали? Проверьте, пожалуйста, что тип элемента указан правильно.
Если профиль к модели Вы применили, то других "фокусов" я не вижу.

Если будет совсем туго, присылайте Вашу рабочую область. Разберусь на месте.

195

Работа / Re: 2,5 года

« : 03 Марта 2011, 22:58:25 »

Ну да - виноват госзаказчик
Они плохие, мы хорошие.

Вот именно!
Нужно иметь соответствующую квалификацию. В том числе - работы с заказчиками. Не "ложиться" под них, а управлять. В TOGAF это называется "управление заказчиками". Смею вас заверить: это реально (при условии, что закзчику нужен продукт, а не ... (увы!). А в последнем случае выход один: делиться! Но это не в компетенции системного аналитика!