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



Варианты использования сделаны некорректно.. Например, что это за вариант использования "Отображение измеренных значений в графическом виде"? ... Это цель пользователя? Или это функция системы?
« Последнее редактирование: 15 Июня 2008, 23:08:14 от Юрий Булуй »
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



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 ВИ? Есть подозрение, что тут будет только один ВИ.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



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



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

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

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

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

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



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



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

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

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



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

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

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

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

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

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



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



Поздравляю ;)
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



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

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

Название "формирование отчетности" скорее именует процесс, а не цель пользователя. Целью скорее всего будет именно "Получить отчет". Я как пользователь имею скромное желание получить таки отчет,  а не получить процесс формирования отчетности. А то, что я хочу его распечатать или сохранить в файл -- ну никак не является целью пользователя, это по Коберну -- subfunction в лучшем случае. Но я бы не стал выделять в данном случае отдельные UC по сохранению отчета и тп., т.к. это усложняет модель и не приносит никаких преимуществ. Можно сделать проще при той же информативности - вставить шаг о том, что пользователь в может сохранить отчет в файл или напечатать его ... и все.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19