1

ПО Аналитика / Re: Сравнение средств управления требованиями (Requirements Management Tools)

« : 18 Апреля 2012, 18:52:21 »

Хорошая новость, PlantUML по-умолчанию встроен в Devprom, вот на всякий случай ссылка на документацию:  http://devprom.ru/docs#11712

Да-да-да. Что несомненный плюс. Я, собственно, именно там о планте и узнал...   

2

ПО Аналитика / Re: Сравнение средств управления требованиями (Requirements Management Tools)

« : 18 Апреля 2012, 15:41:15 »

Brumbel, посмотрите http://devprom.ru

Большое человеческое спасибо!  Интересная вещь, попробую.

И вот эта штуковина тоже заинтересовала: PlantUML
Мне одному пришла в голову мысль, что неплохо было бы сделать Flash или Java апплет для графического построения и редактирования диаграм "на лету" в этом средстве?

3

ПО Аналитика / Re: Сравнение средств управления требованиями (Requirements Management Tools)

« : 18 Апреля 2012, 10:35:53 »

Тоже вот столкнулся с вопросом: а какое СУТ выбрать? Раньше использовал средство моделирования RSA, что делает логичным выбор в сторону RequisitePro... Но они оба платные, причем стоят совсем не дешево. Конечно, на первых порах можно и пофлибустьерствовать в ознакомительных целях, но в дальнейшем это чревато разными сложностями.

Поэтому, скорее речь идет о том, чтобы выбрать сразу связку из RMT и CASE средств, исходя из их совместимости, доступности и достаточной функциональности.

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

Нужны инструменты, которые позволили бы нормально описывать ВИ, обрабатывать связи между ними. Помогли бы интегрировать ВИ, другие требования (как то: бизнес-правила, требования к интерфейсу, производительности и проч.), а также построенные в CASE-средстве модели в один проект. Например, использовать ДВИ в качестве иллюстрации к вариантам использования прямо в документе требований. И не в качестве скриншота, а как встраиваемый редактируемый объект (как, например, таблицы Excel в Word-документе).

Пошарил по форуму, нашел несколько беслпатных средств. Сразу скажу: онлайн (т.н. On-Demand) варианты не понравились тем, что проектная документация будет находиться у третьих лиц. Их сервис или накроется, или платным станет - и что тогда делать? К тому же, смущает потенциальная возможность доступа посторонних к проприетарной информации. OSRMT вроде хвалят, но похоже, проект благополучно загнулся несколько лет назад... Из оставшегося внимание привлекла только бесплатная версия RMT Axiom. Но в связке с каким CASE-средством (желательно тоже бесплатным) его лучше применять? Может, я выпустил из виду еще какие варианты?

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

4

О Сайте и Форуме / Re: Открытие ссылки выбрасывает с форума

« : 13 Апреля 2012, 05:50:27 »

Та же беда:
На странице FAQ Почему ВИ – это не функция? ссылка http://www.uml2.ru/index.php?option=com_smf&Itemid=45&action=dlattach;topic=47.0;attach=23

При переходе по ссылке генерится сообщение об ошибке:

Код: [Выделить]

Notice: Undefined index: db_query in /home/uml2ru62/public_html/forum/Sources/Load.php on line 142

Fatal error: Function name must be a string in /home/uml2ru62/public_html/forum/Sources/Load.php on line 142

Notice: Undefined index: db_query in /home/uml2ru62/public_html/forum/Sources/Load.php on line 2439

Fatal error: Function name must be a string in /home/uml2ru62/public_html/forum/Sources/Load.php on line 2439
... и слетает сессия. Пользуюсь Оперой последней версии. Так баг и не нашли?

5

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

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

Спасибо за наводочку. Жаль не переведена на русский. Англицкую читать все же тяжеловато.

6

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

« : 12 Апреля 2012, 08:41:54 »

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

И вообще, большое спасибо всем отозвавшимся за советы и науку. 


Как и обещал, основательно взялся за книгу "Современные методы описания функциональных требований" (Коберн А.) и наткнулся там на пару интересных, на мой взгляд, советов. Причем, похоже, как раз про "мой случай":

Действующие лица в сравнении с ролями

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

...

В UML используется незакрашенная стрелка, обозначающая, что одно действующее лицо является специализацией друrоrо (см. рис. А.6).

Такая стрелка позволяет кратко выразить, что менеджер может делать все то, что может делать служащий. Достаточно нарисовать стрелку, направленную от Meнеджера к служащему.

...

Стрелка специализации вовсе не помоrает решить rлавную часть проблемы Действующее лицо/Роль. Для служащеrо отдела продаж и служащеrо отдела аудита наборы вариантов использования перекрываются, но между ними нельзя поставить стрелку специализации, так как никто из них не может делать все, что может друrой. Таким образом, вы возвращаетесь к середнне дискуссии о действующем лице и роли.

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

...

Те, кто создают хорошие текстовые варианты использования, просто не встречают проблем, с которыми сталкиваются любители фиryрок из палочек, эллипсов и стрелок UML. Связи появляются естественным образом, коrда вы пишете разворачивающуюся историю. Они становятся проблемой, только если вы на них останавливаетесь. Чем больше опыта приобретают консультанты в текстовой и в UМL форме, тем леrче они с этим соглашаются.

Какой, однако, умный дядька... И объясняет доступно. Может, я и правда чересчур уперся лбом в диаграммки? Что, кстати, уже упоминалось местными эрудитами.  Хотя, с другой стороны, нужно ведь было разобраться с непонятным, да и новые знания почерпнул... Одним словом, еще раз спасибо! )

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

7

ПО Аналитика / Re: Документация по RSA

« : 11 Апреля 2012, 10:57:46 »

