В ходе разработок веб приложение испольщующее технологие php(CodeIgniter),Mysql,Javascript(YUI) дорасло до такого размера что встала необходимость использовать UML чтоб задокументровать систему, да и разложить по полочкам всю архитектуру.

Остановился на IA для проектирования, выбрал деаграммы классов для отображения физической структуры и диаграмме DataBase для БД. Возникли вопросы на которые так и не нашел ответы на форуме. Читаю Основы UML Гради Буча.
Итак:

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

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

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

Во-первых, да сотрудник работает в отделе, но отдел находится в (принадлежит, является неотъемлемой частью) компании
Во-вторых, если сотрудник работает в отделе, а отдел часть компании, то агрегация между сотрудником и компанией лишняя.
В-третьих, сотрудник не может быть частью должности, тем более такой которая ФИЗИЧЕСКИ уничтожается в месте с классом композитом(должность). Сотрудник имеет ассоциацию с должностью
В-четвертых, что вы пытаетесь моделировать структуру хранимых данных? или предметную область через диаграмму классов?

Скорее всего предметную область через диаграму классов. даграмму поправил

Скорее всего предметную область через диаграму классов. даграмму поправил

Мне больше видится конечно совершенно другой вариант.
Компания как объект агрегирует отдел, ну а отдел уже так сказать сотрудников, выражается паттерном композит.
Должность это всего лишь состояние объекта сотрудник а значит только его свойство.
А вот если по теме ajax: это отлично показывается на диаграмме последовательностей. На ней существую асинхронные сообщения.

Мне больше видится конечно совершенно другой вариант.
Компания как объект агрегирует отдел, ну а отдел уже так сказать сотрудников, выражается паттерном композит.
Должность это всего лишь состояние объекта сотрудник а значит только его свойство.
А вот если по теме ajax: это отлично показывается на диаграмме последовательностей. На ней существую асинхронные сообщения.

Должность реализованна в виде класса т.к. имеет методы

вот так

Привет. Скажи, пожалуйста, как связана проектируемая модель классов  с реальной, которая уже работает в приложении?

Компоненты собраны в каталоге components, каждый компонент имеет в своем составе три каталога models, controllers, views (по принципу MVC). Сигналы с сервера обрабатывают контроллерами в соответствующем каталоге а также активно используют бизнес-модели компонента, модели компонента собраны в models,работаю напрямую с БД

шаблоны за вывод информации

даграмма моделей

даграмма моделей

Опа - а это что за чудо?

классы потомки класса Модель

class User extends Model
{
.....
}

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

это еще делается для понимания веб приложения между разработчиками с целью улучшения как отдельных компонентов так и системы в целом

это еще делается для понимания веб приложения между разработчиками с целью улучшения как отдельных компонентов так и системы в целом

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