1651

Варианты Использования (Use Case) / Re: Несколько частных вопросов по ВИ

« : 16 Августа 2011, 23:50:54 »

3. Наконец, я документирую ВИ используя блок-схемы, а не текстовое описание (при этом я стараюсь следовать стандартам текстовых описаний). Возможен ли такой подход? +/- такого решения, на ваш взгляд?

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

Я не знаток RUP, т.е. не такой глубокий знаток. И, наверняка, ошибаюсь. Но мне не совсем нравится делать описание варианта использования с помощью диаграмм деятельности.
1. это сложнее (Вы же сами обратились, а подумайте что делать, если последовательность некоторых шагов не важна? Как это изобразить?)
2. это менее понятно окружающим
3. это требует от окружающих тонкого владения концепций UML и диаграммы деятельности в частности
4. это невольно заставляет усложнять описание вариантов использования и затруднять их понимание
5. я не понимаю модели (или механизма) трансформации диаграммы деятельности (правда и текстового описания) в реализацию варианта использования
---Потому все это личный выбор, дело личного опыта и собственной практики, способ, который по душе Вам и которому Вы сумели обучить окружающих (с учетом пунктов 1-4)

PS Знакомство с UML я начал с книги Джозефа Шмуллера (в 2001 году, если не ошибаюсь) в ней предлагался такой подход.
1. вы берете интервью и изображаете основной бизнес-процесс (важную деятельность) с помощью ДД
2. в ходе ее изображения у вас может появится потребность какую-то часть деятельностей свернуть - получите некий параллельный БП
3. обязательно виды деятельностей нужно раскидать по персоналиям - это также позволяит выделить какие-то параллельные БП или деятельности
4. Среди этих видов деятельностей какие-то и будут целью автоматизации
5. они сами по себе или после декомпозиции их на части станут вариантами использования
6. описание ВИ было словесным, но кратким и далее сразу предлагалось переходит к реализации ВИ (аналитической сначала)

1652

Системный Анализ и Требования / Re: Логично ли так формировать ТЗ?

« : 16 Августа 2011, 21:16:29 »

Коллеги,

ВИ - это взаимодействие НАШЕЙ СИСТЕМЫ с внешними объектами (пользователями, др. системами, часами в конце концов), если же мы начинаем описывать в виде ВИ требования по взаимодействию между подсистемами НАШЕЙ СИСТЕМЫ, то теряем нужный/одинаковый уровень абстракции, т.к. будут ВИ по взаимодействию подсистемы с пользователем (один уровень абстракции) и будут ВИ по взаимодействию м\у подсистемами (другой уровень абстракции). Ни к чему хорошему это не приведет.
Исключения - это ВИ включения, необходимые для обобщения потока событий.

1. кто сказал, что ... "ВИ - это взаимодействие НАШЕЙ СИСТЕМЫ с внешними объектами"? Это написано в спецификации?
2. все-таки нужно различать элементарные части системы и подсистемы
3. а зачем нам нужен одинаковый уровень абстракции? Может он нужен только будучи на определенном уровне? Если я на уровне всей системы, я имею один boundary. Но если я буду находится на уровне подсистемы, то эти другие подсистемы для меня такие же внешние сущности. Более того, эти внешние сущности-подсистемы помогают мне понять какие интерфейсы мне следует спроектировать.
4. возможно это не следует делать для простых системы, но Павел рассматривает АСУ, так что не вижу криминала, более того вполне законно и обосновано

1653

Варианты Использования (Use Case) / Re: Несколько частных вопросов по ВИ

« : 16 Августа 2011, 21:08:35 »

Ага) что-то похожее на Коберна, но чуть симпатичнее.
P.s имел ввиду отмену всего, что было сделано в рабочем потоке UC

Но и у Коберна, и в представленном примере, так и есть. 
Если ВИ рассматривать как некий протокол взаимодействия актора и системы (а так оно и есть), то описывая разные постусловия, мы указываем возможные состояния системы после исполнения ВИ.
Ясно, что будет некое явное целевое состояние и какие-то побочные. Помните у Коберна - минимальные гарантии успеха. Т.е. что должно быть в самом худшем раскладе.
Отмена исполнения ВИ в процессе его реализации - это по сути откат транзакции, откат к исходному состоянию, к предусловию. Вам нужно это как-то указать. Это некое требование, причем, если вдуматься, негласное требование самого ВИ. Любой ВИ состоит из собственно себя - т.е. цели использования системы актором и описанием варианта использования (UCD - как говорят буржуи, причем эти буржуи всегда проводят грань между UC и UCD). В описании ВИ всегда должен присутствовать типичный сценарий событий. Отмена - тоже вполне типичный, но все-таки альтернативный сценарий. При этом словами с помощью описания это можно сделать очень просто, а графически изображать - надумаешься.

1654

Варианты Использования (Use Case) / Re: Несколько частных вопросов по ВИ

« : 16 Августа 2011, 18:59:21 »

Доброго времени суток.
1. Действие "Отмена" доступно пользователю на протяжении всего ВИ. Как зафиксировать данный момент? У Коберна встречал такую практику: на первом шаге описывается расширение со словами "В любой момент до ... пользователь может отменить ...". Не очень понравился такой способ, есть ли ещё какие-нибудь варианты?

Посмотрите такой вариант. Пример 5 и 7. Не подойдет?

1655

Варианты Использования (Use Case) / Re: Несколько частных вопросов по ВИ

« : 16 Августа 2011, 18:56:32 »

Извините, чуть в сторону.
Мой первый инструмент UML был Paradigm+ от Platinum (ныне, кажется, в составе CA). Это оно?

