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

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

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

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

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

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

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

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

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


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