Спасибо. Про эту книжку знаю. Правда, похоже, большая редкость. Долго искал, нашел только в виртуальной библиотеке КнигаФонд.

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

8

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

« : 11 Апреля 2012, 10:19:28 »

Вам виднее. Система как-то различает авторов конференции между собой? Обычно для этого служит авторизация.

Различает, но в данном случае это не авторизация, а другой механизм, который на данной диаграмме не отражен.

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

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

Мне интересно, какое из моих сообщений можно было так истолковать? В этом Вашем примере необходимость в акторе Директоробухгалтер диктуется не тем, есть ли пользователь, совмещающий эти должности, а тем, должна ли система предоставлять этой роли специфические для неё функции + функции, доступные директору, + функции, доступные бухгалтеру. Если должна, завести такого актора имеет смысл. Если не должна -- нет смысла.
Отразить можно в описании UC Авторизоваться.

Да я просто запутался уже... Понял, спасибо.

В новой версии диаграммы предлагаю UC Создать трансляцию передать Автору.

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

9

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

« : 11 Апреля 2012, 09:53:43 »

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

Учту. Меня в данном случае не столько оформление, сколько правильность построения связей интересовала.

Пользователя = Зарегистрированный пользователь (посетитель), т.е. усилить факт самой регистрации. Поскольку посетитель он тоже пользователь "большого и вечного"

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

Меня немного смущает массивность имени ВИ. В последнем - это уже прям не имя, а краткое описание...  Это ничего?

ВИ "Изменить права доступа посетителя" - что тут имеется в виду?

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

По поводу зрителя - руководствуйтесь принципом Оккамы

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

10

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

« : 11 Апреля 2012, 06:41:52 »

Эта диаграмма составлена на основе душещипательной истории Вани (выше). Верна ли она?
Кстати, мое представление о модели в процессе создания диаграммы изменилось...
ВИ "Управлять трансляцией" в данном случае означает - изменить ее настройки или удалить.
ВИ "Модерировать трансляции" - изменить настройки или удалить любую трансляцию.
Создает трансляцию теперь Пользователь и при этом становится Автором трансляции.

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

Из диаграммы получается, что создав трансляцию, Пользователь становится Автором трансляции... По задумке, Автор трансляции может владеть только одной трансляцией. Т.е. пока он не удалит трансляцию и не станет обратно Пользователем, создавать трансляции он не может... а по диаграмме получается, что этот функционал им унаследован. Как здесь быть? Указывать вес связи: Пользователь * --- 1 Создать трансляцию?

11

ПО Аналитика / Документация по RSA

« : 11 Апреля 2012, 04:39:40 »

Может ли кто-нибудь посоветовать хорошую книгу по Rational Software Archtect SE (7.5)? Если можно, с линком. Желательно на русском. Искал-искал - без толку. Ну или линк на хорошу подборку статей по нему.

Хотя я вот еще о чем подумал: в плане проектирования на UML я еще нуб. Само собой, в CASE-средствах - то же. Может, мне не стоит пока возиться именно с RSA (его выбрал потому что он, как я понимаю, является "наследником" Rational Rose, по которой есть куча книжек)? Есть ли другие CASE-средства со схожими возможностями, но более подходящие для новичков и по которым есть литература?

12

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

« : 11 Апреля 2012, 04:03:34 »

Ох...  Ниче не понял...  Щас как понапишууу... 

Допустим так. Проходят ли авторы и участники конференции авторизацию?

Нет, их функции доступны без этого.

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

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

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

Ваня обиделся на Злого Петуха и назвал его злым петухом. Модератор оскорбился и усмотрел в этом нарушение правил проекта. Нажал на панельке крестик и удалил ванину трансляцию. Больше никто не видел, какой Ваня красивый и умный."

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

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

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

Вот я чего понять не могу... 

А если роль человека в системе меняется со временем. Например, сперва зашел на сайт. Поглазел на трансляции как обычный Зритель. Потом авторизовался, оказалось, что он Модератор, то это все тоже надо отражать? Как? В диаграммах деятельности?

13

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

« : 10 Апреля 2012, 14:36:16 »

А вы кто в процессе? Вы же и разработчик?

Да. Буду непосредственное участие в разработке принимать. Так что во многом формулирую требования "для себя", чтобы разобраться, какой именно должна быть система в конечном итоге. У нас команда маленькая, несколько человек.

14

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

« : 10 Апреля 2012, 10:28:06 »

Без описаний действующих лиц уточнить, какая из двух диаграмм верна, затруднительно. Могут ли автор Трансляции и Модератор Трансляции делать с трансляцией то, что делает Зритель? Вероятно, да.

Ммм... я смотрю на это немного по-другому. Т.е. что (актеры!) Модератор Трансляции и Автор не могут делать с трансляцией то, что делает Зритель (т.е. смотреть трансляцию они не могут априорно). У них четко очерченые функции. Автор может только трансляцию создать (опубликовать), удалить, изменить ее настройки. Модератор может только изменить ее настройки или удалить. Все, больше никаких функций у этих актеров нет.

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

Имеет ли право на жизнь такое мнение, такая трактовка при моделировании на UML?

Кто такой Пользователь? Чем он отличается от Зрителя?

Посетитель - любой посетитель сайта.
Пользователь - авторизованный посетитель сайта.
Зритель - тот, кто просматривает трансляцию.

15

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

« : 10 Апреля 2012, 09:18:35 »

Так, еще (хотя предыдущих вопросов это не снимает...) для приличия уточнить хочу (нуб я или когда? ). Генерализация ведь является аналогом механизма наследования в ООП? Данная диаграмма верна?



И не будет ли лучше так:



По идее, и то, и то верно... Но какой вариант, так сказать, более "православен"?

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

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

Что скажете? Сам я склоняюсь варианту на первом рисунке.

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

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