4411

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

« : 09 Января 2008, 10:47:08 »

Gevorg, рад что Вы снова с нами
Вообще у нас главный специалисто по ЕА - Irr, подождем ее ответов. Где-то у нас ведется тема типа FAQ, советую повторить пост там, и подождать, что скажет наш ЕА гуру.
Тем не менее беру на себя смелость прокомментировать

1. Странно, создаю в ЭА требование и класс, который его реализует, создаю связь.
Открываю свойства класса,  в закладке Links вижу связь с требованием.
Открываю свойства требования - закладки Links нет вААще.

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

2. А где же полноценные диаграммы коммуникации в ЭА?
Сиквенс-есть, а коммуникации - нету, а тем более автоматического преобразования их друг в друга.
Что это? Я чего-то не нахожу, или у меня старая версия ЭА? (v7.08)

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

3. Странно, а какое назначение закладки "Сценарии" у многих элементов, не имеющих ничего общего с ВИ?
Например - свим-лайны, артефакты, актёры, бизнес-ентити.

Наверное никакого. Скорее всего просто такова метамодель в ЕА.

4. Ещё про сценарии. Очень хочется выделить сценарии ЮзКейса отдельными элементами диаграммы,
чтобы ссылаться на них трассировочными связями от требований или других элементов диаграмм.
Например, чтобы можно было наглядно показать, что подключение отдельной дополнительной
компоненты необходимо для реализации только одного альтернативного сценария (или нескольких, но из разных ВИ).
Пока не вижу в ЭА стандартных средств для этого.
И уж совсем очевидная потребность:
связать определённый сценарий ВИ хотя бы с соответствующей Сиквенс-диаграммой, раз уж нет полноценных диаграмм коммуникации.

