Форум Сообщества Аналитиков
Общий раздел => Примеры => Задачи студентов => Тема начата: Vokist от 09 Января 2011, 03:17:10
-
Сделал курсовую работу по теме "Модернизация задачи «Учет библиотечного фонда» ИС библиотеки предприятия ".
Необходима критика работы.
-
Сделал курсовую работу по теме "Модернизация задачи «Учет библиотечного фонда» ИС библиотеки предприятия ".
Необходима критика работы.
Как дисциплина называется?
-
ПОИС скорее всего программное обеспечение информационных систем
-
Одной из типичных ошибок является стремление отобразить на одной диаграмме все свои знания об исследуемой области. Диаграмма прецедентов на рис. 2.1 - наглядный пример.
С точки зрения эргономики, диаграмма нечитабельна.
Некоторые из прецедентов включения являются, скорее, элементарными действиями внутри включающего прецедента, и эти действия не являются существенными (достоиными выделения в самостоятельный модуль).
Критерий для выделения: основной (расширяемый) прецедент является работоспособным, полезным и может ограниченно использоваться без этой функциональности.
С другой стороны, некоторые прецеденты такие расплывшиеся, что они не будут выполняться целиком в одном сеансе взаимодействия субъекта (актера) с системой.
Совет (из RUPа):
- В модели прецедентов создайте пакеты UML для помещения прецедентов одной функциональной области, и назовите их как прецеденты верхнего уровня. У Вас будет три таких пакета. В описании пакетов коротко опишите их назначение (фактически - повторение ваших длинных названий прецедентов). Перетащите в эти пакеты прецеденты, расширяющие соответствующие прецеденты верхнего уроня. Сами прецеденты верхнего уровня удалите из модели: это не use case!
- Удалите все прецеденты расширения, которые не являются таковыми. Сохраните только те, которые Вы действительно будете реализовывать как отдельные модули, т.е действительно будете расширять функциональности расширяемых прецедентов. Проверьте, xто в описании каждого прецедента кратко описана его функциональность. Например: "Формирование справочника "Тип литературы" должно включать следующие возможности: добавление нового типа, изменение типа, удаление типа)".
- В каждом пакете функциональной области нарисуйте свою маленькую диаграмму прецедентов "Прецеденты функциональной области..."
- Пересмотрите свое отношение к субъектам. Вместо одного появятся много, выполняющих прецеденты, соответствующие их ролям в библиотеке.
Диаграмма деятельности должна описывать последовательность взаимодействий для каждого прецедента в отдельност!
При этом Вы сможете обнаружить общие действия, полностью совпадающие в различных диаграммах деятельности, а значит - в прецедентах. Эти фрагменты - кандидаты в прецеденты включения. Если хватит духу - создайте в модели пакет "Прецеденты включения" и опишите там соответствующие фрагменты как абстрактные прецеденты включения (с диаграммами деятельности).
После этого:
- перетащите каждый включаемый прецедент на диаграммы, в которых есть прецеденты, которые его включают и установите соответствующую связь
- соответствующие фрагменты в диаграммах деятельности основных прецедентов могут быть заменены узлами "вызываемая операция".
На диаграмме классов:
- укажите множественности
- подумайте о типах ассоциаций
- название класса "Экземпляр" плохое, наталкивает на мысль, что Вы не знаете, что такое в UML спецификация экземпляра.
По диаграммам компонентов - без комментариев (см. замечание № 1)
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru
-
Дисциплина называется Проектирование организационных информационных систем
-
Некоторые из прецедентов включения являются, скорее, элементарными действиями внутри включающего прецедента, и эти действия не являются существенными (достоиными выделения в самостоятельный модуль).
Согласно программе у меня получается следующее:
есть главная форма->на ней есть кнопка "Отчеты"(нажав на неё открывается выпадающее меню
с элементами выбора: Инвентарная книга, три разных документа КСУБФ, а также Акт прихода и Акт пожертвования).
Пользователь может выбрать один из документов.
Напр. при выборе Инвентарная книга -> появиться автоматически форма с вопросом "Выбирите партию книг"->
если пользователь выбрал партию, нажал ОК -> появится форма Инвентарная книга (на форме есть кнопки Сохранить
документ в формате, печать документа и т.д.) в виде уже автоматически сгенерированнного документа
"Инвентарная книга".
При выборе любого из отчетов автоматически появляется соответствующая форма, а потом форма с самим отчетом.
-
Модель прецедентов (диаграмма прецедентов и диаграмма деятельности) предназначены для документирования требований к будущей системе, а не для описания ее устройства.
Прецедент описывает набор последовательностей взаимодействий (удачных и неудачных), которые инициируются субъектом для достижения его цели. Название прецедента отражает эту цель.
Те действия, которые Вы описали, выполняются всеми актерами во всех прецедентах.
Можно спокойно создать абстрактный прецедент "Вход в систему", а дальше включить его во все прецеденты, а на диаграмме деятельности обозначить одним действием.
Субъектов и прецеденты придумали для того, чтобы облегчить работу (уменьшить сложность) путем ее декомпозиции. Ваш же подход предполагает создание единственного прецедента для систем любой сложности, т.к. в любом случае выполнение любой задачи на компьютере начинается со вставления вилки в розетку.
А вообще, когда программа уже сделана, диаграммы UML рисовать поздно!
-
Удалите все прецеденты расширения, которые не являются таковыми. Сохраните только те, которые Вы
действительно будете реализовывать как отдельные модули, т.е действительно будете расширять функциональности
расширяемых прецедентов.
У меня программа уже написана. На главной форме есть три кнопки:Справочники(в них содержутся
данные необходимые для формирования отчетов), Отчеты(их 6) и Библиотечный фонд. При нажатии на кнопку "Справочники"
появится выпадающее меню с элементами выбора, которые изображены на диаграмме прецедентов как расширения для базового
прецедента "Формирование справочников".Проблема в том что формы справочников однообразны и кнопки на них одни и теже
Сохранить, Изменить, Удалить. Попытаюсь их скомпоновать по совету
Совет (из RUPа):
- В модели прецедентов создайте пакеты UML для помещения прецедентов одной функциональной области, и назовите
их как прецеденты верхнего уровня. У Вас будет три таких пакета. В описании пакетов коротко опишите их назначение
(фактически - повторение ваших длинных названий прецедентов). Перетащите в эти пакеты прецеденты, расширяющие
соответствующие прецеденты верхнего уроня. Сами прецеденты верхнего уровня удалите из модели: это не use case!
-
Успехов!
-
Успехов!
Спасибо
-
Могу я еще дать рекомендации и некоторую критику?
Ну вопрос, конечно, риторический.
Для начала по стилистике работы.
Под функциональной задачей «Индивидуальный учёт» понимается учет каждого конкретного экземпляра документа и каждого названия документа, поступающего в фонд библиотеки или выбывающего из него.
ИНДИВИДУА'ЛЬНЫЙ, ая, ое; -лен, льна, льно [от латин. individuus — неделимый].
1. Отличный от других, свойственный данному индивидууму, личный (книжн.). Индивидуальные особенности учеников. || Отличительный, своеобразный (разг.). Индивидуальное качество этих часов. 2. Единоличный, производимый одним лицом (офиц.). Индивидуальное хозяйство. Индивидуальное требование. 3. Распространяющийся на каждого в отдельности, относящийся в отдельности к каждому (нов.). Индивидуальное кредитование. Индивидуальное обслуживание. 4. Предназначенный для одного человека, новый для каждого другого (спец.). Индивидуальная кисточка для бритья.
На лицо не верное использование слово индивидуальный. Нужно придумать другой термин. Кроме того имеется логическое нарушение. индивидуальный учёт библиотечного фонда
и учет каждого конкретного экземпляра документа
и При списании документов выполняется внесение данных согласно документу «Список книг»
. Что же все-таки является предметом учета? Документ или книга?
По диаграмме использования уже было сказано ранее, повторяться не буду. Только все-таки такую диаграмму следует называть именно Диаграмма использования, а элементы использования - вариантами (способами) использования, а не прецедентами. Прецедент - не верный перевод с английского, исходное сочетание было usage case
По диаграмме классов и словарю классов. Класс - это сущность, абстракция, таксоном, архетип. Он отображает характеристики сходных по свойствам сущностей, а потому именуется единственным числом. Множественное число обычно используют для наименования таблиц - одним из способов хранения конкретных сущностей. Таблица - множество экземпляров одной сущности. Но сущность она одна.
Рассмотрим некоторые классы
Класс Книга (или как в оригинале Книги) - вновь семантический разрыв (см. выше). Почему есть операции только для внесения различных значений атрибутов, а нет операций чтения? В то же время область видимости private,
Класс Авторы - почему атрибут этого класса имеет тип того же самого класса? Довольно знаете ли странно
Реализация прецедента «Формирование библиотечного фонда» возможна тремя поведенческими аспектами:
Выбор кнопки Каталог книг, Каталог экземпляров книг или Выход.
При открытии формы Каталог книг (см.описание диаграммы классов) главная форма остается открытой и возможен возврат к главной форме без закрытия формы Каталог книг.
Это не реализация - а описание того, как может действовать пользователь. Реализация должна описывать, как достигается исполнение варианта использования, и она достигается текстовым описанием, изображением сценариев последовательности, изображением диаграммами деятельности или диаграммами автоматов. У Вас же описывается конкретное действие - открыть Каталог книг
Диаграмма последовательности для прецендента «Формирование «Инвентарной книги»» - к сожалению совершенно не то, что Вы пытаетесь передать
Диаграмма компонентов - попытка есть, но она не удалась. Вы пытаетесь применить шаблон Слой - это плюс, но компоненты переданы совершенно не корректно - это минус
-
Что же все-таки является предметом учета? Документ или книга?
Документ – информация, зафиксированная в виде текста(книги, журналы), звукозаписи, изображения или их сочетания, библиографически идентифицируемая, предназначенная для передачи во времени и пространстве.Документами в библиотеке являются книги, журналы и т.д. Согласен с замечанием исправлю. Тогда предметом учета является книга, а документами являются Инвентарная книга и др.
-
Документ – информация, зафиксированная в виде текста(книги, журналы), звукозаписи, изображения или их сочетания, библиографически идентифицируемая, предназначенная для передачи во времени и пространстве.Документами в библиотеке являются книги, журналы и т.д. Согласен с замечанием исправлю. Тогда предметом учета является книга, а документами являются Инвентарная книга и др.
Хм, интересно. Документ (http://slovari.yandex.ru/документ/БСЭ/Документ/) - ... По содержанию Д. делятся на научно-технические (статьи, книги, патенты, технические отчёты и описания), правовые (постановления, указы, договоры и др.), управленческие (приказы, директивы) и др...
Вроде бы получается, что книгу можно считать документом. Но мне кажется, все-таки не любую книгу. Даже если полагать, что книга - это документ (исходя из определения), то можно ли считать изданный научно-фантастический роман книгой?
Все-таки видимо, Вам следует принять какое-то решение. По-моему, документ следует отличать от книги. Также как и библиотеку от архива. Архив документов и библиотека книг звучит правильнее, чем архив книг и библиотека документов
На каждый экземпляр книги, конечно, имеется формуляр - это уже документ. У каждого выпуска (издания) есть общее описание, характеризующее тираж. Вероятно, это описание - тоже документ. Правда, если в Вашей библиотеке хранятся только по сути уникальные документы, то видимо особой разницы нет. Но тогда следует различать документы учета, документы описания и т.п
-
Под функциональной задачей «Индивидуальный учёт» понимается учет каждого конкретного экземпляра документа и каждого названия документа, поступающего в фонд библиотеки или выбывающего из него.
Правильно так
Под функциональной задачей «Индивидуальный учёт» понимается учет каждого конкретного экземпляра книги и каждого названия книги, поступающего в фонд библиотеки или выбывающего из него.
-
Диаграмма прецедентов по совету
Цитата: lnew от Сегодня в 03:21:07 pm
Совет (из RUPа):
- В модели прецедентов создайте пакеты UML для помещения прецедентов одной функциональной области, и назовите
их как прецеденты верхнего уровня. У Вас будет три таких пакета. В описании пакетов коротко опишите их назначение
(фактически - повторение ваших длинных названий прецедентов). Перетащите в эти пакеты прецеденты, расширяющие
соответствующие прецеденты верхнего уроня. Сами прецеденты верхнего уровня удалите из модели: это не use case!
- Удалите все прецеденты расширения, которые не являются таковыми. Сохраните только те, которые Вы действительно будете реализовывать как отдельные модули, т.е действительно будете расширять функциональности расширяемых прецедентов. Проверьте, xто в описании каждого прецедента кратко описана его функциональность. Например: "Формирование справочника "Тип литературы" должно включать следующие возможности: добавление нового типа, изменение типа, удаление типа)".
- В каждом пакете функциональной области нарисуйте свою маленькую диаграмму прецедентов "Прецеденты функциональной области..."
- Пересмотрите свое отношение к субъектам. Вместо одного появятся много, выполняющих прецеденты, соответствующие их ролям в библиотеке.
-
В самой инструкции также дается другое понятие дифференцированный. Я думаю составители инструкции ошиблись с выбором термина.
Индивидуальный, идет от индивидуала
ИНДИВИДУА'Л, а, м. (нов. газет.).
Лицо, выполняющее индивидуально, единолично какую-н. работу, в противоп. лицам, работающим группой, коллективом. Заочным обучением в нашем городе охвачено шесть групп, индивидуалов имеется 129 человек (из газет).
Индивидуальный (персонифицированный) учет.
Организация и ведение учета сведений о каждом застрахованном лице для целей государственного пенсионного страхования; федеральный закон от 01.04.1996 N 27-ФЗ "Об индивидуальном (персонифицированном) учете в системе государственного пенсионного страхования"
-
По диаграмме классов и словарю классов. Класс - это сущность, абстракция, таксоном, архетип. Он отображает характеристики сходных по свойствам сущностей, а потому именуется единственным числом. Множественное число обычно используют для наименования таблиц - одним из способов хранения конкретных сущностей. Таблица - множество экземпляров одной сущности. Но сущность она одна.
Класс Авторы - почему атрибут этого класса имеет тип того же самого класса? Довольно знаете ли странно
Исправил.По диаграмме классов у меня есть проблемы с определением связей, логика их использования. Построение диаграммы классов или с точки зрения предметной области или программной реализации. Основы есть, но иногда путаюсь.Изучал http://library.mnwhost.ru/doc/UML_HTM/gl_08.htm
Диаграмма последовательности для прецендента «Формирование «Инвентарной книги»» - к сожалению совершенно не то, что Вы пытаетесь передать
Диаграмма компонентов - попытка есть, но она не удалась. Вы пытаетесь применить шаблон Слой - это плюс, но компоненты переданы совершенно не корректно - это минус
Постараюсь переделать.Возможно их надо сократить.
-
Спасибо за помощь
-
По диаграмме классов у меня есть проблемы с определением связей, логика их использования. Построение диаграммы классов или с точки зрения предметной области или программной реализации.
Представленная диаграмма, скорей похожа на предметную область, хотя содержит и программную реализацию. Это правда зависит от типа архитектуры приложения и способа его реализации.
А какие проблемы с типом связи у вас имеются?
Между сущностями возможны:
-ассоциации (в реализации чаще всего агрегации или композиции). Это связи принадлежности, если проводить аналогию с базами данных, или связи типа has-a. Эти связи следует применять при отношении часть-целое, либо сводящиеся к оной
-обобщения - связи типа is-a, что-то есть тоже самое что и другое, но имеющее что-то свое дополнительно, у вас кстати их практически нет
-зависимости - когда составляющая класса зависит (использует) другой класс или его составляющую. Например, является параметром операции класса, или входит в состав реализации такой операции
В любом случае связь показывает некоторое отношение. В ДК предметной области часто двунаправленое, в реальной реализации скорее однонаправленное, интерпретируемое как отношение между клиентом и сервером, т.е. нечто предоставляющее услуги не должно знать ничего о том кому оно его предоставляет и наоборот
-
В предыдущей работе мне надо было написать программу для реализации задачи "Учет библиотечного фонда".
Задача "Учет библиотечного фонда" разбивалась на подзадачи
- суммарный учёт библиотечного фонда( формирование документов «Книга суммарного учета библиотечного фонда(Поступление в фонд)»,
«Книга суммарного учета библиотечного фонд(Выбытие из фонда)»,«Книга суммарного учета библиотечного фонд(Итоги движения фонда».
– индивидуальный учёт библиотечного фонда(формирование документа "Инвентарная книга").
В данной курсовой работе стоит задача построить 6 диаграмм для прошлой курсовой с учетом описания новой задачи
–учет балансовой стоимости библиотечного фонда(формирование документов«Акт прихода», «Акт списання», а также «Акт пожертвования»)
в рамках задачи "Учет библиотечного фонда". Программа у меня реализована так:
Данные хранятся в таблицах БД MySQL.
Проект программы представлен 3-мя пакетами:
1)Вспомагательные классы (отдельный пакет Tools)
2)Классы реализации форм (Library).
3)пакет Report(вспомагательные классы и xml файлы)
4)библиотеки(jasperreports и др.)
Исполняемый файл Library.jar
Моя проблема состоит в том, что у меня есть готовая программа почти на 90%, в которой реализована определенная логика и алгоритмы решения задачи.
Сейчас мне надо построить диаграммы.Напр. диаграмму классов.Классы в программе у меня одни, а по предметной области другие.В программной реализации
у меня классы связаны с формами напр. класс Form_Book,Form_Login и т.д.
Я решил строить диаграмму классов отталкиваясь от сущ-щей программы с учетом понятий предметной области (т.е.это уже как разработка совершенно
новой программы).
Возможно лучше ДК строить просто отталкиваясь от предметной области, но у меня есть проблемы со связями зависимости,
а также с модификаторами доступа и как от них зависит применение той или иной связи(напр.агрегация) и определением операций,
которые дожны быть реализованы в данном классе.
Также есть проблема с выбором классов для задачи "Учет библиотечного фонда".
У меня есть определенные проблемы со здоровьем и нет возможности у кого-т спросить очно,
можете ли подсказать какую-то литературу для прочтения.Моя задача состоит в построении диаграммы классов и других для задачи
"Учет библиотечного фонда", точно как их построить с учетом готового у меня материала я не знаю, потому попытаюсь следуя Вашим советам
построить их с нуля или возможно просто подкорректировать уже имеющиеся диаграммы.
-
Диаграмма классов
-
Диаграмма классов: изменены названия классов.Попытаюсь исправить:
Класс Книга (или как в оригинале Книги) - вновь семантический разрыв (см. выше).
Почему есть операции только для внесения различных значений атрибутов, а нет операций чтения? В то же время область видимости private,
-
Думаю, это не то, о чем мечтали большевики!
Напишу утром, сейчас уже поздновато!
-
Вернемся к диаграмме прецедентов.
О диаграммах UML вообще.
В отличие от многих других нотаций моделирования, диаграмма UML - это не просто картинка, а графическое представление модели системы с определенной точки зрения. Причем, с этой точки зрения может быть и не видна вся система, а только та часть ее, на которой автор диаграммы хочет акцентировать внимание.
Система может описываться множеством диаграмм одного вида (прецедентов, классов и т.д.), каждая из них содержит только те элементы (сущности и отношения), которые иллюстрируют какую-то мысль автора.
Одни и те же модельнве элементы (прецеденты, классы и т.д.) могут присутствовать на множестве диаграмм, причем, даже разных типов.
Именно набор модельных элементов и их определений (в том числе, текстовых описаний) и представляет модель. Диаграммы же - это всего лишь иллюстрации и средство графического интерфейса с моделью.
Каждая диаграмма UML графически иллюстрирует определенный аспект системы.
Например, RUP рекомендует использовать диаграммы прецедентов в следующих случаях:
- обзор главных функций системы (только те субъекты и прецеденты, которые определяют "лицо" системы, т.н. "архитектурно существенные")
- субъект и все его прецеденты (используются, например, для проектирования прав доступа)
- прецедент и его контекст (субъекты и абстрактные прецеденты включения и расширения, используются, например, для проектирования интерфейсов)
Вы, Vokist, пытаетесь нарисовать одну диаграмму прецедентов для всей системы.
Даже для Вашей маленькой системы она не помещается на листе бумаги. А если это будет большая система.
А как быть с системой, которая содержит сотни прецедентов? Выход - в структуризации.
В UML имеется специальный элемент для структуризации - пакет. Он используется для группировки модельных элементов по какому-то признаку.
В моделях прецедентов пакеты часто используются для группировки прецедентов по функциональному признаку. Т.е. пакет представляет некоторую функциональную область. Пакеты могут быть вложенными, если прецедентов очень много или нужна более глубокая классификация.
Функциональная област (пакет) - это "ящик", в котором лежат прецеденты или другие пакеты.
На вашей диаграмме есть три пакета с именем "Прецедент верхнего уровня". Это название недопустимо! Это не прецедент! Нет прецедента "Формирование библиотечного фонда"! Есть несколько (два) прецедента, которые выполняет Ведущий библиотекарь для формирования библиотечного фонда.
Я не работал с Вашим инструментом. Но предполагаю, что он имеет некий каталог в виде дерева модельных элементов и поле для диаграмм. Если это так, Ваш каталог может выглядеть примерно следующим образом:
<название проекта>
<модель прецедентов>
<пакет, содержащий субъектов>
...
<диаграмма прецедентов> Субъекты системы
<пакет, содержащий прецеденты 1-й функциональной области, например:> Формирование библиотечного фонда
<прецедент, например:> Формирование каталога книг
<прецедент расширения, если есть>
<другой прецедент расширения>
<диаграмма прецедентов> Контекст прецедента ...
<...> Формирование каталога экземпляров (про это название я уже писал!)
<диаграмма прецедентов с названием> Прецеденты функциональной области "Формирование библиотечного фонда"
<пакет 2-й области>
...
<пакет третьей области>
...
<проектная модель>
...
Получилось не очень красиво, и не знаю, понятно ли.
Еще об абстрактных прецедентах.
- Прецедент расширения не может расширять более одного прецедента! Общие части нескольких прецедентов должны определяться как прецеденты включения.
О прецедентах вообще.
- Прецедент, если это не абстрактный прецедент, должен иметь субъекта, цель которого он выполняет (некоторые инструменты позворяют определять для элементов ключевые слова, если у вас позволяет, то ассоциации субъект-прецедент нужно назначить ключевое слово primary.
У Вас есть прецеденты без субъектов!
Дорогой Vokist!
Любые усилия должны быть оптимальными для достижения поставленной цели.
Если Вы собираетесь стать системным аналитиком или проектировщиком, Вам стоит почитать книжки, попрактиковаться и т.д. Думаю, участники форума, и я в том числе, с удовольствием Вам помогут в достижении этой благородной цели!
В принципе, задачка для такой учебы подходит, и если ее довести до ума, она могла бы стать хорошим пособием. Тем более, можно проследить весь цикл, от требований до развертывания продукта.
Если же у Вас утилитарная цель сдать курсовик, не напрягайтес! Трояк, я думаю, Вам гарантирован.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru
-
Vokist, уважаемый lnew подробно пытается объяснить Вам ситуацию с диаграммами использования.
Я буду копать в стороны структурных диаграмм и возможно поведенческих.
Вслед за lnew, я также хочу сказать, что нельзя описать сколь-нибудь сложную систему единственной диаграммой. Не думаю что стоит такая цель, даже если в рекомендациях к заданию говорится, что построить 6 диаграмм, то все равно это не самоцель...
Диаграммы классов, как Вы наверняка знаете, отражают статическую структуру вашей программы. При моделировании будущего приложения Вы используете какой-то шаблон. Это похвально я думаю, но в шаблонах всегда скрыты определенные принципы, задача которых обеспечить выполнения определенных задач оптимальным способом и гарантировать некоторое качество, решение проблемы.
Ваша задача - учебная и скорее всего не будет претендовать на решение всех нюансов и потребностей, тем более они Вам наверняка все неизвестны, и более того, Вы их допридумываете, как Вам выгодно.
Как Вы понимаете, решение задачи определяется и внешними обстоятельствами. Если бы Вы делали проект за деньги, работая с нормальным заказчиком и думая о перспективах, то очевидно помимо чисто функциональных требованиях, у Вас проявлялись бы и такие требования как удобство использования (практичность), модифицируемость, сопровождаемость, масштабируемость, производительность, контролепригодность, стоимость и т.п.
Однако ситуация у Вас совершенно иная, скорее от вас требуют продемонстрировать некоторый уровень знаний, умений и навыков, общий уровень компетенции, который предполагают Ваши преподаватели. Потому я не соглашусь с уважаемым lnew, что трояк Вам гарантирован. Почему так мало, я бы рассчитывал на гораздо большую оценку :)
Тем не менее, исходя из выше предположенного, модель Вашего решения может быть самой разнообразной и она вполне может быть правильной... Однако исходя из соображений профессионального характера, следует понять, что при построении диаграмм классов, нужно действовать аналогичным способом, который предложил lnew.
1. отталкиваться от варианта использования
2. разворачивать вариант использования последовательно или параллельно, осуществляя анализ и разработку структурных, поведенческих диаграмм и диаграмм взаимодействия. В том же RUP существует рекомендация делить все класс на три группы: граничные, т.е. которые отвечают за взаимодействие с внешними системами (актерами), управляющими, отвечающими за бизнес-логику, сервисы и т.п., сущностные - по сути отражающие важные предметные классы и отвечающие за сохранение информации.
3. для каждого варианта использования можно построить как минимум одну диаграмму VOPC (view only participiant classes), добавляя туда вначале на каждую ассоциацию варианта использования с внешними субъектами по одному граничному классу и на каждый вариант использования по одному управляющему классу + все, участвующие в реализации ВИ предметные классы. При этом можно следовать также такому правилу. Действующее лицо - актер(внешняя система) может распадаться на две сущности: класс предметной области для перзистентного (постоянного) хранения важной для ПрОбл инофрмации (например библиотекарь, оформивший поступление книг) + класс управляющий, который в программном виде реализует часть функций конкретного актера (того же библиотекаря)
4. естественно в записке Вы отразите конечную диаграмму, а не всю ее эволюцию от момента зарождения идеи решения до его конкретного воплощения, главное что ваша модель будет меняться в зависимости от ваших рассуждений и изменений в других моделях. Ясно что на появление ПРОГРАММНЫХ будет оказывать влияние и выполнение принципов проектирования объектных программ, в частности принципов распределения ответственности, отделения представления от модели, принципы низкого связывания и высокого зацепления, принципы повторного использования кода
Кстати, если у Вас уже есть программная реализация, попробуйте выполнить обратный инжиниринг. Вы получите некоторую модель своего приложения
-
Спасибо за помощь!
-
Разбираюсь с предметной областью и по Вашим советам строю диаграммы.
-
[/quot
Если же у Вас утилитарная цель сдать курсовик, не напрягайтес! Трояк, я думаю, Вам гарантирован.
Хочу получить пятерку но для этого мне еще нужно много работать.
[/quotДорогой Vokist!
Любые усилия должны быть оптимальными для достижения поставленной цели.
Если Вы собираетесь стать системным аналитиком или проектировщиком, Вам стоит почитать книжки, попрактиковаться и т.д. Думаю, участники форума, и я в том числе, с удовольствием Вам помогут в достижении этой благородной цели!
В принципе, задачка для такой учебы подходит, и если ее довести до ума, она могла бы стать хорошим пособием. Тем более, можно проследить весь цикл, от требований до развертывания продукта.
Скорее всего чисто системным аналитиком я наверно не буду - скорее вместе с программистом.
-
Аналитик компьютерных систем - но это все перспективы).
-
Исправил первые три диаграммы.Попытался сделать диаграмму использования по совету не для всей системы сразу, а для одного варианта использования.Диаграмма классов для всех вариантов использования.
-
Добрый вечер!
Т.к. Эдуард взял на себя труд "критики" структуры, я продолжу "критику" (если можно так назвать) описания функциональности (в данном случае - диаграммы деятельности и идентификации прецедентов).
В справочнике UML, 2-е издание, авторов Буч и Ко, это "диаграмма, на которой показано разложение некоторой деятельности на ее составные части".
Наверное, основное назначение диаграммы - это описание выполнения прецедента (есть и другие приложения).
При описании прецедента деятельность (activity) принадлежит прецеденту, а диаграмма, естественно, деятельности. Т.е. нужно соблюдать правило: один прецедент -> одна деятельность -> одна диаграмма деятельности.
Примечание: составная часть деятельности сама может быть деятельностью; т.о. может образовываться иерархия диаграмм, ужасно подробно описывающих выполнение прецедента.
Вам это, м.б., и не нужно!
Прецедент - это описание последовательности взаимодействий субъекта (или субъектов, один из которых является первичным) с системой. На Вашей диаграмме никаких взаимодействий не видно. М.б. Вы указали, кто выполняет каждое действие в их описаниях? (Честно говоря, я сомневаюсь, что вы выполняли описания действий!)
Для явного указания на диаграмме, кто выполняет действие, имеется элемент "дорожка" (в UML 2 - Partition). У Вас д.б. две дорожки: субъект и система. Каждый узел диаграммы помещается в тот раздел, который представляет исполнителя.
"Мячик" перекидывается между субъектом и системой. Словами это можно выразит примерно так:
- субъект выбирает тип отчета
- система, если субъект выбрал "Инвентарная книга", отображает окно настройки отчета Инвентарная книга
если субъект выбрал "КСУБФ", отображает окно ...
Все это, конечно, графически. Ну, и названия действий должны кратко, но понятно, отображать их содержание (действия - это не названия окошек, а действия, выполняемые системой или субъектом).
Думаю, с объяснением нового материала, на сегодня, достаточно.
Есть явная ляпа, которую многие, особенно начинавшие на UML 1x, не замечают: в самое верхнее действие входят два потока управления. В UML 1х такой прием даже рекомендовался для лаконичности. UML 2 много формальнее (жесткий формализм объясняется тем, что UML 2 разрабатывался для поддержки концепции MDA). В данном случае получается клинч: если в действие входят два потока управления, то действие начинается только тогда, когда управление "прибежит" по обоим потокам. Здесь этого не может быть в принципе, значит действие никогда не будет выполнено. Т.е. такая нотация применима только, если это параллельные потоки.
Для объединения потоков нужно использовать элемент Mtrge Node (это ромбик, похожий на Decision Node, но это другой элемент с другими свойствами). Если Ваш инструмент такого элемента не имеет, используйте ромбик Decision. На вид все будет корректно, а код генерировать из диаграммы деятельности Вы, как я понимаю, не собираетесь.
Проверьте, нет ли еще таких ситуаций.
Кстати, название этого действия - это явно название окошка. Это весь прецедент - формирование отчета. На самом деле это "Отображение окна ...", после которого следует действие субъекта типа "Выбор продолжения", и снова, на стороне системы - ромбик и альтернативные потоки.
-
Не смог подойти к компьютеру за последние три дня- я буду дома только на выходных. Попытаюсь перестроить диаграммы по Вашему совету.
-
Спасибо за помощь
-
У меня к lnew и Galogen есть просьба.Помогите пожалуйста мне сделать все диаграммы на примитивном уровне не усложняя, а используя те элементы, возможно, которые минимально необходимы и
присутствовали на курсовой, которую я выложил в первый раз. Просто у меня
осталось немного времени - эти выходные и следующие.
1.диаграмма использования(прецедентов)- критика;
У нас в университете такие требования, что изображение диаграммы использования возможно в таком виде какой был в первом варианте.
Я пытался изобразить все что делает пользователь с системой. Если делать примитивно - возможно ли оставить диаграмму использования как у меня была в первом варианте. Или есть что-то что обязательно надо в ней добавить.(мне не нравится в ней то,что много элементарных действий расширения(добавить, удалить...) при формировании справочников).Или мне как-то сделать по Вашему совету - попытаться варианты использования сгруппировать по пакетам.
-
Заранее спасибо
-
1.диаграмма использования(прецедентов)- критика;
У нас в университете такие требования, что изображение диаграммы использования возможно в таком виде какой был в первом варианте.
Я пытался изобразить все что делает пользователь с системой. Если делать примитивно - возможно ли оставить диаграмму использования как у меня была в первом варианте. Или есть что-то что обязательно надо в ней добавить.(мне не нравится в ней то,что много элементарных действий расширения(добавить, удалить...) при формировании справочников).Или мне как-то сделать по Вашему совету - попытаться варианты использования сгруппировать по пакетам.
Дорогой друг Vokist!
Боюсь, мечты уважаемого Эдуарда не оправдаются! (Это насчет пяти шаров). Понимаю, откуда у студента время!
Совет: когда читаешь технический текст, читай внимательно. Если текст описывает картинку или отзыв на картинку, читай и просматривай те части картинки, о которых идет речь в тексте.
Не нравятся прецеденты "ввести", "удалить"?
Я уже писал, это не прецеденты! Это действия в прецеденте! Они должны быть или описаны текстом в описании прецедента, или представлены в соответствующей диаграмме деятельности!
Ты говоришь, что в диаграмме прецедентов нужно нарисовать все, что делает субъект.
Это бред сивой кобылы! Или у вас преподаватель не обладает соответствующей квалификацией (во что я не верю), или ты слушал его с той же продуктивностью, с которой читаешь мои рецензии.
Если уж так тебя прижало, рисуй все на одной диаграмме прецедентов, но там должны быть только прецеденты (модельные элементы, соответствующие определению этого термина).
Диаграмм деятельности должно быть столько, сколько прецедентов! Все иное - грубейшая ошибка!
Про классы пусть Эдуард пишет, если у него есть время.
Извини, если слишком грубо. Зато справедливо.
-
1.диаграмма использования(прецедентов)- критика;...
То есть Ваша критика.
Извини, если слишком грубо
Ничего.Пытаюсь читать литературу - надеюсь получится.
-
Попытаюсь быстро и качественно все сделать.
-
Цитата: Vokist от Января 15, 2011, 09:02:11 pm
1.диаграмма использования(прецедентов)- критика;...
То есть Ваша критика.
Если можете критикуйте мои диаграммы.Попытаюсь их сделать правильно.(и быстрее их выложить)
-
Не смотря на критику мне курсовая нравится. Но я в ней искал пример описания сценария в ВИ для обобщения.
сам вопрос тут (http://www.uml2.ru/forum/index.php?topic=2225.0)