НУжна информация по азам проектирования

Пытаюсь разработать проект в Rational Rose. От чего отталкиваться при разработке классов, а затем и обьектов в диаграмме состояний (Statechart)? От устройств в диаграмме Deployment? Сколько устройств - столько и классов?

И ещё один вопрос. В диаграмме Use Case необходимо указывать всю деятельность актёра или только ту которая проходит с программным продуктом? Например - библиотекарь->приём книг. А для читателя - указывать "сдача книг" или нет?

Заранее благодарен.

0

смотрите тут

0

Ответьте, пожалуйста, возможен ли мой вариант диаграммы требований к системе (Use Case)? Если да, то подскажите некоторые классы?

Миниатюры

 

0

Я бы предложил следующие: поиск книги, пользователь-библиотекарь, администратор-библиотекарь, запись о книге. Новый вопрос: подойдут ли эти классы и хватит ли их?

0

Текстовое описание предметной области могло бы помочь вам в поиске сущностей для определения имен классов. Постарайтесь разобраться с бизнес-моделью, которая предшествует разработке вашей системы. тут я описал диаграмму бизнес объектов, если вы правильно определите бизнес-объекты предметной области, то они помогут вам нарисовать диаграмму классу.

Варианты использования типа "Авторизоваться" "Зарегистрироваться" по Коберну находяться не на уровне целей пользователя, а на уровне функций системы. Поэтому их изображать не надо. Также у ваших вариантов использования должны быть бизнес-цели, которые в отличии от функций находятся выше, чем цели пользователей, которые позволяет реализовать система(выше уровня моря). Их можно изобразить на отдельной диаграмме бизнес вариантов использования. Такую диаграмму можно не показывать преподу, но она позволит уточнить системные варианты использования. Ваши системные варианты использования должны быть как бы потомками бизнес вариантов использования.

Добавлено через 7 минут
Приведу пример бизнес вариантов использования.
Бизнес лица это:
Читатель

БВИ Получить книгу
Действующее лицо - читатель

Добавлено через 12 минут
Тут мы рассмотрели библиотеку как черный ящик. Для понимания бизнес-процессов внутри библиотеки мы можем рассмотреть библиотеку как прозрачный ящик.

В таком ящике появится действующее лицо - библиотекарь.

Цель библиотекаря это не выдать книгу как может показаться. А "оформить выдачу книги". Это и будет "родительской целью" для ваших системных вариантов использования.

а вообще есть в инете обсуждения подобных курсовиков например это

0

Скажите, почему следует указывать для читателя БВИ - получить книгу? Можно ли обойтись без этого (ведь уже есть цель библиотекаря "оформить выдачу книги"). К тому же читатель не взаимодействует здесь с информационной системой - общается с библиотекарем.

0

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

По Коберну "получить книгу" имеет самый высокий уровень(уровень облака)
на основании этого желания появляются цели библиотекаря "Оформить выдачу книги" "Зарегистрировать возрат книги".
Просто мы на основании БВИ "получить книгу" получаем четкую связь(которая заключается в цели библиотекаря "Оформить выдачу книги") между читателем и ИС(даже несмотря на то что читатель не взаимодействует с ИС)


В бизнес моделировании ещё нет информационной системы. То есть мы как бы рассматриваем, что происходит в библиотеке сейчас. Какие существуют у библиотекаря(и других действующих) проблемы.

Выявив всех действующих лиц и их "бизнес цели" мы сможем построить системную модель.

Конечно никто не требует производить бизнес моделирование, но это помогает разобраться в предметной области.

Добавлено через 13 минут
Если у нас существует БВИ библиотекаря "Оформить выдачу книги". То мы предполагаем, что он это делает в письменном журнале например.

"Оформить выдачу книги" - это как бы "родительская" цель для цели "Зарегистрировать выдачу книги" пользователя ИС - "библиотекаря".

Если изобразить их на разных уровнях, мы получим картинку похожую на картинку моря в книге коберна:

Бизнес уровень "Получить книгу" \ "Оформить выдачу книгу" Далее уровень границы ИС: "Зарегистрировать выдачу книги" Уровень функций ИС(его обычно не показывают на диаграмме вариантов использования ИС): Авторизация библиотекаря Регистрация нового пользователя

- о функциях ИС можно упомянуть в шагах сценариев вариантов использования.

0

А что делать дальше? Разрабатывать классы?

0

И ещё подскажите чисто практический вопрос: создаю класс:

Если записываю в стереотипе entity меняется форма:
Как сделать, что бы форма изображения класса оставалась прежней?

Миниатюры

 

Изображения

 

0

Вам уже дали объективную(хотя может и несколько субъективную) консультацию.

У вас не хватает некоторых частей фундамента для того, чтобы проектировать классы(о которых вам говорили на uml2_ru)

Хочу посоветовать меньше слушать советчиков и больше думать своей головой.

Но я вам объясню почему товарищам с сайта uml2 не нравится ВИ "Найти книгу" - по Коберну(это и есть всё объяснение).

Коберн в своей книге описал ВИ, похожий на ваш и назвал его "Найти что угодно".

