241

ПО Аналитика / Re: Системы управления требованиями

« : 20 Января 2011, 15:56:17 »

Очередная рекламная акция: эта щеточка увеличивает длину ресниц на 345,4 %!

Я не знаю рекламируемого инструмента, даже не видел. Два других пробовал, с RequisitePro работаю постоянно.

Критерии сравнения вызывают сомнения.

Например, почему сравнивается возможность выводить информацию в Excel (это кому-то надо?), и не сравнивается возможность синхронизации требований с задачами MS Project?

А как насчет моделирования? Своего моделирования у RP нет, но есть беспрецедентная интеграция со всеми средствами моделирования Rational. Любой элемент модели может быть определен как требование RequisitePro. Отсюда - возможность отследить, на какие модельные элементы повлияет изменение требования.

Опять же, что-то не заметил я отслеживания зависимостей между требованиями (может быть, я упустил).

Во многих местах "крестики" проставлены неправильно, д.б. "галочки".

RequisitePro - инструмент для управления требованиями. Все дополнительные операции вынесены в другие инструменты, с которыми установлена интеграция. И это хорошо, т.к. можно сфокусироваться на "своих" возможностях.

"Лучше меньше, да лучше!"

242

Задачи студентов / Re: Курсовая работа (построение диаграмм UML)(критика)

« : 15 Января 2011, 23:41:11 »

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

Дорогой друг Vokist!
Боюсь, мечты уважаемого Эдуарда не оправдаются! (Это насчет пяти шаров). Понимаю, откуда у студента время!

Совет: когда читаешь технический текст, читай внимательно. Если текст описывает картинку или отзыв на картинку, читай и просматривай те части картинки, о которых идет речь в тексте.

Не нравятся прецеденты "ввести", "удалить"?
Я уже писал, это не прецеденты! Это действия в прецеденте! Они должны быть или описаны текстом в описании прецедента, или представлены в соответствующей диаграмме деятельности!

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

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

Диаграмм деятельности должно быть столько, сколько прецедентов! Все иное - грубейшая ошибка!

Про классы пусть Эдуард пишет, если у него есть время.

Извини, если слишком грубо. Зато справедливо.

243

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

« : 14 Января 2011, 01:13:24 »

Дааааа..... !

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

А если серьезно, то ТЗ Вы не напишете, т.к. у вас не хватит квалификации. Но Вы можете попробовать создать документ(ы) с условным названием "Информационные потоки в отделе ...".

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

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

Всё, задание выполнено! Все, что Вы могли, Вы сделали.
Т.к. из вашего письма понятно, что Вам это не нужно, этого достаточно.

Лозунг, который когда-то висел над моим рабочим столом и приводил в ярость моих командиров:
ДЕЛАЯ ЧТО НИБУДЬ БЕСПОЛЕЗНОЕ, СЛЕДУЕТ ОГРАНИЧИТЬСЯ САМЫМ НЕОБХОДИМЫМ!

Успехов 

244

Задачи студентов / Re: Курсовая работа (построение диаграмм UML)(критика)

« : 11 Января 2011, 22:44:13 »

Добрый вечер!
Т.к. Эдуард взял на себя труд "критики" структуры, я продолжу "критику" (если можно так назвать) описания функциональности (в данном случае - диаграммы деятельности и идентификации прецедентов).

В справочнике UML, 2-е издание, авторов Буч и Ко, это "диаграмма, на которой показано разложение некоторой деятельности на ее составные части".

Наверное, основное назначение диаграммы - это описание выполнения прецедента (есть и другие приложения).

При описании прецедента деятельность (activity) принадлежит прецеденту, а диаграмма, естественно, деятельности. Т.е. нужно соблюдать правило: один прецедент -> одна деятельность -> одна диаграмма деятельности.
Примечание: составная часть деятельности сама может быть деятельностью; т.о. может образовываться иерархия диаграмм, ужасно подробно описывающих выполнение прецедента.
Вам это, м.б., и не нужно!

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

Для явного указания на диаграмме, кто выполняет действие, имеется элемент "дорожка" (в UML 2 - Partition). У Вас д.б. две дорожки: субъект и система. Каждый узел диаграммы помещается в тот раздел, который представляет исполнителя.

"Мячик" перекидывается между субъектом и системой. Словами это можно выразит примерно так:
- субъект выбирает тип отчета
- система, если субъект выбрал "Инвентарная книга", отображает окно настройки отчета Инвентарная книга
                если субъект выбрал "КСУБФ", отображает окно ...
Все это, конечно, графически. Ну, и названия действий должны кратко, но понятно, отображать их содержание (действия - это не названия окошек, а действия, выполняемые системой или субъектом).

Думаю, с объяснением нового материала, на сегодня, достаточно.

