Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Gutti от 15 Июня 2008, 21:16:58
-
Здравствуйте!
Хотел бы у Вас попросить помощи или консультации по УМЛ. Сейчас заканчиваю дипломный проект, в котором одним из условий является наличие нескольких УМЛ диаграмм. Хотел бы попросить Вас помочь мне составить диаграмму классов. ДВИ я с помощью 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 по сохранению отчета и тп., т.к. это усложняет модель и не приносит никаких преимуществ. Можно сделать проще при той же информативности - вставить шаг о том, что пользователь в может сохранить отчет в файл или напечатать его ... и все.