Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
У меня вот, например, 2 блога: личный (подседневная жизнь), профессиональный - события и высказывания, ссылки относительно профдеятельности.Павел, посмотрите как все реализовано у software-testing.ru. Мне кажется, можно что-то в подобном же ключе.
Сейчас вот думаю над вопросом агрегации блогов аналитиков.
Эд, а не получается ли при этом уже функциональная декомпозиция?Саша, не в данном случае. Здесь не декомпозиция, здесь группировка по определенным (например, по архитектурным признакам). Я согласен, может это не должно сразу появится в ТЗ, хотя а почему нет? В этом случае просто меняются углы зрения и высвечиваются некоторые темные местечки. Если ВИ считать не просто констатацией требований, но и синтетическими штучками, то почему нет?
Описав все СВИ относительно всех Пользователей вы и получите набор всех необходимых ФТ. Зачем еще дальше дробить на функции?
Any user or system or subsystem that interacts with your system is an actor.
And your system is an actor when it interacts with another system or subsystem.
That other system or subsystem you interact with is often termed a secondary actor.
Personally I don't like this secondary actor terminology as it leads to confusion.
It's just a system or subsystem you interact with to use it's functionality via it's use cases.
If a subsystem SubX-SD becomes an Actor, the system boundary has to be redefined and the new SD NSD will be different. The SubX-SD must be truly independent of the NSD. As said earlier "initiation" use case is not crucial. It can be taken up and resolved later, that is after Naming the Use Case and its Goal.John Watson
I wish to restate what you wrote: "in some cases SubX-SD can initiate some UC of the NSD ON BEHALF OF a previous Actor (PA) of the original SD. PA is NOT directly connected to the New SD and is NOT an Actor of NSD". I hope this is consistent with what you wrote & intended.
If the SubX-SD is truly a subsystem with some independent processing power / storage etc (NOT A mere TRANSMITTER OF INFRORMATION with or without amplification) then the connection between SubX-SD and the PA (now Actor of SubX- SD) is irrelevant to the context of the new SD. SubX-SD must deal with the PA as its Current Actor CA separately in a suitable way. The SubX-SD must have its own GOAL (it may be related to what CA asks SubX-SD) with ref to the new SD. This is the principle of system boundary and specific context for each subsystem of any system.
Within a SYSTEM BOOUNDARY of an SD, NO SubSystems of itself should be recognized and represented in the USE CASE DIAGRAM of SD. Accordingly it cannot be an actor of another External System ES which may be connected with SD . If a USE CASE DIAGRAM of the ES is drawn, then SD as a whole will be an Actor of ES which will now be THE SD.
If an Actor A is a mere TRANSMITTER he or she or it is NOT an Actor. The entity on the other end is the true Actor of the System Under Development.
Hello Edward,
I think that if Ivar Jacobson had English as his first language that Actors would have been called Interactors. An Actor (or Interactor)symbol on a Use Case diagram represents a role filled by anything outside the boundary of a system that interacts with that system.
Consider an Automatic Check-in Kiosk at an airport. A traveller (Actor) interacts with the Check-in Kiosk (System) in order to obtain their boarding pass and bagggage tags. To complete the process, The Check-in Kiosk System requests the Reservation System (Actor from the viewpoint of the Check-in Kiosk) to validate the Traveller's reservation details. In this context, Get Boarding Pass is a Use Case of the Check-in Kiosk initiated by the Traveller Actor. From the viewpoint of the Traveller the Check-in Kiosk is a system and the Reservation System is "invisible". From the viewpoint of the Check-in Kiosk, the Reservation System is an Actor. From the viewpoint of the Reservation System the Check-in System is an Actor.
If you would like a diagram and Use Case descriptions to illustrate the above, e-mail me.
For scope control purposes we choose to treat the Check-in System and Reservation Systems as separate entities. From the viewpoint of each system (or sub-system?) the other system is an Actor
Иначе будет бардак - кто в лес кто по дрова... Что уже и получилось в этой теме.А где ты увидел бардак?
Вообще, я очень советую каждому аналитику иметь на рабочем столе ссылку на RUP,А ссылку ?!
На данном этапе мне важно понять, будет ли это кому-то еще интересно. Если да, то выложим на wiki, организуем обсуждение, возможно - голосовалку, поскольку абсолютного консенсуса по некоторым терминам может и не быть.Ждем реакции других заинтересованных лиц. Сколько будем ждать?
Ну, нужно было автору показаться умным! Только практического значения это не имеет!Автор не только кажется умным, но и строит на этом свою полемику с оппонентами. Записывайтесь в Use Case Professionals.
How to properly reflect sequence of use cases in UML?
Hello to everyone.
My question is basically the following:
Use Case diagrams typically do not reflect sequential order of use cases in native UML. In my work I often need to provide development team with the high-level order of use cases reflected in the main set of use case diagrams.
Example: let's imagine that we have 5 CRUD Use Cases - 'View List Of Objects', 'View Object's Details', 'Delete Object', 'Create Object', 'Edit Object'. From the standpoint of sequence (and thus from the standpoint of navigation within the application) first comes 'View List Of'; after the list is displayed User is able to 'Create New', 'View Details' and 'Delete'; after performing 'View Details' User is able to 'Edit'.
There are some ways to do it which I'm aware of however I do not consider them as proper options:
1. Create a 'Sequencer Use Case' which includes all these Use Cases (e.g. 'Manage Objects'). But this will flood the diagram with UC's of different level of abstraction.
2. Use additional relationships such as ''Precedes' or 'Invokes'. But this will also flood the diagram heavily.
3. Use sequence and activities diagrams. However these diagrams are ususally used to reflect flow of a single use case and not the flow between use cases.
How do you solve this issue?
I think part of the answer is in how we frame the question. Rather than use the CRUD use case example that rarely has direct value to a user, let's consider a business suite like Microsoft Office with use cases Manage Document, Manage Spreadsheet, etc. These use cases each has a goal that matter to a user to use an artifact with paths to view, create, edit and delete it along with other connected use cases. Some, like delete, could be used by all manage use cases; others can only be used by a few because they are more narrow.
In real world usage, users create Word documents, then copy part to a PowerPoint and then change the wording, and then copy it back to the Word document, and then ... There are innumerable scenarios.
If you view use cases to be services, you do not have to worry about documenting them all. Sufficient sample scenarios that cover the services would be sufficient.
Sometimes there truly are overriding business reasons for specific order that are *always* true. In that case, I suggest that the whole scenario that delivers the business goal should be its own use case that describes all the steps in order - including other use cases, that can provide value outside this scenario, as appropriate.
Unfortunately, all too often, today's "always" is tomorrow's "what if we?" Preconditions then become a documentation, coding and testing problem. I have found it better for project sanity to treat use cases as services whenever possible.
In spite of common usage, use cases cannot have preconditions and be UML compliant. Please see http://www.building-requirements-consensus.com/preconditions.html for a detailed discussion.
+1.Павел, займетесь?
Я ранее предлагал создать либо RSS-поток блоггеров-аналитиков, либо хотя бы twitter-ленту, код которой можно легко встроить в страницу сайта.