Есть явная ляпа, которую многие, особенно начинавшие на UML 1x, не замечают: в самое верхнее действие входят два потока управления. В UML 1х такой прием даже рекомендовался для лаконичности. UML 2 много формальнее (жесткий формализм объясняется тем, что UML 2 разрабатывался для поддержки концепции MDA). В данном случае получается клинч: если в действие входят два потока управления, то действие начинается только тогда, когда управление "прибежит" по обоим потокам. Здесь этого не может быть в принципе, значит действие никогда не будет выполнено. Т.е. такая нотация применима только, если это параллельные потоки.
Для объединения потоков нужно использовать элемент Mtrge Node (это ромбик, похожий на Decision Node, но это другой элемент с другими свойствами). Если Ваш инструмент такого элемента не имеет, используйте ромбик Decision. На вид все будет корректно, а код генерировать из диаграммы деятельности Вы, как я понимаю, не собираетесь.
Проверьте, нет ли еще таких ситуаций.

Кстати, название этого действия - это явно название окошка. Это весь прецедент - формирование отчета. На самом деле это "Отображение окна ...", после которого следует действие субъекта типа "Выбор продолжения", и снова, на стороне системы - ромбик и альтернативные потоки.

245

Задачи студентов / Re: Курсовая работа (построение диаграмм UML)(критика)

« : 10 Января 2011, 13:27:49 »

Вернемся к диаграмме прецедентов.

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

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

Вы, Vokist, пытаетесь нарисовать одну диаграмму прецедентов для всей системы.
Даже для Вашей маленькой системы она не помещается на листе бумаги. А если это будет большая система.
А как быть с системой, которая содержит сотни прецедентов? Выход - в структуризации.

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

На вашей диаграмме есть три пакета с именем "Прецедент верхнего уровня". Это название недопустимо! Это не прецедент! Нет прецедента "Формирование библиотечного фонда"! Есть несколько (два) прецедента, которые выполняет Ведущий библиотекарь для формирования библиотечного фонда.

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

<название проекта>
   <модель прецедентов>
      <пакет, содержащий субъектов>
         ...
         <диаграмма прецедентов> Субъекты системы
      <пакет, содержащий прецеденты 1-й функциональной области, например:> Формирование библиотечного фонда
         <прецедент, например:> Формирование каталога книг
            <прецедент расширения, если есть>
            <другой прецедент расширения>
            <диаграмма прецедентов> Контекст прецедента ...
         <...> Формирование каталога экземпляров (про это название я уже писал!)
         <диаграмма прецедентов с названием> Прецеденты функциональной области "Формирование библиотечного фонда"
      <пакет 2-й области>
         ...
      <пакет третьей области>
         ...
   <проектная модель>
...

Получилось не очень красиво, и не знаю, понятно ли.

Еще об абстрактных прецедентах.
- Прецедент расширения не может расширять более одного прецедента! Общие части нескольких прецедентов должны определяться как прецеденты включения.

