Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / UML(проектирование) / 6 сообщений из 6, страница 1 из 1
18.03.2007, 13:24
    #34398521
NorthStar
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
UML(проектирование)
Есть следующая задача:
В процессе анализа предметной области любого проекта возникает некоторое количество описаний возможностей будущего продукта, которые называются требованиями. Потенциально требования могут добавляться на всем протяжении жизненного цикла программы. Требования проходят несколько стадий. Они могут быть "предложены" - в этом случае становится известна формулировка (содержание) требования, а также источник требования (откуда оно появилось - например, ссылка на протокол оперативного совещания). Второе состояние требования - "принято" - в этом случае считается, что требование должно быть реализовано. На этом этапе требование приобретает значение важности (критическая (без реализации этого критического требования проект может быть отменен), важная (существенное с точки зрения конкурентоспособности продукта), полезная (требование можно не включать в план разработки). Третье состояние - "включено" (для требования становится известно, кто отвечает за реализацию, сколько времени необходимо для выполнения, с какими другими требованиями оно связано, в какой версии программы (в какой день) реализация этого требования должна появиться). 

Не могли бы вы подсказать как лучше сделать это на UML. Особенно интересно, как разбить на классы эти требования и как отобразить то, что одно требование может быть связано с другими.
Заранее спасибо. (Я в этом деле новичок, постигаю все сама, поэтому если что не так подскажите)
...
Рейтинг: 0 / 0
18.03.2007, 15:14
    #34398589
NorthStar
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
UML(проектирование)
Вот моя диаграмма. Подскажите пожалуста правильно или нет я составила диаграмму. И так ли следует поступить с требованиями(или же не надо делать три класса, а сделать один?)
...
Рейтинг: 0 / 0
18.03.2007, 16:07
    #34398622
NorthStar
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
UML(проектирование)
Блин, подскажите пожалуста.Делать три класса или один, и соответственно три таблицы или одну?
И как показать это на диаграмме?
...
Рейтинг: 0 / 0
19.03.2007, 10:31
    #34399411
Shtock
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
UML(проектирование)
ПМСМ неправильно.Надо ввести класс Состояние требования,который будет учитывать фактор времени.По вашему же получается что иерархией наследования мы подменяем процесс смены состояний,т.е. в процессе жизни у вас объект идет вниз по дереву наследования.
...
Рейтинг: 0 / 0
23.03.2007, 14:15
    #34411690
Майевтик
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
UML(проектирование)
У вас неправильно используется отношение обобщения.

По определению, вышестоящий класс включает в себя все ниже стоящие. А у вас же получается, что в предложенные требования входят также принятые и "включённые".

Тогда уж изобразите один общий класс "Требование" с подклассами, где у каждого будет своё состояние - набор атрибутов. И используйте динамическую классификацию, чтобы объект менял свой класс в процессе жизни. Но это несколько вымучено.

Проще - сказать, что "предложенное требование" может породить (не в смысле наследования!) новый объект - "принятое требование", инициализировав его некоторыми атрибутами и связью с исходным требованием.
...
Рейтинг: 0 / 0
25.03.2007, 05:09
    #34413810
?
?
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
UML(проектирование)
Правильность - понятие растяжимое. А вот целесообразность такой диаграммы под большим вопросом.

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

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

Против выделения классов "источник", "программа" и "ответственное лицо" возраженй нет.

Про связи: тяните ассоциативную связь требование-требование, только уточните атрибуты связи, возможно появится еще один класс.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / UML(проектирование) / 6 сообщений из 6, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]