Помогите, пожалуйста, буду очень благодарен если сделаете хотя бы 1 диаграмму
4 из них сделал
Само задание:
6. БИБЛИОТЕКА
Описание предметной области
Вы являетесь программистом в библиотеке. Ваша библиотека решила зарабатывать деньги, выдавая напрокат некоторые книги, имеющиеся в небольшом количестве экземпляров. Вашей задачей является разработка информационной системы, обеспечивающей отслеживание финансовых показателей работы библиотеки.
У каждой книги, выдаваемой в прокат, есть название, автор, жанр. В зависимости от ценности книги Вы определили для каждой из них залоговую стоимость (сумма, вносимая клиентом при взятии книги напрокат) и стоимость проката (сумма, которую клиент платит при возврате книги, получая назад залог). В библиотеку обращаются читатели. Все читатели регистрируются в картотеке, которая содержит стандартные анкетные данные (фамилия, имя, отчество, адрес, телефон). Каждый читатель может обращаться в библиотеку несколько раз. Все обращения читателей фиксируются, при этом по каждому факту выдачи книги запоминаются дата выдачи и ожидаемая дата возврата.
Классы объектов
Книги (Название, Автор, Залоговая стоимость, Стоимость проката, Жанр).
Читатели (Фамилия, Имя, Отчество, Адрес, Телефон).
Выданные книги (Книга, Читатель, Дата выдачи, Дата возврата).
Развитие постановки задачи
Теперь ситуация изменилась. Несложный анализ показал, что стоимость проката книги должна зависеть не только от самой книги, но и от срока ее проката. Кроме того, необходимо добавить систему штрафов за вред, нанесенный книге и систему скидок для некоторых категорий читателей.
Первоначальная постановка:
• Диаграмма случаев (диаграмма прецедентов) – use case diagram
• Диаграмма классов (структура классов) - class diagram
• Диаграмма кооперации – collaboration diagram

Развитие задачи:
• Диаграмма случаев (диаграмма прецедентов) – use case diagram
• Диаграмма классов (структура классов) – class diagram
• Диаграмма объектов (структура объектов) - object diagram
• Диаграмма кооперации – collaboration diagram
• Диаграмма последовательностей - sequence diagram
• Диаграмма активностей - activity diagrams

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

На форуме могут помочь, но не будут за тебя делать, пойми.

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

Сделал 4: обычную прецедентов, обычную классов, активностей и последовательностей

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

Вот ряд замечаний, советов, рекомендаций и вопросов.

1. Диаграмма прецедентов - из описания явно можно вычленить только Возврат и выдачу книги, а также Регистрация читателя
Проверка контрольных сроков - это часть ВИ возврат книги, не вижу смысла вычленять это в отдельный поток. Это похоже на функциональную декомпозицию. что нехорошо.
Оплата услуг - часть процесса по Выдачи книги. Подумайте, что значит Читатель обратился в систему с целью оплатить услугу. Из описания никак не следует, что это отдельный поток.
Читатель - участник процесса. но он не ОСНОВНОЕ ДЛ, а потому непосредственно с системой учета проката книг не взаимодействует
Сами прецеденты желательно заключить в системный контекст - boundary - типа Система учета проката книг
База данных - в топку - это элемент реализации, или она должна быть представлена как внешняя сущность - актор, типа Картотека читателей

2. Диаграмма классов - мастдай!
Персонал - плохой класс, Библиотекарь лучше, Можно Сотрудник
все связи разорвать - бред!!!
Классы именуются единственным числом
Связи
Читатель (1) - (1 .. *) Выданная книга
Книга (1) - (0 .. *) Выданная книга

Персонал видимо мастдай, либо висит несвязанный

Я бы конечно создал класс Прокат
Читатель (1) - (1..*) Прокат (0..*) - (1) Сотрудник
Прокат (1) - (1..*) Выданная книга (0..*) - (1) Книга

Например как-то так

