К сожалению до сих пор остается неясным вопрос о сфере практического использования UML, но этот вопрос в данной теме оффтоп..
Лично мне не кажется, что это оффтоп, вопрос как раз уместный. По-моему, в данной теме налицо не вполне удачные попытки применить инструмент, который для выбранной цели не очень подходит. Неудобно запихивать шары в квадратные отверстия, вот мы и мучаемся.
Всякому овощу свое время. С легкой руки г-на Коберна варианты использования как техника описания требований стали настолько популярны, что некоторые аналитики стали считать их асболютно универсальным средством, которое
можно и нужно применять в
любой задаче, и именно с их помощью формулировать конечный набор требований к ПО.
Лично мне более близок подход
Вигерса, который указывает на то, что варианты использования имеют ограниченное применение. Они подходят как форма
промежуточного описания предметной области, когда аналитик только пытается ее как-то декомпозировать - выделяет акторов, их действия по отношению к системе и т.п. Дальше, по Вигерсу, аналитик с этими зарисовками идет к этим акторам, проговаривает с ними сценарии использования (вот тут от них и есть польза), а дальше -
ВИ умирают и на смену им приходят требования к ПО, которые аналитик выявил и сформулировал как результат обсуждения с пользователем. Этот подход к формулированию требований является распространенным, но неправильно было бы утверждать, что он является единственно возможным, т.е. что путь к требованиям ПО лежит
только через варианты использования. Более того, Вигерс указывает, что для некоторых классов систем (например, со сложными внутренними вычислениями) ВИ мало подходят для использования.
В Вашем кейсе я вижу следующее:
1) бизнес-процессы и алгоритмы работы системы на верхнем уровне Вами описаны;
2) взаимодействие конечных акторов (водители, клиенты) с системой Вы тоже описали, пусть и не в форме классических ВИ;
3) дальнейшее интервьюирование акторов для уточнения требований вряд ли имеет большой практический смысл - если только у Вас есть какие-то продвинутые водители и/или клиенты, с которыми Вы готовы обсудить эту идею - я бы выбрал обсуждать с ними прототип, а не ВИ;
4) основная "тяжесть" системы состоит во взаимодействии ее компонентов - Sphinks, Katrin, Asterisk, ГИС - при желании это взаимодействие можно расписать в виде ВИ, но, опять же, это не лучший, не единственный и не обязательный способ. Еще такой нюанс - если Вы используете эти системы как готовые/полуготовые, то с практической точки зрения Вы скорее пойдете от существующих интерфейсов к сценариям, нежели наоборот.
Таким образом, Вы можете продолжать попытки применить техники ВИ для описания данной системы; в учебных целях это, наверное, неплохо. Но с практической точки зрения я бы не стал на этом проект останавливать; есть все необходимое, чтобы двигаться дальше.
Система автоматизации диспетчерских и таксопарков