Здравствуйте!
Хотел бы у Вас попросить помощи или консультации по УМЛ. Сейчас заканчиваю дипломный проект, в котором одним из условий является наличие нескольких УМЛ диаграмм. Хотел бы попросить Вас помочь мне составить диаграмму классов. ДВИ я с помощью FAQ с вашего сайта составил, но не совсем уверен в ее правильности. Если Вам не сложно и есть немного времени - прошу помочь. Программа небольшая, по сути оболочка для БД с включением некоторых математических функций обработки данных. Сам программный код писать не нужно, нужно только проект.
Как работает программа: есть входящий ASCII файл, в котором записаны данные об измерениях в нескольких каналах измерения. Каналы делятся на несколько типов. Каждый канал расположен в одной скважине. В каждом канале может быть несколько датчиков. Принцип работы: текстовый файл попадает в парсер, который выбирает из него всю информацию. Далее, каждое значение одного канала проходит математическую обработку (фильтрация по значению, сравение по пределам). После этого данные заносятся в базу данных. Оператор должен просматривать даннные в т.н. текущем режиме (файл данных поступает каждые 10-15 сек.) на графике. Также, оператор может просматривать данные в ретроспективе, с помощью SQL запроса (и еще по нескольким критериям) выбираются данные за некоторый период времени и по номеру канала, а так же по типу измеренных данных. Все это выводится на график. Возможность экспорта и печати данных тоже предусмотрена. Я выложу схему БД, и свой вариант ДВИ. Если понадобятся еще какие-нибудь данные - пишите, дополню. Заранее спасибо за помощь.

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

1. Некоректно используется связь обощение. Слеудет использовать связь коммуникации - простая ассоциация - можно направленная.
2. Работа с базой данных - не может быть целью пользователя, а есть способ реализации достижения цели. Что конкретно делает оператор, далее Вы расписываете как связь включения как я понимаю поскольку иначе стрелки должны быть направлены в обратную сторону
3. Отображения данных в графическом виде - это функция системы, а не вариант использования системы.

Вариант использование - это то, что хочет получить оператор или системный администратор, потому он не хочет отобразить в графическом виде - а посмотреть некоторую отчетность или что-то иное

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

5. Насчет диаграммы классов, какая нужна? классов предметной области, классов программы?
Если первое назовите классы единствтенным числом - и преобразуйет БД в ДК предметной области

6. Если Вам нужны еще и классы программы, для каждого ВИ составьте по шаблону MVC диаграмму коммуникации или просто аналитическую модель VOPC (view only participiant classes) добавляя на каждый ВИ минимум одну форму и один контроллер по имени ВИ с суффиксом Manager Controller Handler и т.п. Возможно весь контроллер у вас будет размазан по событиям формы где функции контроллера по сути шаги ВИ.

Да и если можно по-русски пожалуйста диаграмму ВИ готовьте.

Большое спасибо всем за ответы. Исходя из ваших замечаний переработал свою ДВИ.

6. Если Вам нужны еще и классы программы, для каждого ВИ составьте по шаблону MVC диаграмму коммуникации или просто аналитическую модель VOPC (view only participiant classes) добавляя на каждый ВИ минимум одну форму и один контроллер по имени ВИ с суффиксом Manager Controller Handler и т.п. Возможно весь контроллер у вас будет размазан по событиям формы где функции контроллера по сути шаги ВИ.

Нужны именно классы программы. Порывшись в интернете нашел несколько ссылок по шаблону MVC. Для меня не совсем понятно, как его применить на моем примере. Т.е., насколько я понял, в этом шаблоне присутствуют только три класса, которые обмениваются между собой сообщениями. Причем классы всегда одни и те же (модель, представление, контроллер). Отличаться они должны атрибутами и методами от других ВИ, я правильно понимаю? Если можно, хотя бы небольшой пример, пожалуйста. Примеров в инете хватает, но они все из бизнес-области, не получается аналогий провести
По диаграмме VOPC почему-то нигде информации не нашел, даже на этом форуме.

Большое спасибо всем за ответы. Исходя из ваших замечаний переработал свою ДВИ.

