Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Секреты бизнеса. Предприниматели рассказывают..." на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
Создаем свою информационную систему
Информационный Канал Subscribe.Ru |
Создаем свою информационную систему
Выпуск 12
Я долго обдумывал, как описать создание документа и решил
начать с самого общего алгоритма. Начну с того, что в последней версии системы
появилась возможность использовать в качестве базы описания модель Rational Rose.
Фактически это значит, что можно вплотную подойти к реализации фразы «нарисуем – будем жить».
Получается вот такой обобщенный алгоритм создания документов.
1. Делаем Экспорт текущей метамодели в Rational Rose. Это позволяет познакомиться с особенностью использования UML нотации в нашем случае и увидеть, что уже есть в системе.
2.
Рисуем модель документа в Rational Rose.
3.
Импортируем описание новых типов документов в среду
проектирования «Муромец»
4.
Дополняем и исправляем модель при необходимости.
5.
Создаем дополнительные «сложные запросы», если это
необходимо. См. Ниже.
6.
Накладываем ограничения уникальности на разделы
документа.
7.
Описываем режимы работы документа. См. Ниже.
8.
Проверяем модель и исправляем очевидные ошибки
9.
Генерируем код для базы данных.
10. Обновляем
базу данных
11. Генерируем
код для объектной модели и интерфейсной части документов
12. Преобразуем
код в исходные коды на Visual
Basic
13. Компилируем
исходные коды полученных проектов
14. Запускаем
программу Администратор и получаем новую версию списка лицензий
15. Тестируем
документ на наличие логических ошибок. Если надо возвращаемся к пункту 4.
16. Настраиваем
внешний вид форм редактирования и таблиц для просмотра разделов документа.
При отсутствии желания, или инструмента можно начинать сразу с пункта 4.
После одной- двух итераций можно получить вполне работоспособный документ. Другое дело, что для реальной прикладной системы это только начальная стадия. И после завершения этого цикла начинается работа над дополнительной логикой работы самих форм редактирования.
«Дополнительные запросы» - это по сути дела View, которое позволяет отображать
данные нескольких разделов документа в одной таблице. View есть смысл определять для всех
разделов на которые мы планируем ссылаться из других документов. Это связано с
тем, что универсальный механизм выбора строки для ссылки несколько страдает от
своей универсальности. Достаточно
сложно сделать простую реализацию алгоритма, который способен обеспечить выбор
строки из любого документа и с любой его глубины. Если для раздела не
определить представление (View),
которое будет использоваться для такого выбора, то система по умолчанию должна
использовать универсальный механизм.
Прямым следствием является рекомендация определять представления для каждого из разделов справочника, исключение может составлять древовидные справочники.
Режим работы документа. Режим работы документа – это то, как он виден на различных рабочих местах. Действительно, в зависимости от стадии жизненного цикла документ может выглядеть совершенно по-разному. Например, инструкция на стадии разработки имеет один вид и свойства, на стадии утверждения доступен раздел утверждений и комментариев, но не доступен для редактирования основной раздел текста. На стадии исполнения инструкция доступна только для чтения, но возможно внесение комментариев. Все это режимы работы одного и того же документа.
Реальное проектирование документа складывается из нескольких фаз.
- Проектирование структуры, которое можно сделать и на бумаге, или с использованием средств моделирования
- Проектирование режимов. Вообще говоря, я не знаю средств проектирования, которые эту фазу вообще затрагивали. Надеюсь, что я просто ошибаюсь.
- Проектирование схем защиты документа на уровне прав.
- Проектирование процессов, которые обеспечивают реализацию жизненного цикла документа. Эту фазу можно реализовать либо с использованием системы управления бизнес процессом, либо моделирую смены прав и режимов работы в зависимости от текущего состояния документа. Можно использовать и оба метода сразу.
Вот теперь мы уже сказали достаточное количество слов, чтобы привести структуру одного из документов, которые мы будем использовать в нашей системе. Пока это только структура. Общая идея реализации состоит в том, что для документов одного и того же типа в организации предусматривается идентичный способ обработки документа. Обработка документа может идти двумя путями. Первый путь – отработанный и утвержденный процесс. Такой процесс нам поможет обслужить подсистема управления процессами. А соответствие между типом документа и тем процессом, который должен быть запущен для нового документа устанавливается в справочнике типов документов.
Второй путь – свободная маршрутизация. Мы реализуем ее способом, который очень похож на реализацию в рамках системы Евфрат. Построим дерево обработки. Это несколько ограничивает нас в сложности процесса, но мы-то понимаем, что такой способ должен использоваться, когда не утвержден «нормальный» процесс. Т.е. в достаточно экстренных случаях. А в такой ситуации эти ограничения нас вполне устраивают.
В описании документа вы обнаружите ссылки на новые еще пока неизвестные нам сущности: Динамика обработки и Машина состояний. Первая предназначена для хранения данных в случае свободной маршрутизации, а вторая – это дополнительная возможность управлять жизненным циклом документа. Остальные сущности, такие как Контактное лицо и Клиент – заимствованы из примера, База данных клиента, который входит в состав среды проектирования.
Описание документа: Карточка - Входящий ( cinc_ )
Документ входит в состав приложения: Канцелярия
Описание раздела: Общий(card_inc_common)
Общий
Структура (коллекция с одной строкой)
Структура раздела
Название |
Псевдоним |
Тип |
Можно не задавать |
кратко |
размер / ссылка на |
Номер входящего |
docnumber |
Целое число(Integer) |
Да |
Да |
|
Количество листов
документа |
pagesnum |
Целое число(Integer) |
Да |
Нет |
|
Отправитель |
sender |
Ссылка(Reference) |
Да |
Нет |
ссылка на объект
типа: Контактное лицо |
Подшит в папку |
docfolder |
Строка ограниченной
длины(String) |
Да |
Нет |
80 |
Комментарии |
comments |
Мнегострочное поле
для ввода информации(Memo) |
Да |
Нет |
|
Зарегистрировал |
reguser |
Ссылка(Reference) |
Да |
Нет |
ссылка на строку
раздела: Пользователи(в документе: Данные о пользователях) |
Дата исходящего |
outdate |
Дата(Date) |
Да |
Нет |
|
Название |
docname |
Строка ограниченной
длины(String) |
Нет |
Да |
80 |
Отдел |
department |
Ссылка(Reference) |
Да |
Нет |
ссылка на строку
раздела: Отделы(в документе: Справочники канц.) |
Количество листов
приложения |
apppagesnum |
Целое число(Integer) |
Да |
Нет |
|
Префикс |
docprefix |
Строка ограниченной
длины(String) |
Да |
Да |
10 |
Постфикс |
docpostfix |
Строка ограниченной
длины(String) |
Да |
Да |
10 |
Дата входящего |
docdate |
Дата(Date) |
Да |
Да |
|
Номер исходящего |
outnumber |
Строка ограниченной
длины(String) |
Да |
Нет |
50 |
Тип входящего |
doctype |
Ссылка(Reference) |
Да |
Да |
ссылка на строку
раздела: Тип входящего(в документе: Справочники канц.) |
Дата регистрации в
системе |
regdate |
Дата(Date) |
Да |
Нет |
|
Ответственный
исполнитель |
curator |
Ссылка(Reference) |
Да |
Нет |
ссылка на строку раздела:
Пользователи(в документе: Данные о пользователях) |
Контактное лицо
отправителя |
ContactPerson |
Ссылка(Reference) |
Да |
Нет |
ссылка на объект
типа: Контактное лицо |
Текущее состояние |
CurrentState |
Идентификатор(ID) |
Да |
Нет |
|
Проект |
Project |
Ссылка(Reference) |
Да |
Нет |
ссылка на объект
типа: Динамика обработки |
Организация |
senderorg |
Ссылка(Reference) |
Да |
Нет |
ссылка на объект
типа: Клиент |
Описание раздела: Документы(card_inc_docscollect)
Документы
Коллекция строк
Структура раздела
Название |
Псевдоним |
Тип |
Можно не задавать |
кратко |
размер / ссылка на |
Файл |
docfile |
Ссылка(Reference) |
Да |
Да |
ссылка на объект
типа: Каталог |
Вложение |
Data |
Файл(File) |
Да |
Нет |
|
Название |
Name |
Строка ограниченной
длины(String) |
Да |
Да |
80 |
Описание раздела: Связи(card_inc_cardrefs)
Связи
Коллекция строк
Структура раздела
Название |
Псевдоним |
Тип |
Можно не задавать |
кратко |
размер / ссылка на |
Ссылка |
cardref |
Ссылка(Reference) |
Нет |
Да |
ссылка на объект |
Тип ссылки |
reftype |
Ссылка(Reference) |
Нет |
Да |
ссылка на строку
раздела: Тип ссылки(в документе: Справочники канц.) |
Описание раздела: Темы для каталогизации(card_inc_theme)
Темы для каталогизации
Коллекция строк
Структура раздела
Название |
Псевдоним |
Тип |
Можно не задавать |
кратко |
размер / ссылка на |
Тема |
theme |
Ссылка(Reference) |
Нет |
Да |
ссылка на строку
раздела: Классификатор тем(в документе: Справочники канц.) |
Поскольку в процессе перехода к реализации существенно поменялась структура справочников, то я приведу и их новое описание:
Описание документа: Справочники канц. ( dir_ )
Документ входит в состав приложения: Канцелярия
Допускается существование только одного документа данного типа в информационной системе
Описание раздела: Тип ссылки(dir_reftype)
Тип ссылки
Коллекция строк
Структура раздела
Название |
Псевдоним |
Тип |
Можно не задавать |
кратко |
размер / ссылка на |
Тип |
reftypename |
Строка ограниченной
длины(String) |
Нет |
Да |
40 |
Описание раздела: Тип входящего(dir_inctype)
Тип входящего
Коллекция строк
Структура раздела
Название |
Псевдоним |
Тип |
Можно не задавать |
кратко |
размер / ссылка на |
Тип |
itype |
Строка ограниченной
длины(String) |
Нет |
Да |
40 |
Процесс обработки |
Process |
Ссылка(Reference) |
Да |
Нет |
ссылка на объект
типа: Определение процесса |
Свободная обработка |
UseProject |
Да / Нет(Boolean) |
Нет |
Нет |
|
Машина состояний |
StateMachine |
Ссылка(Reference) |
Да |
Нет |
ссылка на объект
типа: Описание машины состояний |
Название документа в
процессе |
ProcessDocumentName |
Строка ограниченной
длины(String) |
Да |
Нет |
255 |
Описание раздела: Отделы(dir_departments)
Отделы
Коллекция строк
Структура раздела
Название |
Псевдоним |
Тип |
Можно не задавать |
кратко |
размер / ссылка на |
Название отдела |
depname |
Строка ограниченной
длины(String) |
Нет |
Да |
80 |
Группа |
depgroup |
Ссылка(Reference) |
Да |
Нет |
ссылка на строку раздела: Группы |
Группы пользователей
для определения прав доступа(в документе: Данные о пользователях) |
|
|
|
|
|
Папка входящих |
incfolder |
Ссылка(Reference) |
Да |
Нет |
ссылка на строку
раздела: Папка(в документе: Каталог) |
Корневая папка |
rootfolder |
Ссылка(Reference) |
Да |
Нет |
ссылка на строку
раздела: Папка(в документе: Каталог) |
Префикс исходящего |
outprefix |
Строка ограниченной
длины(String) |
Да |
Нет |
10 |
Префикс входящего |
incprefix |
Строка ограниченной
длины(String) |
Да |
Нет |
10 |
Префикс приказа |
ordprefix |
Строка ограниченной
длины(String) |
Да |
Нет |
10 |
Постфиксисходящего |
outpostfix |
Строка ограниченной
длины(String) |
Да |
Нет |
10 |
Постфикс входящего |
incpostfix |
Строка ограниченной
длины(String) |
Да |
Нет |
10 |
Потфикс приказа |
ordpostfix |
Строка ограниченной
длины(String) |
Да |
Нет |
10 |
Папка исходящих |
outfolder |
Ссылка(Reference) |
Да |
Нет |
ссылка на строку
раздела: Папка(в документе: Каталог) |
Папка оперативных
указаний |
orderfolder |
Ссылка(Reference) |
Да |
Нет |
ссылка на строку
раздела: Папка(в документе: Каталог) |
Нумератор входящих |
incnumerator |
Ссылка(Reference) |
Да |
Нет |
ссылка на объект
типа: Нумератор |
нумератор исходящих |
outnumerator |
Ссылка(Reference) |
Да |
Нет |
ссылка на объект
типа: Нумератор |
нумератор приказов |
ordnumerator |
Ссылка(Reference) |
Да |
Нет |
ссылка на объект
типа: Календарь |
Описание раздела: Классификатор тем(dir_theme)
Классификатор тем
Коллекция строк
Структура раздела
Название |
Псевдоним |
Тип |
Можно не задавать |
кратко |
размер / ссылка на |
Название |
name |
Строка ограниченной
длины(String) |
Нет |
Да |
255 |
Комментарий |
Coment |
Мнегострочное поле
для ввода информации(Memo) |
Да |
Нет |
|
Ведущий рассылки: Михаил М. Баранов | |||
bami@murometz.spb.ru | www.murometz.spb.ru | Кубики для взрослых |
http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу |
В избранное | ||