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

×


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

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


Сообщения - Galogen

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »
1606
    А что, никто ArgoUML не пользуется ? Почему, если не секрет ?
Не нравится
Есть инструменты много лучше

1607
Гриша, я помню у нас была же лента внешних блогов и довольно удачно смотревшаяся. Может ее просто возродить? Или это нечто иное?

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

1609
Друзья, вот что обнаружилось по ходу.

В ряде книг, посвященных разработке ПО и UML от буржуйских коллег: Мацяшек, например. Обнаружил такие рассуждения:

"Прецеденты использования можно называть. ориентируясь на субъект или действующее лицо... Название П.И. с т.зр. действующих лиц не всегда рекомендуется. Легко понять, что их следует называть, занимая позицию внешних действующих лиц. Однако в этом случае труднее установить связь между прецедентами и моделями/артефактами, разработанными позднее, поскольку эти модели и артефакты тесно связаны с внутренним устройством субъектов и подсистем"

Мой уважаемый коллега Пушта из Индии в присланных мне для прочтения материалах пишет:
"ВИ - именованная служба (сервис) системы, которая, как ожидается, обеспечивает ДЛ или действующим лицам, играющим ту же роль, достижение определенной цели"
Далее идет Соглашение о именовании вариантов использования. Формулировки соглашения появились в ходе общения со студентами AMSSOI 2010 Batch:
1. Имя варианта использования относится всегда к систем, а НЕ ДЛ (выделено)
2. Используй глагол, выражающий службу (сервис), которую система выполняет (обеспечивает)
E.g Show contents (NOT View Contents), Present Welcome / Home Page, Give Options and Instructions (NOT SELECT OPTIONS), Receive Payment (Not “Payment”), Capture Decisions, Capture Recommendations, Deliver Cash (NOT Collect Cash), Read Card (NOT INSERT CARD) 
3. Используй префикс "Делать возможным" для действий исполняемых действующим лицом
E.g “Enable Registration / Log-in” or “Enable Payment” or “Enable Decision Making” or “Enable Recommendations” or “Enable Card Insertion”

Как я понимаю нет стандарта определяющего правила наименования ВИ, но есть хорошие и плохие практики.
Возникает вопрос: и тот и другой подход именований уместен . А каким образом Вы именуете свои варианты использования, какими правилами руководствуетесь и, если можно, почему

1610
Правильно я понимаю, что это будет именно коллективный "блог аналитиков", а не "блог об аналитике"? Я, например, про аналитику писал в блоге всего пару раз.

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

1611
Внешний вид ленты мне не нравится. Зачем повторять на каждой строке наш логотип? Все в рамках таблиц - вглядит несовременно и как-то стесняет. Мне кажется достаточно просто названия с возможностью перейти: название-ссылка или название + кнопка

1612
Эдуард, не проще ли дать коллегам ссылку на эту дисскуссию на Use Case Professionals, вместо того, что бы работать двунаправленным транслятором идей?
[поставил на предохранитель]
1. туда нужно записаться для начала
2. мы ее не ведем в группе, а лично по переписке

1613
базука и alex6565, последнее олимпийское. Здесь ведется обсуждение правил именования варианта использования. Озвучен взгляд иностарнных коллег, который привел меня в изумление. Я пытаюсь выяснить у своих отечественных коллег, а что они думают об этом. Ваша же дискуссия идет параллельно. Предлагаю сделать тему и вести дискуссию там, темы ваши могу туда перекинуть

1614
Мальчики и девочки,

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

1. синий - первая реплика Пушта
2. Темно-крансный мой ответ вопрос
3. зеленый вторая реплика в ответ на мой вопрос Пушта

Putcha: The Use Case Names are the "Names of Services" that "the System provides".  They are very short.  If we do not adopt a strict convention we would not know "with reference to what we are giving a particular name to Use Case".
 
If you name a use case "make payment" it is difficult to say who makes payment to whom?

 
Why? UC is a part of usage model. This model includes Actors: at least one External Entity (Primary Actor)   (who "makes payment " ) and SuD (whom makes payment ). This "whom" is customer (client) of SuD
 
Putcha:  There are two possibilities of payments.  Consider an Electronic Shop---the SuD here.  SuD buys Goods from Seller and in turn sells Goods to Buyers.  In this case both Buyers and Sellers are primary users (SuD is created to serve both of them).  SuD  1 receives payments  from Buyers and 2 makes payments to the Sellers later. Payments are involved in both the cases of 1 and 2.  They need to be distinguished.  One way is full expression as given at 1 and 2.  If you wish to use a short expression "receives payments" or "makes payments", they should be with ref to SuD in all cases.
 
Another example is BANK (real or electronic).  It (BANK) RECEIVES money and PAYS money.


Putcha: If the standard reference is the system, then it means that system makes payment to whoever (Actor) is connected to the Use Case.
Why again? Actor makes payment by means of SuD. Actor USES the system to make payment. "Make payment" is not an actor goal. Perhaps this goal is to have comfort conditions for a living
 
