16

Системный Анализ и Требования / Re: Оформление дополнительных требований к исходному ТЗ

« : 06 Июля 2012, 18:36:54 »

А если все-таки есть требование оформляться документацию в соответствии со стандартом, то ГОСТ 34.602-89 в п. 1.7 говорит:

Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с … ».

17

UML SysML и пр. / Re: Вопросы по составлению диаграммы развертывания

« : 27 Июня 2012, 03:30:15 »

В Enterprise Architect, например, есть демонстрационный eap-файл. Одна из моделей - Deployment Model. Можно попробовать подсмотреть там.
В качестве примера, рассмотрен Internal Database Server (см. приложение).
По поводу "запускать, сохранять, искать...": это не совсем похоже на диаграмму развертывания. Больше на sequence. Хотя, для наглядности можно было бы на связи через слэш прописать все это, как с RunsOn на картинке. Но нужно ли это

18

Для всех / Re: Activity Diagram Разница между State и Activity

« : 04 Июня 2012, 01:04:08 »

Если переходы по сайту от окна к окну - диаграмма автомата. Без вопросов.

Почему без вопросов?
А чем плохо представление диаграммы деятельности в разрезе разделительных линий (swimlanes), где одна область соответствует "Пользователю", а другая - "Системе/Сайту". Пользователь инициирует нажатием на кнопку вызов какой-нибудь экранной формы, система отображает экранную форму. И т.д. в таком духе.

19

Для всех / Re: Модель обработки информации

« : 24 Мая 2012, 18:58:40 »

Можешь посмотреть здесь. Рассмотрено несколько примеров, один из которых - Activity Diagram.

20

Для всех / Re: Модель обработки информации

« : 22 Мая 2012, 19:16:31 »

Можно нарисовать и диаграмму деятельности (Activity Diagram). Затем к каждому шагу сценария притрассировать входной/выходной объект и действующее лицо. Для читабельности можно разбросать все это по отдельным разделительным линиям (swimlanes).

21

Для всех / Re: Вопрос новичка

« : 02 Мая 2012, 09:42:47 »

StarUML - всего лишь инструмент, поддерживающий моделирование в соответствии со стандартом UML.
Отсюда следует, что вы можете познакомиться с диаграммой классов (ДК), изучая спецификации OMG по UML и иную литературу.
Если нужно описать тулбокс с элементами, доступными для помещения на ДК, можно полистать User Guide от StarUML (страница 60 и далее - описание ДК и элементов).

22

Задачи студентов / Re: UseCase diagram. Правильно ли?

« : 17 Апреля 2012, 15:59:54 »

Практикуется ли вообще, такой подход?

Касательно документа - да.
Можно еще брать документ, ставить ему в соответствие класс и добавлять классу атрибуты, которые будут отражать структурные элементы исходного документа. Иногда я так делаю.

23

Sparx / Re: Работа с требованиями в ЕА

« : 27 Марта 2012, 18:53:30 »

Ну, например, такая стуктура:
|Наименование                                         |Релиз|Реализуемость|Источник            |Логическое обосноавние|
__________________________________________________________________________________________________
Необходима большая красная кнопка ОТВЕТ| 1.0    |Low               |Департамент ХХХ|Попросили                    |

Ваша структура и размещение элементов на диаграмме ясно, только Вы изначально хотели, кажется, добавить доп. свойства требованию
Ваша задача успешно реализуется (см. приложение) через добавление новых Tagged Values и выгрузку пакета с требованиями в CSV-файл с разделителем ";" для корректного прочтения в Excel.
Если структуру на диаграмме необходимо оставлять и не добавлять таги к требованию, то тогда следует либо воспользоваться запросами и их результаты экспортировать, либо смотреть в сторону API EA.

24

Sparx / Re: Работа с требованиями в ЕА

« : 27 Марта 2012, 11:47:48 »

Я видела такую возможность, если атрибуты забиты в одном объекте (требование).
А если это два объекта: само требование и еще объект с указанием источника требования. И они между собой связаны. И еще может быть несколько объектов, которые связаны с требованием. Можно все это вынести одной строчкой?

Правильно ли я понимаю, что Вы хотите

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

поместить в один атрибут требования, например, через запятую?
Если Вы хотите мониторить связи требования, то делайте SQL-запрос. Столбцами результата будет и требование, и все, что с ним связано.
Если нужно держать все это в одном атрибуте, то стандартными средствами EA этого не делал. Возможно будет необходимо написать Addin, который бы вызывался по клику в определенное контекстное меню требования, создавал таг и агрегировал в нем всю необходимую информацию.
Не исключаю возможности, что это можно решить и другими (стандартными) средствами EA.

25

Sparx / Re: Работа с требованиями в ЕА

« : 27 Марта 2012, 11:32:01 »

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

Для этих целей Вам придется использовать CSV Import/Export. Настраивайте т.н. "Спецификацию" выгрузки CSV и извлекайте в *.csv-файл, с которым можете работать через Excel.
Кроме того, если Вы будете использовать Tagged Value для фиксирования "Логического обоснования", то Вы сможете выгрузить его в этот самый CSV-отчет.
Если у Вас предполагается хранить значительный по объемам текст в создаваемом атрибуте элемента, то можно попробовать задать самостоятельно тип Tagged Value, т.е. Type=Memo. Ограничение на хранимую информацию в "таге" с типом Meme протестируйте сами

26

Sparx / Re: Работа с требованиями в ЕА

« : 27 Марта 2012, 11:21:29 »

Да, точно, этот метод лучше чем SQL (просто я уже привык на нем писать).

Я и сам частенько решаю задачи поиска SQL-запросом. Хорошо работает, но в более сложных задачах на селекцию.

27

Sparx / Re: Работа с требованиями в ЕА

« : 27 Марта 2012, 11:03:58 »

Добрый день!
По вопросу 1: Да, можно. Стандартный способ - Model Search. Добавьте в Bulder'e поиска необходимые фильтры (Phase, Author) и по кнопке Run извлекайте в окно просмотра ниже результаты.
По вопросу 2: В свойствах чего? Если Вы говорите о свойствах элемента, то для этих целей можно и нужно использовать Tagged Values, которые для этого и созданы.

28

Sparx / Re: Как убрать "префикс" к имени?

« : 26 Февраля 2012, 21:24:56 »

Так на диаграмме можно отображать FQN под элементом. Он не блокируется отключением FSON'а. Или этого недостаточно?

29

Sparx / Re: Вопрос по Relationship Matrix

« : 22 Февраля 2012, 14:24:55 »

...имеет довольно развитые инструменты автоматизации

Да, у EA богатые возможности в части Automation Interface (AI).

Кстати, частично решить вышеописанную задачу можно путем добавления, например, статуса тому коннектору, который связывает измененный класс и требование через API. Для этих целей можно написать небольшой скриптик. А вытягивать требования, которые нужно пересмотреть, можно через Model Search. В Model Search'е необходимо будет набросать запрос-выборку для отображения требований, которые находятся в End_Object_ID коннектора со статусом "Нужна ревизия" (как пример).

Все это, конечно, за пределами Relationship Matrix, о которой шла речь вначале темы

30

Sparx / Re: Вопрос по Relationship Matrix

« : 22 Февраля 2012, 11:30:45 »

Baseline переводят по-всякому.
Панель для работы с Baselines вызывается в EA нажатием комбинации CTRL+ALT+B.
Далее можно создавать, сравнивать и откатывать "снимки" проекта до ранее созданной Базовой линии, отслеживая внесенные в проект изменения.
Более подробную информацию можно найти в хэлпе EA.