Да такого явно нет, однако можно использовать обновляемые нотации (может это поможет как-то: http://www.uml2.ru/index.php?option=com_content&task=view&id=119&Itemid=48)

5. Вот, хотелось чтобы требование типа
"Система должна обеспечивать до 3тыс позиций у одной товарной накладной"
Можно было явно притрассировать к мощности связи на диаграмме классов, ан-нет, -
трассировать требование можно только к "квадратику или овальчику".
Даже просто на связь сослаться трассировкой ниЗЗя, хотя требований типа
"Интерфейс Z между компонентами А и Б должен удовлетворять требованиям стандарта Х" - море.
В Визио - там есть возможность создать на линии "точку привязки"
и цеплять к ней конец другой стрелочки, неужели Архитект не даёт подобных возможностей?.

по всей видимости в ЕА такое сделать нельзя, либо просто трассировать к реализуемому классу

6. Требования, ишью и реквесты в ЭА нарисованы одинаковой фигурой
- наталкивает на мысль, что между ними должно быть много общего.
Не случайно, наверное, многие изобретательные разработчики приспосабливают баг-трекеры к управлению требованиями.
В СтарТиме - так там баг трекер прямо так и оперирует не с БАГом, а с чейндж-реквестом.

ачто такое реквесты? Я что-то не нашел такого элемента. Вы имели в виду feature? Или change?

По РаКвесту.

1. Нет Ишьёв и чейндж-ревестОв.
Если в ЭА велось обсуждение проблемы, или было заказано изменение требования в чейндж-реквесте,
то всего этого не увидишь в РаКвесте.

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

2. Возможность генерации классов по элементам глоссария порадовала, но есть ли дальнейшая синхронизация?
К примеру, если я заметил грамматическую ошибку в названии соответствующего класса -  и тут же на месте её исправил,
то что нужно проделать для исправления оной в РаКвестном глоссарии?
И как я могу увидеть трассировки от требований к строчке глоссария? Есть такое в РаКвесте?
Или только в ЭА вручную проставлять трассировки от требований к соответствующему строке глоссария классу?

аналогично

3. Сильно раздражает отсутсвие  прав на редактирование диаграмм зависимости требований.
Не гарантирую чистоту эксперимента, но у меня получалась такая досадная ситуация:
Открываю диаграмму зависимости требований в РаКвесте - автоматически сгененрированная картинка не нравится.
Открываю ЭА, нахожу соответствующую диаграмму, правлю расположение, сохраняю.
Открываю эту же картинку снова в РаКвесте - он снова её переделывает на свой автоматический манер.
Снова иду в ЭА, смотрю картинку там, надеюсь увидеть свой сохранённый вариант размещения алементов,
 но оказывается, РаКвест и её "подправил".

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

4. Какой смысл в дереве иерархии требований?
Что это за связь между ними такая, что есть в структуре дерева проекта и никак не отображается в матрице?
У меня есть свои соображения по этому поводу, опять же, как результат неявно предлагаемой разработчиками ЭА концепции.
Как дойдут руки - напишу, а пока просто не буду использовать эту возможность.

Опять же пример - и формулировка вопроса. Отправлю разрабочикам и буду ждать ответа

4412

Примеры / Re: Моделирование системы тестирования

« : 09 Января 2008, 10:16:25 »

Ну что, на навигацию забили???

Фу как грубо.

Судя по Розе (а мне кажется она все же ближе к истине), либо мы рисуем агрегацию/композицию у класса А либо мы рисуем там стрелку.
Но во всех примерах в Интете есть два разделения:
1. Либо вообще навигации нет
2. Либо навигация расположена на другом конце от агрегации/композиции

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

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

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

Из этого спича можно заключить навигация важна именно в момент реализации и сильно зависит от способа реализации. IMHO конечно

4413

Тестирование / Re: Место тестирования в процессе разработки ПО

« : 09 Января 2008, 09:27:36 »

С этой целью на базе корпоративной платформы в компании реализована система управления работами. Если в ходе тестирования обнаруживается ошибка или проблемы, в СУР размещается работа. Менеджер работы просматривает и распределяет по исполнителям. Автор работы, часто является и проверяющим.

4414

Примеры / Re: Задачи на построение диаграммы вариантов использования

« : 08 Января 2008, 21:02:30 »

Спасибо A_K. Интересные изменения.

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

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

вот это: "По информации о длине маршрута система расчитывает стоимость проезда, которая сообщается водителю." это уже усложнение imho. Проще использовать счетчики.  Правда это не хуже фразы, что используется ГИС для оптимизации маршрута. Поскольку трактовать ее можно по-разному. ГИС - может быть совершенно независимым приложением, который использует диспетчер или водитель. Может существовать и явное взаимодействие разрабатываемой нами системы и ГИС через некий интерфейс, через который наша система передает отправную точку и пункт назначения, а получает некий оптимальный маршрут. Вообще я бы в данном случае ГИС бы выкинул, или оставил бы как некую ловушку усилив фразу типа: диспетчер использует ГИС города для расчета оптимального маршрута.

Но вот какая мысль пришла мне в голову. Зачем изменять формулировку? Может изменить вопрос?
Нарисовать диаграмму вариантов использования (use case diagram) системы автоматизации работы службы диспетчерской такси.
Как Вы думаете, в этом случае достаточно было бы старой формулировки?

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

Я задаюсь вопросом, поскольку формулировка задачи не МОЯ. Безусловно задача вырвана из контекста, в реальности вообще такой постановки как нарисовать ДВИ не было бы. Безусловно был бы анализ и создание модели вариантов использования.

Чтобы дискуссия продолжилась и в другом направлении, посмотрите, пожалуйста, вот в этом направлении, там я публиковал пример билета, которые я лично формулировал и предлагал студентам на экзамене:
http://www.uml2.ru/forum/index.php?topic=137.msg6537#msg6537 (тот что по ОООА)

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

4415

Примеры / Re: Задачи на построение диаграммы вариантов использования

« : 08 Января 2008, 14:17:43 »

Ну почему, эта работа требует умения анализировать описание в свободном формате и выделять из него ВИ, понимания смысла и принципов построения ДВИ. Разве этого мало?

Да я тоже полагал так, когда публиковал задачу. Однако дискуссия подняла пласт проблем.

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

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

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

4416

Реализация / Реализация ассоциаций

« : 08 Января 2008, 12:33:15 »

Опубликовал небольшой пост на тему реализации ассоциаций. Можно посмотреть здесь: http://galogenit.livejournal.com/1476.html

Комментировать можно как в журнале, так и здесь. Кому как покажется интереснее и проще

4417

Примеры / Re: Моделирование системы тестирования

« : 08 Января 2008, 11:28:31 »

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

4418

Примеры / Re: Моделирование системы тестирования

« : 07 Января 2008, 20:50:57 »

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

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

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

4419

Примеры / Re: Компания по продаже полов, ламината, в большом количестве но в розницу

« : 07 Января 2008, 17:23:38 »

А что означает "как у людей".

Саша, предлагает Вам сформировать Видение или образ Вашей системы или концепцию.

Цель определяет развитие проекта, задает контекст, функционирование системы.

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

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

На стадии анализа требований будут возникать какие-то артефакты.

В ходе анализа Вы будете формировать набор моделей: модель классов, модель взаимодействия, модель состояния.

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

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

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

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

4420

Примеры / Re: Моделирование системы тестирования

« : 07 Января 2008, 17:10:14 »

Эдуард, Rational Rose с Вами не согласен.

Может быть. Разные средства моделирования реализуют ассоциации по-разному. Я экспериментировал в Enterprise Architect. Тут все зависит еще и от того, как рисуешь связь, т.е. кто источник, а кто мишень.

Однако хотелось бы понять как правильно.

Читая книгу Рамбо и Блаха ""UML2.0 Объектно-ориентированная разработкаи и моделирования", обнаруживаю следующее:
односторонние ассоциации реализуются при помощи указателя (в логическом смысле). При реализации это может быть указатель, ссылка языка программирования или даже внешний ключ базы данных.
для двухсторонней ассоциации могут быть три подхода:
одностороння реализация - реализовать  в виде одностороннего указателя и выполнять поиск при прослеживании в обратном направлении. используется если частота прослеживания в одном направлении сильно отличается от другого направления.
двусторонняя реализация - с указателями в обоих направлениях.
реализация при помощи объекта.

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

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

4421

Примеры / Re: Компания по продаже полов, ламината, в большом количестве но в розницу

« : 07 Января 2008, 16:39:28 »

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

4422

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 07 Января 2008, 14:38:48 »

Эд, ты не поверишь - у Гугла.

Язва 

4423

Примеры / Re: Компания по продаже полов, ламината, в большом количестве но в розницу

« : 07 Января 2008, 14:36:45 »

Не буду с Вами спорить по поводу семантических особенностей понятний концептуальная модель, ERD и т.п.

Я уже запутался в Ваших рассуждениях. От нас что нужно?

4424

О Сайте и Форуме / Re: Поздравляем с НГ и Рождеством

« : 06 Января 2008, 18:53:39 »

ага, тем более среди нас много и студентов

4425

Примеры / Re: Моделирование системы тестирования

« : 06 Января 2008, 18:52:22 »

Не хочется вступать в философский спор, но

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

Смотрите, поскольку связь 1-ко-многим, то независимо от навигации среди атрибутов класса Группа будет атрибут Студент типа Студент.
 
Поскольку стоит агрегация, то навигация ничего нового не дает, как бы вы ее не меняли задание классов остается тем же самым.

Однако если будет ассоциация, то тут уже гораздо интереснее ситуация
1. Группа (нет навигации) - Студент (нет навигации)
имеем
Public номер As int
Public курс As int
Public m_Студент As Студент
и
Public номер зачетки As char(5)
Public ФИО As char(100)

2. Группа (навигация) - Студент (нет навигации)
имеем
Public номер As int
Public курс As int
Public m_Студент As Студент
и
Public номер зачетки As char(5)
Public ФИО As char(100)
Public m_Группа As Группа

3. Группа(нет навигации) - Студент(есть навигация)
ситуация подобна пункту 1

4. Группа(навигация) - Студент(навигация)
ситуация 2 повторяется