Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: multitaskrobot от 12 Октября 2008, 09:13:14
-
Добрый день
Разрабатывается информационная система по учету и контролю за исполнением управленческих документов на предприятии.
Иерархия типов документов на предприятии выглядит следующим образом
-- Управленческий документ
|_Распорядительный документ
|_Приказы генерального директора
|_Решения генерального директора
|_Распоряжения генерального директора
|_Распоряжения начальника подразделения (подразделения, для которого разрабатывается система)
|_Служебный документ
|_Входящий
|_Внутренний
|_Факс
|_Служебная записка
|_Внешний
|_Факс
|_Письмо
|_Исходящий
|_Внутренний
|_Факс
|_Служебная записка
|_Внешний
|_Факс
|_Письмо
Интересует как представить на диаграмме классов следующие моменты:
1. Факс может быть внешним, внутренним, исходящим и входящим, получается под каждый тип факса создавать отдельный класс?
2. С помощью каких связей и классов представить эти типы документов на диаграмме классов?
Спасибо за помощь
-
Представить можно по-разному. Можно сделать так:
Служебный документ с соответствующими уточняющими классами Факс | Служебная записка | Письмо.
С атрибутами - входящий, исходящий , внутрений или внешний.
Однако для правильного принятия решения маловато информации о поведении разных документов или скорее о событиях, которые возникают в связи с ними
-
Попробуйте что-то нарисовать, так будет понятнее.
-
Добавлю один комментарий ... действительно - можно смело разрулить атрибутами, только следует поминить, что сам атрибут тоже может быть ссылкой на класс. Это в том случае, если для входящих\исходящих документов предполагается какое-то поведение.
-
Спасибо за ответы.
Некоторое общее описание системы учета и контроля управленческих документов (далее - документ)
1) Сведения о документе и его электронная копия заносятся в систему
2) Документу назначаются исполнители, причем каждый исполнитель может назначить других исполнителей, своих подчиненных (получается дерево исполнителей), а также назначаются сроки исполнения документа
3) Документ может иметь различные состояния (не выполнен -... - взят на контроль - ... - ... - выполнен), в системе учитываются дата передачи документа исполнителю, дата возврата документа в делопроизводство, дата предполагаемого выполнения документа, дата фактического выполнения и т.д.
4) Исполнитель составляет отчет о выполнении документа
Диаграмма классов во вложенном рисунке:
нарисована в Power Designer,
ограничимся служебными документами и Факсом.
Понимаю, что диаграмма неправильная, но суть в ней отражена. Необходимо представить иерархию классов управленческих документов, с учетом разделения на входящие(внутренние/внешние), исходящие(внутренние/внешние).
... представить можно по разному...
2 Galogen : Как еще можно представить подобную иерархию документов?
-
... представить можно по разному...
2 Galogen : Как еще можно представить подобную иерархию документов?
Мне кажется представленная вами иерархия сложна для использования. Безусловно она отражает некоторую классификацию, но...
Скажем чем отличается внешний документ от внутреннего? Не может ли документ быть одновременно исходящим для одного отдела-исполнителя и входящим для другого-отдела исполнителя.
Каждый уровень иерархии должен добавлять какие-то информационные свойства, а что в вашем случае добавляет каждый уровень иерархии.
В чем отличие служебного документа от управленческого, чем служебный документ уточняет управляющий.
Кроме того, представьте ситуацию, что вы хотите полученное решение использовать в других приложениях, в этом случае вам придется включать всю иерархию наследования.
На мой взгляд иерархия может начинаться с управляющего класса, идти через служебный и заканчиваться факсом, служебной запиской и письмом. Поскольку вполне возможно они имеют некоторый собственный набор атрибутов, отличающий их от каждого наследника...
-
Нарисовал второй вариант диаграммы классов,
Не могли бы вы оценить ее корректность?
--Скажем чем отличается внешний документ от внутреннего?
Внешний пришел извне на предприятие, а внутренний появился внутри предприятия (пришел из отдела в отдел)
--Не может ли документ быть одновременно исходящим для одного отдела-исполнителя и входящим для другого-отдела исполнителя.
Может, в случае единой базу на предприятии, сейчас у каждого подразделения своя БД.
--Каждый уровень иерархии должен добавлять какие-то информационные свойства, а что в вашем случае добавляет каждый уровень иерархии.
В моем случае иерархия добавляет некоторые свойства, на диаграмме атрибуты не делал, чтобы не усложнять ее
--В чем отличие служебного документа от управленческого, чем служебный документ уточняет управляющий.
Отличие есть, ответил в предыдущей фразе
-
Нарисовал второй вариант диаграммы классов,
Вариант хорош как концептуальная модель классов. Так ее и надо понимать и анализировать. Это не диаграмма классов, которая станет скажем моделью данных. Пока еще далеко. Нужно тщательно проанализировать концепцию и найти наиболее эффективные решения.
Не могли бы вы оценить ее корректность?
Концептуальная диаграмма настолько корректна, насколько однозначно понимается заинтересованными лицами.
--Скажем чем отличается внешний документ от внутреннего?
Внешний пришел извне на предприятие, а внутренний появился внутри предприятия (пришел из отдела в отдел)
Я вас не об этом спрашивал, а атрибутами, поведением. То что вы указали, может спокойно определено атрибутивно
--Не может ли документ быть одновременно исходящим для одного отдела-исполнителя и входящим для другого-отдела исполнителя.
Может, в случае единой базу на предприятии, сейчас у каждого подразделения своя БД.
Тем более не коректно делить классы по признаку входящий / исходящий
--Каждый уровень иерархии должен добавлять какие-то информационные свойства, а что в вашем случае добавляет каждый уровень иерархии.
В моем случае иерархия добавляет некоторые свойства, на диаграмме атрибуты не делал, чтобы не усложнять ее
в данном случае интересно на них взглянуть
--В чем отличие служебного документа от управленческого, чем служебный документ уточняет управляющий.
Отличие есть, ответил в предыдущей фразе
не вижу ответа, есть только фраза о том, что мол отличаются
-
Спасибо за помощь.
Как только внесу изменения в диаграмму классов обязательно выложу.
-
Добрый день.
Допустим есть класс "Исполнитель", "Сотрудник", "Подразделение предприятия"
Как мне представить на диаграмме классов тот факт, что "Исполнитель" может быть либо "Сотрудником", либо "Подразделением предприятия"?
-
Это известная задача: решается наследованием. Исполнитель -- суперкласс, Сотрудник и Подразделение -- подклассы, причем от Подразделение и Исполнителя можно связать агрегацией (Исполнитель -- часть, Подразделение -- целое).
-
Добрый день.
Допустим есть класс "Исполнитель", "Сотрудник", "Подразделение предприятия"
Как мне представить на диаграмме классов тот факт, что "Исполнитель" может быть либо "Сотрудником", либо "Подразделением предприятия"?
Вы имеете в виду, что исполнитель может играть роль сотрудника или подразделения?
Тогда лучше всего выделить два интерфейса - Сотрудник и Подразделение. А Исполнитель пусть эти интерфейсы реализует.
Предложенное Виктором решение может не сработать, так как наследование (в UML - обобщение) подразумевает принцип подстановочности. Я не думаю, что во всех местах, где будет использоваться Исполнитель не будет иметь значение, какой реально объект будет подставлен Сотрудник или Подразделение.
-
Вы имеете в виду, что исполнитель может играть роль сотрудника или подразделения?
Я имею ввиду, что исполнитель может быть либо сотрудником, либо подразделением (если "может играть роль" и "может быть" одно и то же, то мы думаем про данную ситуацию одинаково).
Не могли бы Вы, изобразить на диаграмме классов (в контексте моей второй диаграммы) Ваш вариант с исполнителем, сотрудником и подразделением, для большего понимания Вашего предложения?
-
Не могли бы Вы, изобразить на диаграмме классов (в контексте моей второй диаграммы) Ваш вариант с исполнителем, сотрудником и подразделением, для большего понимания Вашего предложения?
Напишите техническое задание и дайте определение всем используемым терминам. Тогда я нарисую вам диаграмму классов.
-
Если я правильно понял, имелось в виду, что "Исполнителем" может быть либо "Сотрудник", либо "Подразделение". В таком случае "решение с интерфейсом" выглядит так:
---------------
|<<interface>>|<|- - - Сотрудник
| Исполнитель |<|- - - Подразделение
---------------
Вместо связей наследования (обобщения) -- связи реализации.
P. S. Рамочки классов вокруг сотрудника и подразделения рисовать поленился. :)