О прецедентах вообще.
- Прецедент, если это не абстрактный прецедент, должен иметь субъекта, цель которого он выполняет (некоторые инструменты позворяют определять для элементов ключевые слова, если у вас позволяет, то ассоциации субъект-прецедент нужно назначить ключевое слово primary.
У Вас есть прецеденты без субъектов!

Дорогой Vokist!
Любые усилия должны быть оптимальными для достижения поставленной цели.
Если Вы собираетесь стать системным аналитиком или проектировщиком, Вам стоит почитать книжки, попрактиковаться и т.д. Думаю, участники форума, и я в том числе, с удовольствием Вам помогут в достижении этой благородной цели!
В принципе, задачка для такой учебы подходит, и если ее довести до ума, она могла бы стать хорошим пособием. Тем более, можно проследить весь цикл, от требований до развертывания продукта.

Если же у Вас утилитарная цель сдать курсовик, не напрягайтес! Трояк, я думаю, Вам гарантирован.

Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru

246

Задачи студентов / Re: Курсовая работа (построение диаграмм UML)(критика)

« : 10 Января 2011, 02:19:12 »

Думаю, это не то, о чем мечтали большевики!
Напишу утром, сейчас уже поздновато!

247

Задачи студентов / Re: Курсовая работа (построение диаграмм UML)(критика)

« : 09 Января 2011, 17:50:09 »

Успехов!

248

Задачи студентов / Re: Курсовая работа (построение диаграмм UML)(критика)

« : 09 Января 2011, 17:07:51 »

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

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

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

А вообще, когда программа уже сделана, диаграммы UML рисовать поздно!

249

Задачи студентов / Re: Курсовая работа (построение диаграмм UML)(критика)

« : 09 Января 2011, 15:21:07 »

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

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

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

Совет (из RUPа):
- В модели прецедентов создайте пакеты UML для помещения прецедентов одной  функциональной области, и назовите их как прецеденты верхнего уровня. У Вас будет три таких пакета. В описании пакетов коротко опишите их назначение (фактически - повторение ваших длинных названий прецедентов). Перетащите в эти пакеты прецеденты, расширяющие соответствующие прецеденты верхнего уроня. Сами прецеденты верхнего уровня удалите из модели: это не use case!
- Удалите все прецеденты расширения, которые не являются таковыми. Сохраните только те, которые Вы действительно будете реализовывать как отдельные модули, т.е действительно будете расширять функциональности расширяемых прецедентов. Проверьте, xто в описании каждого прецедента кратко описана его функциональность. Например: "Формирование справочника "Тип литературы" должно включать следующие возможности: добавление нового типа, изменение типа, удаление типа)".
- В каждом пакете функциональной области нарисуйте свою маленькую диаграмму прецедентов "Прецеденты функциональной области..."
- Пересмотрите свое отношение к субъектам. Вместо одного появятся много, выполняющих прецеденты, соответствующие их ролям в библиотеке.

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

На диаграмме классов:
- укажите множественности
- подумайте о типах ассоциаций
- название класса "Экземпляр" плохое, наталкивает на мысль, что Вы не знаете, что такое в UML спецификация экземпляра.

По диаграммам компонентов - без комментариев (см. замечание № 1)

Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru

250

Примеры / Re: Не хочу больше делать ошибки с проектированием

« : 06 Января 2011, 20:11:12 »

Спасибо. Вопрос решен.

251

Примеры / Re: Не хочу больше делать ошибки с проектированием

« : 06 Января 2011, 18:21:32 »

Большое спасибо!

А зайдите на корень, http://lnew.ucoz.ru, Каталог статей.
Видимо, что-то со ссылкой. Я проверю, исправлю.

Ваше мнение для меня важно.

252

Примеры / Re: Не хочу больше делать ошибки с проектированием

« : 06 Января 2011, 17:28:31 »

Еще раз спасибо за детальный разбор.

Я считаю интересы ЗЛ первичными, а модели - это отображение этих интересов, как их  понимает аналитик. Я уже писал выше, что моделировать не обязательно, но теперь многие это делают. И кто-то использует UML.

Если Вы хотите удостовериться, что я думаю именно так, посмотрите http://lnew.ucoz.ru, Моделирование заинтересованных лиц в TOGAF.

А вот, как вставить файл картинки в сообщение, я так и не узнал. Может, этого вообще нельзя сделать?

253

Примеры / Re: Не хочу больше делать ошибки с проектированием

« : 06 Января 2011, 17:01:54 »

Бедный Alexeyzf!
Но откуда мы знаем, что он аналитик или собирается им стать?
И кто сказал, что он не выполнил анализ требований (в своей голове)?
Мало того! Откуда такая уверенность, что рисовать диаграммы нужно после анализа?

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

Вот, великий Коберн вообще на UML плюется, и нам повезло: иначе мы не читали бы его замечательную книгу. Я по этой книжке многому научился. Но, тем не менее, без UML так описывать прецеденты не смог бы.
А если Вы посмотрите мои спецификации, они очень похожи на "эффективные юзкейсы", хотя получены генерацией из модели.

254

Примеры / Re: Не хочу больше делать ошибки с проектированием

« : 06 Января 2011, 15:47:38 »

Леонид, можно обойтись без дорогих инструментов round-trip engineering, копирования диаграммы как картинки, заливки её на хостинг и вставки в пост.

Сервисы типа yuml.me позволяют генерировать диаграммы способов применения на лету, просто указываю нужные атрибуты в URL.

Спасибо. Я не хотел рисовать диаграммку на лету. Я скопировал ее из живого проекта, в котором сейчас работаю,  в файл .jpg, который, вследствие технической безграмотности, не сумел вставить в свой ответ.
Что касается дорогих инструментов, я, нарное, зря их упомянул. Диаграммку, проще всего, рисовать на салфетке. Есенин стихи писал на манжетах.

Рисовать в инструментах (дорогих) имеет смысл, если собираешься использовать информацию. Например, для генерации документов или выполнения преобразований моделей, например, из модели use cases в проектную модель, и т.д., как описано в MDA.

Относительно анализа требований. Помните про Золотую рыбку? Она буквально выполняла высказанные желания.
Alexeyzf ничего не спрашивал про анализ требований. Он хочеn писать код и учит UML.
Так давайте следовать опыту Золотой рыбки!

255

Примеры / Re: Не хочу больше делать ошибки с проектированием

« : 06 Января 2011, 14:07:00 »

Простите, картинку вставить не научился.
Никак не получается.
Если хотите посмотреть, пожалуйста, расскажите, как Вы свою вставляли.
Или могу выслать по почте.