Нет, это совершенно новый продукт. Восходящая звезда Гонконга. http://visual-paradigm.com

1656

Системный Анализ и Требования / Re: Логично ли так формировать ТЗ?

« : 16 Августа 2011, 15:12:13 »

В принципе правильно, но только использовать подсистемы в качестве ДЛ - это не правильно.

Почему неправильно?

1657

Тестирование / Re: Test Cases на основе UML-модели

« : 13 Августа 2011, 21:08:18 »

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

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

И какой вид тестов наиболее соответствует UC - system или scenario?

Думаю сценарий.

1658

Задачи студентов / Re: Диаграмма ВИ, банковская система.

« : 13 Августа 2011, 00:19:50 »

На самом деле, то, что вам нужно для начальной модели использования, содержится в последних абзацах

   За работу с клиентами в отделении банка отвечает менеджер. В его обязанности входит добавление нового клиента и заведение счета для клиента. Клиент может иметь несколько счетов, поэтому менеджер имеет возможность читать, добавлять, удалять и редактировать данные клиента; заводить новый счет, закрывать существующий (со снятием денег или переводом их на другой счет клиента в банке), а также читать информацию о счете.
   Оформление списаний и начислений осуществляются кассиром по обращению клиента. Кассир может работать со счетами клиентов, оформленными в любом отделении банка. Учет начислений по процентам система осуществляет автоматически по истечении интервала, определяемого видом счета.
   Возможность работы с отделениями банка доступна директору, который может добавлять и удалять отделения. При удалении отделения все его клиенты и счета должны быть переведены в другое отделение банка. Директор может читать и редактировать данные об отделениях банка. Система позволяет директору получать интересующую его информацию: получение списка клиентов и их счетов по видам счетов в заданном отделении/во всех отделениях, заведенных в течение заданного периода времени.

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

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

Авторизация - возможно и важный ВИ, но вряд ли на данном этапе

Смотрю уже вторую ДВИ. На мой взгляд в ней больше ошибок, чем в первой.
1. Менеджер - Выполнить операцию с данными клиента - не находите что похоже на функциональную декомпозицию? Главное не ясна цель, зачем все это делается и почему?
2. Менеджер - добавить нового клиента - а что можно добавлять нового клиента как-то по-другому? Зачем специально выделять добавить данные, завести новый счет? да еще и инклюды. Вы кстати знаете что такое транзитивность? Да еще одновременно ВИ завести новый счет и инклюдится и есть уточнение к Выполнить операцию со счетом. Слишком сложная логика, не на той диаграмме отображается, да и не понятно зачем

Остальное в том же стиле. Сосредоточьтесь на цели использования, зачем ДЛ использует систему, что он пытается выполнить? Зачем ему добавлять данные клиента, может ли существовать счет без клиента? а клиент без счета?

Кстати я там выделил: время (или таймер) у вас тоже ДЛ: Учет начислений по процентам система осуществляет автоматически по истечении интервала, определяемого видом счета.

1659

Обучение / Re: Книга: Введение в UML от создателей языка

« : 12 Августа 2011, 11:34:57 »

Маркетинговый ход:)

1660

Обсуждение статей / Re: Рецепт работы с требованиями

« : 11 Августа 2011, 14:44:09 »

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

1661

Обсуждение статей / Re: Рецепт работы с требованиями

« : 11 Августа 2011, 14:20:40 »

Сергей, может дадите тогда свое определение процесса управления требованиям?

Ага, мне тоже интересно узнать твое определение "управление" и "управление требованиями" , в частности.
Некоторые ссылки: http://habrahabr.ru/blogs/development/114571/

1662

Идеи и мозговой штурм / Re: Тематические анекдоты и смешные истории

« : 11 Августа 2011, 11:21:15 »

По-моему, очень типичная ситуация

1663

Тестирование / Re: Test Cases на основе UML-модели

« : 10 Августа 2011, 21:00:50 »

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

Вместе с тем EA имеет неплохую поддержку для управления разработкой тестовых случаев. К сожалению я лично ей не пользуюсь, т.к. выигрыш она дает, только, если вся команда пользуется ЕА. Однако в первое время я пытался приспособить ЕА для хранения тестовых случаев. Все основные моменты наглядно отображены здесь: http://sparxsystems.com/resources/testing.html

Кроме того, если в Вашей компании используются UCs, то в EA 9 есть отличные возможности формирования тестовых случаев прямо из структурированных сценариев.

В принципе при наличии тех или иных UML моделей: модели использования, структурные модели, поведенческие, довольно легко создать и тестовый проект.
Например, у вас есть диаграмма классов, в ней класс и методы класса, соответственно можно на каждый метод класса сформировать тестовый случай (unit test). Если есть список UCs, то как и пишет уважаемый lnew, то каждому UC как минимум следует сопоставить TC, вернее каждому отдельному сценарию UC (main, altern, exeption) следует сопоставить как минимум один TC. По сути в этом случае TC = сценарию UC конкретизированному до вводимых данных и ожидаемого результата. Разработка таких тестовых случаев находится в стратегии "черного ящика" и максимальна эффективна.

1664

Идеи и мозговой штурм / Re: Применение Ваших знаний (как системных аналитиков) в собственной жизни. Цели.

« : 09 Августа 2011, 22:25:57 »

А вам чего не хватает, простите?

Простите за оффтоп и флейм. Ироничной модераторши

1665

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

« : 01 Августа 2011, 14:27:16 »

Спасибо, Леонид Борисович, за разъяснение