1576

Книги, статьи и ресурсы / Re: К Вигерс, Разработка требований к программному обеспечению--пропущенные страницы

« : 12 Сентября 2011, 16:16:50 »

аааа://depositfiles.com/files/ol4qeh1hl
Версия 1.4

Ну просто стахановец!

1577

Поздравления / Re: Поздравляем Юру Булуя с Днем Рождения

« : 11 Сентября 2011, 20:46:26 »

Со сднем варенья тебя!

Александр - видно еще не совсем протрезвел

Юра, Siku njema ya kuzaliwa

1578

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

« : 11 Сентября 2011, 20:43:16 »

RuZzz,

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

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

То что VP разрешает делать поддиаграмму - это проблемы VP. Ведь ВИ - это классификатор - UML элемент. К UML элементу можно построить поддиаграмму. Вопрос правомерности переложен на Вас

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

не стоит

1579

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

« : 11 Сентября 2011, 00:43:25 »

Не надо усложнять простые вещи.

UC - описывает взаимодействие двух действующих лиц. Одно ДЛ - наша система в разработке, на рассмотрении. Другое ДЛ - это внешняя сущность, то что вне системы, которую мы изучаем.

Внешние сущности нужны, чтобы понять каковы границы нашей системы, каков назначение нашей системы. Грубо зачем наша система нужна внешним актерам=сущностям

Актеры - это роли людей, других систем, в том числе организаций, устройства
Система - это организация, устройство, система

Вариант использования просто не имеет смысла рассматривать вне контекста субъекта, к которому он применяется.

То, что вы нарисовали - противоречит и здравому смыслу, и нотации. Один ВИ не может быть контекстом другому.
Разные уровни абстракции - это разные уровни детализации, а не способ композиции/декомпозиции.

ДБВИ - вообще возникли в RUP, в UML об этом нет ни слова. Потому каждый волен интерпретировать по-своему. Но тут нужно следовать здравому смыслу.
ДБВИ отличает от ДСВИ разве что контекстом (boundary) субъектом.

Вот пример:

Система = Магазин
Актер= Покупатель
ВИ = Купить книгу или Ознакомиться с ассортиментом (т.е. покупатель использует магазин чтобы Купить книгу или Ознакомиться с ассортиментом)
Актер = Поставщик
ВИ =  Получить прибыль от поставки книг (поставщик использует магазин чтобы Получить прибыль от поставки книг согласно контракту)

Актер = Покупатель (цель покупателя получить книгу во владение или даже прочитать книгу или даже получить удовольствие от прочтение или улучшить свои знания в предмете...)
Система = Система он-лайн заказов книг магазина
ВИ = Разместить заказ, Ознакомиться с ассортиментом, Контролировать(наблюдать) исполнение заказа
Типично: уровень облака или воздушного змея - это уровень предприятия в целом, уровень моря - уровень пользователя - суть варианта использования, уровень дна - ВИ абстрактного типа или какие-то специфичные вещи типа Login to system

1580

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

« : 10 Сентября 2011, 21:30:20 »

А если представить что последняя картинка это не ДВИ для разрабатываемой системы, а БДВИ для организации.

Последняя с какого края (верхняя али нижняя)?

Неужели в этом случае "Получить товар" и "Заказать товар" оба будут находится на верхнем уровне то есть в предельной области действия), где "Получить товар" включает "Заказать товар"?

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

Вы рисуете зависимость включение от Получить товар к Заказать товар. Т.е. для того чтобы получить товар нужно его заказать. Но это причинно-следственная связь, она никакого отношения к использованию системы не имеет.
Да и вновь вопрос, а как система называется?

Ну к примеру Получатель товара (Актер) - Получить товар (В границах Почта) - это один ответ, если в границах Склад - другой и т.д.
Но на каком бы уровне мы не находились Получить товар и Заказать товар - два разных способа применения системы, какой бы она не была

Может организация например допускает что можно просто Зарезервировать товар (или есть какой то другой ВИ который является под целю  для "Получить товар", так же как и "Заказать товар"). То есть для БВДИ последняя картинка логичная?

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

1581

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 10 Сентября 2011, 21:22:01 »

Итак, ответ Антона Холодкова по поводу составления rss-канала по определённому тегу в Вордпрессе:

- Вообщем, все оказалось проще простого.
Используются стандартные средства WordPress без каких-либо дополнительных плагинов и настроек.
Просто в строку просмотра списка записей по определенному тэгу: http://www.kholodkov.ru/it/?tag=uml2-ru
добавляется параметр: &feed=rss2