По ходу смысл нескольких глав был в том, что этот ВИ это просто функция системы, а не ВИ.(всё хочу почитать англ. версию книги, а то в переводе смысл искажается). Либо наоборот если библиотекарю нужно найти книгу это Бизнес вариант использования. Эта цель либо слишком глобальна, либо слишком близка к функциям, чтоб находится на уровне границы системы.

Почему вы например нарисовали только "Найти книгу", ведь ещё же существует "найти читателя","найти автора книги", "найти библиотекаря" (например если администратор хочет изменить данные о библиотекаре). (поиск выполняется все лишь одним запросом SELECT в БД)

То есть если вы показываете такие маленькие функции системы(которые находятся ниже уровня CRUD) вы уменьшаете ценность диаграммы вариантов использования, я бы сделал не более 3-х ВИ(потому что системы которые обладают большим количеством ВИ, являются сложными для одного человека). Ваша задача, договориться с заказчиком(или с преподом) на минимальное количество работы.

Для начала можно было сделать 1 ВИ типа

Библиотекарь - "Зарегистрировать выдачу книги"

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

Одним ВИ и исключением функции поиска вы избавляетесь от необходимости вносить все атрибуты книг в БД.

и как следствие вам не нужно создавать таблицы для учета книг, и классы к этим таблицам(например таблица для авторов книг). Тут надо понимать, что если читатель берет книгу то надо её как то идентифицировать - предлагаю два способа: идентификатор или название книги, автор, издание. Просто если вам не нужно вести учет книг, а только их выдавать можно обойтись и идентификатором.

На сайте uml2 описан способ оформления ВИ. но он не является стандартом, некоторые используют стиль Коберна:
вот нашёл ссылку на intuite где кратко описан способ оформления по Коберну.

Перед диаграммой классов на вашем пути ещё стоят паттерны проектирования. Так как у вас будет интерфейс пользователя и БД, я вам предлагаю использовать MVC, потому что я хоть немного могу с ним помочь.

Добавлено через 6 минут
Поскольку я присутствую на сайте uml2 писать параллельно в этой теме необязательно.

0

Такая диаграмма может соответствовать основным требованиям?

Миниатюры

 

0

Ну... если читатель не имеет доступа к ИС...

То "Читатель" это бизнес-лицо, которое изображается бизнес-актёром, то же самое "Получить книгу" - он должен обозначаться бизнес вариантом использования (с черточкой в левом нижнем углу) (так как ИС не может сама выдавать книги, даже если вы используете роботизированную выдачу книг, ИС может лишь послать сигнал для выдачи)

бизнес-лиц и бизнес варианты использования лучше изображать на отдельной диаграмме.
например

видите я показал границы библиотеки, чтоб было понятно что это не ИС, а организация. Также лучше показывать границы ИС на системной диаграмме вариантов использования(или хотя бы расположить действующих лиц по краям, чтоб это было похоже на документ)

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

Я как бы не являюсь системным аналитиком в отличии от товарищей на uml2, у меня другая профессия.

1

Уф-ф, как всё сложно. Мне кажется Rational Rose лучше использовать в сложных проектах, а не для учебных. Вся информация от "заказчика", то бишь "препода" - это "Построить модель работы библиотеки". Возможно для меня лучше в начале продумать логическую модель базы данных, а потом уже отталкиваясь от неё писать диаграммы?

0

Делайте, если не боитесь лишней работы.

Самые популярные модные методологии это XP (например Agile, Scrum и т п) и RUP (внимательно посмотрите на картинку и подумайте где находится этап проектирования БД)

Экспериментируйте, может найдёте новые подходы к разработке ИС.

1

Прошу проверить диаграмму Statechart обьекта "Книга". По замыслу, есть ещё и класс "Экземпляр" (Copy). Пример тривиальный, отношения м/у ними, я думаю понятны, но хотелось бы знать правильный ли?

Миниатюры

 

0

Немного изменил и дополнил комментариями.

Миниатюры

 

0

...

0

я редко рисую диаграммы состояний(обычно использую их для проектирования меню в программе), но в рамках нотации UML ошибок не нашёл.

Обычно до диаграммы состояний стараюсь сосредочиться на Диаграмме вариантов использования и диаграмме классов (которые существенно влияют на архитектуру)

Иногда рисую Диаграммы активности, чтоб понять как должен работать метод.

Диаграмму состояний для объекта я давно не рисовал.(просто потому что код C++ быстро меняется и как бы некоторым людям удобнее оценивать состояние объектов в программе, тем более что объектов там бывает миллионы...)

Поэтому мне самому интересно как вы её нарисуете и в каком контексте.(контекст я доконца так и не понял потому что у меня нет перед глазами вашего курсовика, где до диаграммы состояний было бы правильно сделан фундамент вашей работы.)

Надеюсь вы понимаете, что добавление новых и удаление не нужных вариантов использования, может сделать вашу диаграмму состояний лишней в работе.

Хорошо вы здесь создали тему, а то сайт uml2 сдулся

0

Сообщение от XRuZzz Хорошо вы здесь создали тему, а то сайт uml2 сдулся

Я ответственно заявляю, что к этому не причастен.

Что касается диаграммы, то в моём курсаче, она должна присутствовать "для примера".

0

,разработал классы для DB
+ Пример трёх классов для обработки одной таблицы

Миниатюры

   

0