3. Диаграмма последовательность  - мастдай.
- сначала определись что за прецедент она моделирует, опиши это прецедент текстом
- читатель - не у дел - его убрать
- понять что должна отображать диаграмма последовательности -  реализацию прецендента? Если да в каком стиле, стиле РУП, тогда нужно определить выделить интерфейсные классы: форма, страница, и т.п.; управляющий класс: Обработчик, Диспетчер, контроллер, МенеджерВыдачи и т.п.; ну и твои сущностные классы: читатель, книга и т.п.

4. Диаграмма деятельности - реально у тебя не диаграмма деятельности, а типа 3 в одном. Низя. Опять же нужно понять что ты хочешь передать ДД -процесс чего? Как минимум функции должны располагаться в дорожке где это действие производится выбор книги наверное делает Читатель, Выдачу - отдел и т.д.

Уточню кое-что:
1. Диаграмма прецедентов:
- Из описания не совсем понятно читатель регистрируется сам или его регистрирует Библиотекарь. Можно предположить что это будет Библиотекарь. Хотя от Заказчика можно ожидать всё что угодно и я бы уточнил.
- В описании нет информации про необходимость использования существующих систем. Если у заказчика выясните, что необходимо использовать существующую БД, только тогда она может появиться на диаграмме в виде эктора.
2. Диаграмма классов:
- Нужно прежде всего отталкиваться от того, на каком уровне абстракции нужно построить диаграмму классов. Они будут отличаться в моделях бизнеса, анализа, дизайна/реализации.
Судя по всему нужна диаграмма классов на уровне анализа.
- Для чего нужен класс "Персонал" или "Библиотекарь". Их нужно учитывать? Это нужно уточнить.
- Связи действительно непонятно по какому принципу построены.
- Собираемся ли мы учитывать возврат книг? Из диаграммы видно, что не собираемся. А вообще надо бы.
- Как будут учитываться конкретные экземпляры одной и той же книги? Помимо класса "Книга" должен быть ещё класс "Экземпляр книги".
- Другой вопрос... Что если читатель возьмёт книгу, а вернёт такую-же, но в более плохом состоянии? Необходимо учитывать связанные выдачу и возврат конкретного экземпляра.
В общем есть над чем поразмыслить.
3. Диаграмма объектов:
Она показывает "моментальный снимок" объектов системы в определённый момент времени. Какой момент времени предполагается рассматривать? Какая цель создания этой диаграммы?
4. Диаграмма кооперации и диаграмма последовательностей:
Добавить особо нечего.
5. Диаграмма деятельности (активностей):
Нужно понимать какой именно вариант использования мы хотим визуализировать этой диаграммой, а не скидывать всё в кучу. Цепочка "Применение скидки/Подготовка книги -> Внос залога/выдача книги" это вообще взрыв мозга.

1. Диаграмма прецедентов:
- В описании нет информации про необходимость использования существующих систем. Если у заказчика выясните, что необходимо использовать существующую БД, только тогда она может появиться на диаграмме в виде эктора.

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

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

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

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

Браво!!

Я не возражаю ЭТИМ Вашим словам, я против превращения базы данных в actor. Унаследованная система вряд ли называется база данных.

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

Я в предметной области выделяю следующие компоненты:
1. Понятия
2. Явления
3. Агенты
4. Объекты
5. Деятельность
6. Правила

Из них кандидатами на переход в диаграмму классов системы являются 1-5.

Я не возражаю ЭТИМ Вашим словам, я против превращения базы данных в actor.

Согласен, что чаще всего это является ошибкой.

Унаследованная система вряд ли называется база данных.

В просторечии и объявлениях распространены фразы типа "водительские права с занесением в базу данных гибдд"

В просторечии и объявлениях распространены фразы типа "водительские права с занесением в базу данных гибдд"

Согласен, что можно в просторечии так сказать, но даже здесь мы говорим База данных ГИБДД, на самом деле понимая целую систему. Однако студенту - это противопоказано. Пусть сначала научится теории следовать.

Кстати - студент-то молчит

Согласен, что можно в просторечии так сказать, но даже здесь мы говорим База данных ГИБДД, на самом деле понимая целую систему. Однако студенту - это противопоказано. Пусть сначала научится теории следовать.

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

Наречение системы по существу ее назначения - не такой уж редкий или неправильный случай (как минимум, в отечественной практике). Если теория требует иного, это неважная теория.