Добрый день!
Так сложилось, что я отучился на бизнес-аналитика и имею некоторый опыт работы в этой сфере (но в данный момент я занимаюсь разработкой).
Теперь немного тезисно по вашей информации:
1) Диаграмма - способ представить информацию, любую диаграмму можно описать словами.
2) Диаграмма - инструмент для выявления новой информации о системе.
3) Впервые слышу про диаграмму бизнес-объектов: может это что-то крайне редкое (крайне специализированное), но с высокой долей вероятности, это вам не потребуется.
4) UML - язык, а не гайдлан по документированию ПО, сл-но в книгах с аббревиатурой UML вы не найдете нормального руководства по документированию.
Вывод из этого следующий: диаграмма используется как подкрепление к документации, как инструмент проектирования ПО (для выявления зависимостей и новых сущностей). В обоих случаях набор нотаций будет зависеть от требований, предъявляемых к таким документам.
Если вам интересно документирование ПО, то гуглите: техническая документация, техническое задание, ГОСТ 34, ГОСТ 19, SRS, хорошая статья на
хабре про это.
Если вам интересно именно полноценное описание проекта, то гуглите: методологии разработки программного обеспечения, управление проектами, pmi, pmbok, agile.
Теперь пройдемся по диаграммам в зависимости от назначения. Я сейчас могу выделить несколько направлений (не претендуя на полноту):
1) уровень бизнеса (любые части системы, находящиеся вне ПО per se)
2) уровень программного обеспечения (системные модули, компоненты системы уже реализованные на уровне ПО)
3) уровень данных (структура данных, описание типов данных и т.д.)
4) уровень hardware (например, топология сети)
На уровне бизнеса обычно описываются бизнес-процессы (idf0, idf3, aris, bpmn, dfd), воркфлоу, юзкейсы, маиндмапы и проч. - это все идет сюда. На этом уровне выделяются основные процессы, выполняемые внешними относительно системы акторами, выявляются точки их взаимодействия с системой. На основе этого проектируются основные модули системы, исполняемые ими функции и их взаимодействие. Взаимодействие системы с внешней средой.
На уровне ПО обычно используются алгоритмы, псевдокод, сущность-связь, диаграммы классов, флоучарты, маиндмапы, диаграммы состояний и все вот это вот абстрактное. Как вы понимаете, все сущности, описываемые на этом уровне уже выделены на уровне бизнеса и здесь происходит их уточнение и описываются особенности реализации. Под сущностями я тут понимаю как и глобальные системные модули и подсистемы, так и абстрактные сущности внутри системы, как то "товар", "пост", "юзер" и т.п.
На уровне данных обычно делается схема бд. Собственно, схема бд строится на основе описанных сущностный из предыдущего уровня.
Уровень hardware я лично всегда рассматривал редко, но он строится на основе требований бизнеса, требований к программному обеспечению, требований к обработке, хранению данных.
К сожалению, я не могу в один пост уместить весь объем знаний, полученный мной за годы обучения и практики, но надеюсь, что это направит вас в нужное направление.
ps на небольших и средних проекта я стараюсь прибегать к одной из нотаций бизнес-процессов, если требуется что-то автоматизировать (idf или bpmn), юзкейсам для выявления интеракций пользователя с приложением; для подготовки к написанию ПО - сущность-связь, иногда алгоритмы.
Средний