Putcha: Please consider End-to-End Transaction involving External Seller and External Buyer (Actors in this case). When a sale occurs, Buyer pays 1 to SuD and SuD pays 2 to Seller.  In case 1 Sud RECEIVES payment and in case 2, SuD MAKES payment.  That must be clearly indicated in the naming of use cases.  Here we are concerned with Use Case Goals ....not ultimate goals of people.

Putcha: If the Actor makes payment, then the system needs to receive the payment.  With reference to the system the use case name should be "Enable Payment" or "Receive Payment"...the use case Goal in both the cases is "Actor makes payment to the System and obtains receipt"
Я: Yes but it shall be the SYSTEM goal not the Actor. Actor doesn't want to receive or enable. To recieve or to enable is system responsibility I think.
 
Putcha:  In Use Case Diagram we have only Use Case Goals (there are no separate System Goals.  The System is there to enable Actors to Achieve their Use Case Goals).  It acts as an intermediary or medium between Buyer and Seller who are NOT directly connected.
 
With reference to SuD, "Receive Payment" means SuD Receives Payment from the associate Actor (Buyer here).  If the use Case Name is "Enable Payment", it means the SuD ENABLES the associated Actor  (Buyer here) to PAY.  If the Actor associated is Seller the use case name must change.  Here SuD "Makes Payment" to Seller.  Seller "Receives Payment" FROM SuD but Use Case here SHOUD NOT be named "Receive Payment" because the implied reference here is Seller (which is not correct).
My proposed convention is based on typical naming in banks.  When a bank says "Payment" it means "Bank pays".  "Receipts" means, "Bank receives".

 
Putcha:If Use Case Goals are fully written as Use Case Names, then there is NO NEED for any convention.
 
We arrived at this convention after seeing that a lot of students and professionals are utterly confused in interpreting the Use Case Names.  One can guess what is intended form commonsense but cannot infer from the Use Case Name.

 
Я: Could you explain me what kind of confusions  in interpreting the Use Case Names have a lot of students and professionals
 

Putcha: One example involving Buyer Seller is discussed above.  There are other such cases.  I will compile and send them to you.  Thank you.

1615
Эд, ты не мог бы уточнить у него, о каких именно ошибках идёт речь во фразе «We arrived at this convention after seeing that a lot of students and professionals are utterly confused in interpreting the Use Case Names»?

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

1616
Я в определенной степени выступаю от имени индийского коллеги и хочу пояснить его мнение (как мне кажется).
Он разделяет мнение, что ВИ выражает цель пользователя. Но он считает это сложным моментом, трудным для понимания. Это подчеркивается его последней фразой (последний абзац). И потому предлагает делать так, как предлагает он, потому что это более понятно (с его точки зрения из его личного опыта)

1617
Саша, Эдуард спасибо!
То, с чем был абсолютно согласен - поправил. По остальным моментам оставил комменты.
Александр, получили ли Вы от меня перевод моих букв?

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

Возьмем актора/роль Клиент (Patron). Что хочет получить клиент от использования системы?
Разместить заказа на питание (сделать заказ на обед). Зачем? Он хочет поесть в столовой, ресторане или другом общественном месте. Там реализована система электронного меню, которая должна была ускорить процесс обслуживания и дать больше возможности при выборе блюда. Потому чтобы добиться своей цели Пообедать, клиент использует нашу систему чтобы Разместить заказа.
Естественно мы пишим в требованиях нечто вроде: "Система должна Принимать заказы клиентов"

В результате наш индийский коллега в ходе своего жизненного и профессионального опыта делает вывод, что ВИ следует именовать в терминах сервиса. Но это сразу приводит нас к тому, что ВИ=функция (feature)

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

Что интересно в мировом сообществе тоже идут дискуссии. Общаясь с Putcha V. Narasimham я обнаружил, что он именует варианты использования с точки зрения системы. Т.е. вместо Посмотреть меню или Сделать заказ (для Клиента), он пишет Предоставить меню и Принять заказ. На мой вопрос: "Почему он поступает именно так?", получил ответ:

Цитировать
The Use Case Names are the "Names of Services" that "the System provides".  They are very short.  If we do not adopt a strict convention we would not know "with reference to what we are giving a particular name to Use Case".
 
If you name a use case "make payment" it is difficulty to say who makes payment to whom? 
 
If the standard reference is the system, then it means that system makes payment to whoever (Actor) is connected to the Use Case.
 
If the Actor makes payment, then the system needs to receive the payment.  With reference to the system the use case name should be "Enable Payment" or "Receive Payment"...the use case Goal in both the cases is "Actor makes payment to the System and obtains receipt"
 
My proposed convention is based on typical naming in banks.  When a bank says "Payment" it means "Bank pays".  "Receipts" means, "Bank receives".
 
If Use Case Goals are fully written as Use Case Names, then there is NO NEED for any convention.
 
We arrived at this convention after seeing that a lot of students and professionals are utterly confused in interpreting the Use Case Names.  One can guess what is intended form commonsense but cannot infer from the Use Case Name.

Во вложении таблица Акторов и  Вариантов использования в авторском оригинальном исполнении

Что вы думаете об этом? Какие аргументы за или против выскажите?

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »