Сообщений в теме: 11

[Chuvi]

Привет всем
Интересует вот какой вопрос:
Использует ли кто-то для анализа, а может и для каких других полезных нужд, некие модели систем, например структурированные деревья объектов со свойствами и связями. А может модель в виде диаграмм с теми же свойствами и связями объектов.
Вобщем интересует все по этому поводу: используемое ПО, методы, насколько полезно и удобно.
Заранее спасибо :)

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

[rlabs]

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

Использовать ли для этого специальные инструменты, форматы, стандарты - дело вкуса и эффективности в конкретной команде.

[Chuvi]

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

[LeshaL]

Привет всем
Интересует вот какой вопрос:
Использует ли кто-то для анализа, а может и для каких других полезных нужд, некие модели систем, например структурированные деревья объектов со свойствами и связями. А может модель в виде диаграмм с теми же свойствами и связями объектов.
Вобщем интересует все по этому поводу: используемое ПО, методы, насколько полезно и удобно.
Заранее спасибо :)

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

Не знаю, поможет это вам или нет. Приведу такой пример из своего прошлого, когда я занимался автоматизацией тестирования. Задача была такая - есть UML tool, поддерживающий формат UML1.4. Надо убедиться, что это так. Иначе говоря, надо проверить, что на всех UML-ных диаграммах можно создавать только разрешенные элементы, линки можно проводить только между правильными source/destination, ну и что только разрешенные атрибуты можно проставить для диаграмм, элементов и связей.
Для решения задачи - создал метамодель UML1.4. Это был xml-файл. Потом самодельный тул, чер API продукта, на основе данных из этой метамодели, создавал диаграммы с элементами и линками и также раставлял атрибуты. Если у него получалось сделать что-то запрещенное или не получалось сделать что-то разрешенное - он рапортовал об ошибке.
На создание модели ушло больше недели, но сколько точно сейчас не вспомню. На поддержку такой модели никаких особых затрат не было, разве что по мелочи добавлялось и исправлялось

[Chuvi]

Не знаю, поможет это вам или нет. Приведу такой пример из своего прошлого, когда я занимался автоматизацией тестирования. Задача была такая - есть UML tool, поддерживающий формат UML1.4. Надо убедиться, что это так. Иначе говоря, надо проверить, что на всех UML-ных диаграммах можно создавать только разрешенные элементы, линки можно проводить только между правильными source/destination, ну и что только разрешенные атрибуты можно проставить для диаграмм, элементов и связей.
Для решения задачи - создал метамодель UML1.4. Это был xml-файл. Потом самодельный тул, чер API продукта, на основе данных из этой метамодели, создавал диаграммы с элементами и линками и также раставлял атрибуты. Если у него получалось сделать что-то запрещенное или не получалось сделать что-то разрешенное - он рапортовал об ошибке.
На создание модели ушло больше недели, но сколько точно сейчас не вспомню. На поддержку такой модели никаких особых затрат не было, разве что по мелочи добавлялось и исправлялось

Спасибо, довольно интересно :)

[rlabs]

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

Модель спецификации и модель живого продукта - две большие разницы. я так думаю.

[Mila]

Привет всем
Интересует вот какой вопрос:
Использует ли кто-то для анализа, а может и для каких других полезных нужд, некие модели систем, например структурированные деревья объектов со свойствами и связями. А может модель в виде диаграмм с теми же свойствами и связями объектов.
Вобщем интересует все по этому поводу: используемое ПО, методы, насколько полезно и удобно.
Заранее спасибо :)

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

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

Если ближе к тестированию, то можно проводить тестирование на уровне модели некоторых фич системы, которые не зависят от кода. Например, мы разрабатывали решение: по MSC диаграммам + еще кое-что, генерились тесты для "прозвона" всех абонентов для UML модели АТС, проверяя что все соединяются друг с другом правильно. Решение получилось более удобным, чем тестирование через готовый код.
Самим фактом наличия каких-то элементов и атрибутов можно проверять, что разработчики ничего не забыли, что объекты побывали в нужных состояниях и т.п. - может оказаться проще, чем проверять это через запуск системы.
И т.д. и т.п.

Что касается тулов, использующих визуальное моделирование: их много, и они могут различаться по идеологии и с вариантами на тему использования UML. ИМХО, тут так же как и с тулами для тестирования.

[LeshaL]

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

Модель спецификации и модель живого продукта - две большие разницы. я так думаю.

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

Вот другой пример вспомнился. Делали модель системы в UML, иначе говоря, Feature Tree. Правда UML использовался не как язык, а как графический редактор. Второе дерево - дерево тестов (точнее тестовая документация), с привязкой к дереву фич. Понятно, что листики деревьев имели связь многие-ко-многим. Т.е. одну фичу тестирует более одного теста, но и тест может тестировать более одной фичи. Кастомными атрибутами на диаграммах вносились статусы прохождения тестов и список дефектов, блокирующих тестирование. Легко получались репорты, где можно было просмотреть какие тесты были прогнаны и их статусы, и какие фичи были протестированы и их статусы (два view).

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

Оба дерева приходилось постоянно поддерживать в up-to-date состоянии, но на это много усилий не требовалось, хотя и были неудобные моменты. Собственно, все тестирование и было сбазировано на этом представлении. Да и разработка типа по FDD происходила, а как иначе если Peter Coad был CEO...

[rlabs]

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

Вот как поддерживать в актуальном состоянии такую модель, мне пока не очень понятно. Возможно, в случае применения MDD это делать проще, но MDD - сферическая очень штуковина.

[Chuvi]

Правда UML использовался не как язык, а как графический редактор.

Какой редактор использовали в этом случае? Очень интересна в этом плане древовидная модель

А если вообще не привязываться к UML? или не стоит изобретать велосипед в 101й раз?

[Stren]

использовал HP Quality Center, на выходе получил требования с првязанными к ним спеками, тесты с связями на покрытие требований, ну и как бонус частично автоматизировали регресс тестирование через QTP, результат понравлся всем , горжусь.

[riverraine]