В самой инструкции также дается другое понятие дифференцированный. Я думаю составители инструкции ошиблись с выбором термина.

Индивидуальный, идет от индивидуала

ИНДИВИДУА'Л, а, м. (нов. газет.).
Лицо, выполняющее индивидуально, единолично какую-н. работу, в противоп. лицам, работающим группой, коллективом. Заочным обучением в нашем городе охвачено шесть групп, индивидуалов имеется 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!
Любые усилия должны быть оптимальными для достижения поставленной цели.
Если Вы собираетесь стать системным аналитиком или проектировщиком, Вам стоит почитать книжки, попрактиковаться и т.д. Думаю, участники форума, и я в том числе, с удовольствием Вам помогут в достижении этой благородной цели!
В принципе, задачка для такой учебы подходит, и если ее довести до ума, она могла бы стать хорошим пособием. Тем более, можно проследить весь цикл, от требований до развертывания продукта.

Скорее всего чисто системным аналитиком я наверно  не буду - скорее вместе с программистом.

Аналитик компьютерных систем - но это все перспективы).   

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