В итоге имеем rss-канал по адресу: http://www.kholodkov.ru/it/?tag=uml2-ru&feed=rss2

Супер! Павел спасибо за хорошую работу.

1582

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

« : 09 Сентября 2011, 17:44:04 »

А как тогда показать(или может описать) взаимосвязь между этими ВИ на БВДИ и ДВИ?

Здесь нарушение на логическом уровне. Нельзя смешивать БВИ и СВИ. Но взаимосвязь показать можно зависимостью например.

Смотрите Заказать товар - что это такое? в каком контексте? Цель какова? Очевидно чтобы получить товар.
Т.е. бизнес-процесс для получения товара включает заказ товара. Если Вы автоматизируете заказ товара, то имеет смысл только ВИ Заказать товар. Хотя возможно в вашей галактике уже существует телепортация или вы живете в полностью информационном обществе и товар производится непосредственно дома, достаточно получить программу изготовления, но в нашей галактике мы еще не научились этого делать. Поэтому ВИ Получить товар к сожалению нет. Можно Получить извещение о получении товара (на почте например)

1583

Примеры / Re: Описание поведения GUI средствами UML

« : 09 Сентября 2011, 17:37:03 »

Вы получили полносвязный граф. Такое возможно. Для улучшения наглядности можно ввести промежуточное псевдосостояние. Или соединитель - join

1584

Вакансии / Re: Системный архитектор Documentum

« : 09 Сентября 2011, 13:18:42 »

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

Саша, а в чем проблема? раздражает? но ведь в какой-то степень и цель форума помочь найтись?

1585

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

« : 09 Сентября 2011, 13:08:51 »

Вопросы ко всемА если язык реализации не ООП, а процедурный? Возможно ли рисовать такую диаграмму активности для UC в которой бы преобладали activity и они же постепенно раскладывались на диаграммы активности на более низком уровне опускаясь до реализации.
Мой инструмент(VP) упорно не хочет из шагов в текстовом описании создавать Activity, он их трактует как Action.
Всё таки хочется понять технологию трансформации ВИ в реализацию.
Или услышать рекомендации.

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

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

если такая ситуация верна то какое отношение у этих двух ВИ? в каком случае отношением  будет "включить", а в каком "Зарегистрировать товар" является под целю "Добавить товар", то есть на более низком уровне. Оба способа я нарисовал на диаграммах.

Неверное понимание на мой взгляд. все эти переводы в чистовики и обратно - суть реализация. Что нужно пользователю. какая его цель, в чем бизнес-задача? Поймете  - это и будет вам ответом.
Зарегистрировать товар предполагает его добавление в систему. Регистрировать более абстрактно чем добавление, добавление, шаг возникающий при регистрации

1586

Системный Анализ и Требования / Re: Определение границ системы

« : 09 Сентября 2011, 08:36:12 »

Да, в RUP я этот раздел нашел (несколько схоже с тем, что написано у Коберна), спасибо, SADT тоже посмотрю.

Лёша, посмотри например тут: http://dit.isuct.ru/ivt/books/CASE/case8/sadt/gl22.htm.

1587

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 08 Сентября 2011, 23:10:40 »

В своей повседневной деятельности мы постоянно используем термин Change Control Board, но если я выпендрюсь и скажу "Группа по управлению изменениями", меня вероятней всего, не смотря на загрузку в проекте, отправят в отпуск - отдохнуть.

Я думаю это может произойти, только в случае большого участия иностранного капитала в проекте. Нам, например, все равно, как это будет называться. Возможно мы даже не осознаем, что делаем Change Control Board, когда возникает потребность принять серьезное решение при изменении требований.

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

1588

Системный Анализ и Требования / Re: Определение границ системы

« : 07 Сентября 2011, 23:08:11 »

Ну у Коберна есть некая таблица. Столбец понятий предметной области, столбец вне границ и столбец внутри границ - ну и ставишь крестики - нолики.

- Это один способ.

Другой способ - собственно вся деятельность, связанная с созданием модели использования

Есть рекомендации у Левенгуэлла, если мне не изменяет память.

Собственных (особых) наработок нет

1589

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 07 Сентября 2011, 23:07:22 »

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

Просто у меня цель, чтобы блоггер и нас рекламировал, а твоя цель предоставить интересный материал Моя ширее

1590

Вакансии / Re: Разработчик ETL со знанием web-разработки

« : 07 Сентября 2011, 17:37:09 »

что для Вас было бы более ценным?

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