Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Pavel_T

Страницы: « 1 2 3 4 5 »
46
Galogen, спасибо, но есть вопросы:

1. По действиям оператора: Разве нельзя свернуть 1-3 в один общий кейс?
2. По действиям администратора: Разве нельзя ввод данных, указанных в п.п. 1-3 свернуть в один общий кейс?

3. По ДК - не совсем понял.
В ДК мне нужно указать, те классы, которые содержат в себе данные, участвующие в системе тем или иным образом, а точнее по заданию написано "Разработать Диаграмму классов (в конечном итоге с указанием стереотипов классов, типов атрибутов, сигнатуры операций)

Скажем Классы: Извещение, Платеж (3 вида) или один общий, Архив, АРМ оператора (оператор, администратор можно не выделять как класс, можно выделить класс - "пользователь" с атрибутами "оператор" и "администратор"). Я верно понимаю?

PS. Кроме того, мне еще предстоит нарисовать 6 диаграмм :(



47
И все? больше Оператор никаким образом не будет использовать систему?

А что значит настроить АРМ оператора, как часто и сколько времени это занимает?
Что такое снять статистику? Какого рода статистика
 
ДК бывают концептуального уровня - т.е. бизнес-объекты, дале аналитическая ДК, далее проектная ДК, где появляются программные классы и т.д.

Оператор. Еще можно добавить расширение "Запрос данных (суммы) из архива"

ДК - вроде как преподаватель говорил, что изображаются классы данных.


48
Ой, опечатка:

3. Какого уровня? Не очень понял. Моя цель была перечислить на ДК все КЛАССЫ, присутствующих в постановке.

49
1. Диаграмма ВИ на самом деле мало понятна.
2. Начинать нужно с выделения действующих лиц и их целей в использовании системы
3. По ДК - это что за диаграмма? какого уровня? Не совсем ясно что такое класс АРМ, и класс Архив. Почему оператор - это граничный класс

1 и 2. Действующие лица: Клиент, Оператор, Администратор (согласно заданию других не вычитал).
Система будет установлена на АРМ Оператора, поэтому по сути Клиента можно не включать, поскольку он не действует никоим образом на Систему.
Цель Оператора - Оформить с помощью Системы платежи.
Цель Администратора - Настроить АРМ Оператора и снять статистику.

Где я ошибся? :(

3. Какого уровня? Не очень понял. Моя цель была перечислить все диаграммы классов, присутствующих в постановке.

Где ошибка? :(

50
Профессионалы, покритикуйте плиз :(

51
Господа, добрый день!

Грызу гранит науки и пытаюсь научиться анализу.

Имеется задание по разработке приложения, предназначенного для установки на АРМ оператора по приему коммунальных платежей.
Подробнее см. задание в 2-ух картинках.

Наваял две диаграммы Use Case и Class (тоже в картинках к сообщению).
Покритикуйте пожалуйста, что не верно, что верно и на правильном ли я пути.

Очень хочу научиться.

Спасибо.

52
Да является. Можно использовать 3 издание.
Также можно посмотрть Фаулера. Основы UML, также лучше заказать 3 издание. На books.ru pdf стоит 150 рублей

Нигде нельзя скачать свободно?

53
Добрый день!

Подскажите пожалуйста, какая существует на сегодня литература для начинающих (для чайников) по UML?
Чтобы простым и внятным языком, по делу (без размазываний) и желательно с примерами.

PS. Есть (была) такая книга "Освой самостоятельно UML за 24 часа" Шмуллера. Является ли эта книга тем, что я ищу?
Посоветуйте где можно достать или найти альтернативу?

Спасибо.

54
Зачем гадить в чужой топик?? ИМХО Ваш вопрос не имеет ничего общего с топиком, в который Вы его поместили.
Ну вот эта Д более информативная. Теперь надо назвать связи и расписать взаимодействие внутри связи.

Простите! Вы меня не поняли.
В моей диаграмме красным прямоугольником выделено два действующих "лица": 1 - Actor и 2 - наш черный ящик.
Все то, что находится дальше, включая двух пользователей (выделены в виде рисунков Actor - чисто условно) не должно нас волновать да и не волнует.

Мы только получаем сигналы от одной системы и шлем ей свои сигналы. А дальше - трава не расти!

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


55
Господа!

(из топика "Вариант использования или..." перейду сюда)

Вот, я попытался изобразить схему, в которую вплетена наша Система и действия которой (функции) необходимо описать в сценариях (или ВИ или еще каким то образом).



На рисунке NNNt - наша Система. NT - это единственный Actor видимый нашей системой.
Как видно, никаких пользователей нашей Системе не видно.

Ваши комментарии?  ???

56
GUI в ТЗ могут быть, а могут не быть. Ничего предосудительно в этом нет, это как Вам удобнее, мне с GUI удобнее.
Только GUI в этом случае должны быть вынесены в отдельный раздел (требования к экр. формам) и из ФТ должна быть просто ссылка на них.

Я всегда рассматривал ТЗ, как некое описание того, что "должно" (каким-либо образом) быть реализовано в Системе.
А "как это уже реализовано" (или "as is") - это уже был не ТЗ. Это уже был другой документ.
Так вот, готовые снимки экранных форм - это уже (по идее) - "as is".
Насколько правильно их размещать в ТЗ?

Поясните пожалуйста. Или я недопонимаю чего-то.

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

К примеру: "Система производит переотправку сообщений с интервалом отправки, заданным параметром "Таймер переотправки"".
То есть в примере указано уже конкретное название таймера. Насколько это правильно в ТЗ? Насколько правомерно?


57
замечания по потокам:
из п. 2 не понятно что Система находит Пользователя. Т.е. надо так и писать - Система находит зарегистрированного Пользователя по параметрам Запроса. А в 2.1. писать: "Система обнаружила, что Пользователь не зарегистрирован (отсутствует профайл абонента)."
в. п.3. можно написать исключение прямо в этом п., например, "Система проверяет наличие у Пользователя Услуги. Если Услуга не найдена, то сценарий продолжается. Если услуга найдена, то Системе формирует сообщение о наличии услуги у пользователя и сценарий завершается."

Спасибо.

То есть альтернативу засовываем в основной поток? Простите, а что тогда "спускать" в альтернативу? И в каких случаях?
Хочется понять... научиться.

58
2. Подвоха нет, просто не понял эту часть Вашего поста.

А... просто привел другую, отличающуюся от Вашего примера диаграмму.
Вы привели:



А я "натыкаюсь" на:





59
В вашем конкретном случае (когда идет один запрос) в Д я не вижу смысла.
Смысл, я полагаю, в том, что человек (разработчик, заказчик), читая пункт, с названием функционального требования "Подключение услуги X" глазом упирается в картинку, где видны участники процесса.

Простите, где натыкаетесь??
Повсюду, в интернете. А это не правильный пример? Или... в чем подвох?

...
Только GUI в этом случае должны быть вынесены в отдельный раздел (требования к экр. формам) и из ФТ должна быть просто ссылка на них.

Спасибо. В разделе "Функциональные требования" не стоит запихивать подразделом "Требования к GUI"? Это уже не есть "ФТ", правильно?

60
Да именно так. Исходящих судя по всему 2: из каждого альтернативного сценария + нужно ли в NT какое-то подтверждение слать или нет?

В некоторых случаях в NT возвращается ответ с ошибкой. А так, в основном от NT запросы идут (они же и активируют наши функции в Системе, чтобы она там сама ворочалась).

Диаграмма коммуникации - collaboration
Примеры в каждой диаграммы в атаче

Спасибо!
Итак, collaboration - она же "коммуникации", "она же контекстная", "она же Д взаимодействия". Я прав?

И я натыкаюсь вот на такие collaboration диаграммы:



И еще вопрос. В попавшемся мне ТЗ, по наследству, были обнаружены в приложении экранные снимки скриншотов, то есть, вроде как покрываются требования к GUI.
Для меня опять это не привычно (работал очень много с ГОСТ).
Подскажите пожалуйста, насколько правомерно размещать такую информацию сразу в ТЗ? Может стоит выныести в отдельный документ и существует ли такой?

Спасибо!

Цитировать
Очень совету посмотреть сюда: http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_19

Спасибо!
Заглянул. С английским пока туго, ибо "еще учусь". Точнее "перевожу со словарем" :(

Страницы: « 1 2 3 4 5 »