1. Именовать юзкейсы следует отглагольными существительными, отражающими цель пользователя -- например,
"Просмотреть отчетность"
2. Не уверен, что имеет смысл выделять отдельно ВИ "Печать" и "Экспортировать данные". Это по-всей видимости опциональные шаги в ВИ "Получить отчет".
3. Чтобы правильно выделять ВИ имеет смысл попробовать описать предусловия и постусловия в ВИ и его основной сценарий -- тогда часто становится очевидным, корректен ли ВИ. ВИ это описание функциональности с т.з. пользователя.
4. Исходя из представленного в первом посте процесса работы с программой не понятно что делает пользователь в ВИ  "Контроль измеряемых значений" и "Управление процессом измерения". Каким образом пользователь управляет процессом? И как может влиять на процесс? И вообще, каков будет outmost ВИ? Есть подозрение, что тут будет только один ВИ.

Большое спасибо за ответ.

4. Исходя из представленного в первом посте процесса работы с программой не понятно что делает пользователь в ВИ  "Контроль измеряемых значений" и "Управление процессом измерения". Каким образом пользователь управляет процессом? И как может влиять на процесс?

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

И вообще, каков будет outmost ВИ? Есть подозрение, что тут будет только один ВИ.

Я прошу прощения, но что такое outmost ВИ? и почему вы считаете, что будет только один ВИ?

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

Насчет MVC - есть вариант использование - это не овальчик с мальчиком - а полнотекстовое описание сценария(иев) того как выполняется данное использование, как достигается или не достигается цель пользователя. Отсюда и танцуем, в описании ВИ вы придумываете (описываетет) порядок того, что должно быть сделано пользователем и системой (обычно в виде черного ящика) для удовлетворения этой самой цели.
Затем вы выполняете так называемую реализацию варианта использования, т.е. описываете какими классами и как будет достигаться эта самая функциональность, тут очень удобно предстваить вариант использования в виде системной диаграммы последовательности: пользователь - система (как черный ящик) и сообщения от пользователя к системем и наоборот согласно описанному сценарию: там будет видно КАКИЕ системные события и соответственно системные операции требуется реализовать, так вот MVC вам и поможет это представить.

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

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

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

Большое спасибо за ответ, буду пыхтеть

Именовать юзкейсы следует отглагольными существительными, отражающими цель пользователя -- например,
"Просмотреть отчетность"

Имхо авторское "Просмотр отчетности" близко к 'отглагольное существительное' ... хотя по мне, так лучше "Формирование отчетности" - а уж что в дальнейшем будет делать пользователь с отчетностью ... просмотрит или распечатает или сохранит в неком_фомате для импорта.

И импорт/экспорт у автора может быть вполне отдельная операция, не имеющая к  "Формирование отчетности" отношения.

Я думаю, Юра просто ошибся про отглагольные существительные, он видимо полагал использовать неопеределенную форму глагола, причем совершенную форму. Что сделать! Т.е. что должна сделать система по мнению пользователя.

У Лармана даются рекомендации по выбору ВИ:
одобрение руководства - нормально ли то, что будет пользователь делать в течение времени рабочего
элементарный бизнес-процесс - т.е. функциональная обязанность сотрудника
критерий размера - если мало шагов - то скорее всего это подфункция по Коберну.

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

Однако я бы не стал слишком упираться во все тонкости, навык придет с опытом. В данном случае просто нужно понимать это и идти к цели - семимильными шагами.

По сути ведь есть и разные уровни представления ВИ. Если Gutti, уже имеет программу и делает скажем так обратное проектирование, то можно просто на это посмотреть с точки зрения общего меню программы.

Хотя в данном конкретном случае как мне кажется было бы поще использовать традиционные списки требований

Большое спасибо всем за помощь! Сегодня защитился.

Поздравляю

Имхо авторское "Просмотр отчетности" близко к 'отглагольное существительное' ... хотя по мне, так лучше "Формирование отчетности" - а уж что в дальнейшем будет делать пользователь с отчетностью ... просмотрит или распечатает или сохранит в неком_фомате для импорта.

И импорт/экспорт у автора может быть вполне отдельная операция, не имеющая к  "Формирование отчетности" отношения.

Название "формирование отчетности" скорее именует процесс, а не цель пользователя. Целью скорее всего будет именно "Получить отчет". Я как пользователь имею скромное желание получить таки отчет,  а не получить процесс формирования отчетности. А то, что я хочу его распечатать или сохранить в файл -- ну никак не является целью пользователя, это по Коберну -- subfunction в лучшем случае. Но я бы не стал выделять в данном случае отдельные UC по сохранению отчета и тп., т.к. это усложняет модель и не приносит никаких преимуществ. Можно сделать проще при той же информативности - вставить шаг о том, что пользователь в может сохранить отчет в файл или напечатать его ... и все.