Компьютер в бухгалтерском учете и аудите 1998'3
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Концепция визуального проектирования
в инструментальной среде “Тектон”

Традиционный подход к автоматизации хозяйственной деятельности предприятий, предполагающий использование набора автоматизированных рабочих мест (АРМ), обладает существенными недостатками. Эти недостатки, имеющие принципиальный характер, заметно снижают эффективность самого процесса автоматизации и ведут к многочисленным непроизводительным затратам времени и ресурсов.

Недостатки классического подхода к проектированию АРМ

Поясним сказанное на конкретном примере.

Как разрабатывается типичный набор АРМ?

Процесс разработки состоит из нескольких этапов, каждый из которых имеет свои особенности.

На первом этапе конечный пользователь (например, бухгалтер, кассир и т.п.) ставит перед бизнес-аналитиком задачу на создание АРМ.

Однако бизнес-аналитик, детально знакомый с прикладной областью пользователя, не является программистом. Он не в состоянии самостоятельно запрограммировать АРМ с использованием традиционных средств, предназначенных для решения этой задачи. В самом деле, такие средства разработки, как Delphi, N++, Fox Pro и т.п., с применением которых создаются обычные АРМ, предназначены для профессиональных программистов.

Дополнительную сложность представляет процесс создания структуры базы данных. Для того чтобы правильно формировать базу данных для приложений технологии клиент-сервер, необходимо детально знать принципы функционирования реляционных баз данных.

Если необходимо дополнить структуру базы данных несколькими таблицами, или полями в уже существующую таблицу, справиться с этим в состоянии только подготовленный специалист.

Поэтому бизнес-аналитик, получивший задание на разработку АРМ от пользователя, ставит эту задачу перед программистом или перед группой программистов.

Программисты не знакомы с предметной областью настолько, насколько с ней знаком бизнес-аналитик. Они просто реализуют задание последнего настолько хорошо, насколько хорошо его понимают.

Далее бизнес-аналитик принимает готовый АРМ у программистов, высказывает им свои замечания и, как правило, тут же отправляет на доработку. После нескольких промежуточных шагов готовый АРМ передается конечному пользователю.

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

В итоге бизнес-аналитик снова передает АРМ на доработку программистам, и эта доработка, возможно, будет выполнена не за одну итерацию.

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

Сказанное иллюстрируется на рис. 1.1.

Рис. 1.1. Замкнутый круг процесса разработки АРМ

Как видно из этого рисунка, конечные пользователи могут выдавать задания на изменение АРМ не только бизнес-аналитикам, но и непосредственно группе программистов. Такое часто встречается на практике и ведет к еще большему запутыванию процесса разработки.

Кроме того, дополнительные проблемы появляются при необходимости внести изменения в разработанную систему. Она может возникнуть, например, при изменении нормативных документов, регулирующих деятельность предприятия, при перераспределении обязанностей сотрудников на предприятии. Даже минимальное изменение в форме отчета или добавление нового поля к документу, особенно первичному, может повлечь за собой повторение полного цикла прохождения заданий от конечного пользователя к бизнес-аналитику, а затем к группе программистов.

В результате для сопровождения традиционных АРМ приходится либо держать на предприятии штат программистов (что обходится очень недешево), либо обращаться по каждому мелкому или крупному вопросу к фирме-разработчику. А это опять-таки требует затрат времени и денег.

Концепция, принятая в системе Тектон

Компания “ИнтелГрупп”, уже много лет занимающаяся управленческим консультированием и проектированием информационных систем для автоматизации хозяйственной деятельности предприятий, проанализировала недостатки традиционного подхода, перечисленные выше. На основе этого анализа, а также собственного опыта создания информационных систем для предприятий, была разработана новая концепция.

Эта концепция предполагает создание специализированного инструмента для реализации решений, предлагаемых конечными пользователями, и ориентированного не на программистов, а на бизнес -аналитиков.

В основе концепции лежат следующие принципы:

• реализация информационной системы конкретного предприятия должна происходить без привлечения программистов;
• любые изменения форм документов, коэффициентов, форм выдачи и т. п. не должны влиять на работоспособность информационной системы;
• пользователь изменяет или создает шаблоны, процедуры, документы и отчеты, а за структуру базы данных отвечает само программное средство;
• система должна иметь простой пользовательский интерфейс, обеспечивающий минимально необходимые возможности. Тем не менее, по мере изучения системы перед пользователем должны открываться все большие и большие возможности.

Две грани системы Тектон

В результате практической реализации новой концепции была создана объектно-ориентированная система Тектон-Дизайнер (дальше — просто Тектон), предназначенная для автоматизации хозяйственной деятельности предприятий.

Эта система выступает в двух ипостасях: как инструмент для бизнес-аналитика и как виртуальный АРМ для конечного пользователя.

Приступая к автоматизации конкретной прикладной области, бизнес-аналитик получает задание от конечного пользователя. Применяя Тектон как инструмент, он создает набор документов, отчетов, шаблонов и процедур, а также выполняет другие необходимые действия, формируя виртуальный АРМ.

Иными словами, бизнес-аналитик настраивает Тектон под конкретную прикладную область, создавая в процессе такой настройки инструмент для конечного пользователя. Полученный инструмент будет применяться для решения задач, возлагаемых при традиционном подходе на классические АРМ. При подключении к системе конечный пользователь вводит свой пароль, после чего система Тектон показывает себя в том виде, в котором это было предусмотрено при настройке. Заметим, что бизнес-аналитик может задавать для разных пользователей разные права доступа к отдельным объектам системы, что во многих случаях просто необходимо.

Существенно, что в процессе такой настройки не требуется привлекать профессиональных программистов. Практически вся работа может быть сделана бизнес-аналитиком с использованием готовых объектов, заложенных программистами в систему Тектон. Разумеется, при необходимости бизнес-аналитик может заказывать дополнительные компоненты, обращаясь к программистам компании “ИнтелГрупп” или к сторонним разработчикам. Заметим, что такая необходимость будет возникать достаточно редко — практически все, что может потребоваться бизнес-аналитику, уже заложено в системе Тектон и готово к использованию.

В результате цикл разработки информационной системы для автоматизации прикладной деятельности сильно упрощается (рис. 1.2).

Рис. 1.2. Цикл разработки при использовании концепции Тектон

Фактически все взаимодействие происходит между конечным пользователем и бизнес-аналитиком. Ни тот, ни другой не являются программистами, но оба они владеют прикладной областью и потому легко найдут общий язык. Разработка прикладной информационной системы ведется бизнес-аналитиком в терминах прикладной области без привлечения каких-либо традиционных языков программирования или классических систем проектирования приложений.

Что же касается взаимодействия бизнес-аналитиков с программистами, то оно ограничивается заказом новых компонентов для системы Тектон. Создание таких компонентов не требует детального знакомства с прикладной областью, и потому на этом этапе так же легко достигнуть взаимопонимания между бизнес-аналитиками и программистами.

Таким образом, Тектон — это инструмент, посредством которого можно смоделировать любую прикладную область, описываемую в виде потока документов. При описании предметной области создается набор виртуальных АРМ, позволяющий работать с документами, обмениваться информацией, управлять потоком документов и анализировать его.

В итоге получилась система, которая изначально управляется данными. Являясь объектно-ориентированной, она представляет пользователю возможность работать в его прикладной области. При этом пользователь, работающий с виртуальным АРМ Тектон, не имеет понятия о базе данных. Он работает с тем, чем он привык — документами, папками, карточками, накладными и так далее.

Преимущества нетрадиционного подхода, использованного в Тектон

Подводя итог сказанному, перечислим основные преимущества нового подхода, использованного при создании системы Тектон:

• цепочка заказчик-исполнитель сокращается в три раза, что приводит к значительной экономии времени на разработку и согласование;
• разработчик системы (бизнес-аналитик) очень хорошо владеет предметной областью. При этом разработка ведется с использованием понятий, пригодных для описания бизнес-процессов и доступных конечному пользователю. Это позволяет описать прикладную задачу быстро, наиболее полно и точно;
• для внесения изменений в систему не требуется привлечение программистов — все можно сделать силами бизнес-аналитиков;
• в системе Тектон применен простой интуитивно понятный интерфейс, не требующий длительного и дорогостоящего обучения пользователей;
• при изменении круга задач, решаемых конечным пользователем, настройка рабочих мест выполняется несложно;
• есть возможность анализа документооборота предприятия;
• с помощью системы Тектон возможно прогнозирование типа “что будет, если…”

Первый взгляд на Тектон>

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

Из чего состоит система Тектон

Основные компоненты системы Тектон показаны на рис. 2.1. Это главный модуль, база данных, дизайнер форм, дизайнер отчетов и дизайнер процедур.

Рис. 2.1. Основные компоненты системы Тектон

Главный модуль системы является приложением, предназначенным как для бизнес-аналитика, так и для конечного пользователя. С помощью органов управления, расположенных в его окне (рис. 2.2), бизнес-аналитик настраивает Тектон на конкретную предметную область. В дальнейшем этот же модуль будет запускаться конечным пользователем виртуального АРМ.

Для хранения всей информации, накопленной системой, применяется база данных. Она может располагаться как локально на компьютере бизнес-аналитика или конечного пользователя, так и на сервере локальной сети. Для защиты от различных сбоев при работе с базой данных применяется механизм транзакций. Важно то, что этот механизм работает на уровне документов и процедур, а не физических записей базы данных. Иными словами, транзакция заканчивается не при изменении или добавлении записи в базу данных, а когда пользователь заканчивает работу с документом. В результате достигается повышенная надежность хранения данных в системе.

Рис. 2.2. Главное окно системы Тектон

Благодаря чему?

Представьте себе ситуацию, когда пользователь выполняет операцию, затрагивающую сразу несколько документов. В процессе выполнения этой операции происходят многократные обращения к базе данных для обновления или добавления записей, имеющих отношение к обрабатываемым документам. При этом в любой момент возможно возникновение сбоя системы, в результате которого наполовину сделанная операция будет прервана. При этом часть записей базы данных будет изменена, а часть — нет. Чтобы целостность данных, хранимых в системе, не была нарушена, необходимо отменить изменения, сделанные до момента аварийной остановки системы.

В то же время обычные СУБД способны отслеживать неполные изменения только отдельных записей, но не документов — ведь СУБД “не знает” структуры вашей информации.

В системе Тектон производиться отмена операций над документами, выполненных не полностью. Поэтому в ней никогда не появятся документы, обработанные “наполовину”.

Еще один важный момент.

Система Тектон выполняет отслеживание и сохранение всех событий, происходящих в системе. То есть любые действия (даже ошибочные) оставляют свой след и могут быть проанализированы. В результате становится возможным анализ поведения системы в целом и, что интересно, прогнозирование по схеме “что было бы если…”. А такая информация представляет собой большой интерес для верхнего уровня руководства фирмы.

Заметим, что в процессе работы внутренняя структура базы данных остается скрытой как от конечного пользователя, так и от бизнес-аналитика. Она остается одной и той же вне зависимости от конкретной прикладной области, для которой настраивается Тектон.

Дизайнеры форм, отчетов и процедур нужны только для бизнес-аналитиков. Они предназначены для проектирования объектов системы Тектон в процессе ее настройки на прикладные области и потому не нужны конечному пользователю.

Что проектируется с помощью дизайнеров?

Дизайнер форм (рис. 2.3) нужен для формирования набора полей документов, а также для создания внешнего представления документов при их отображении на экране или при печати на принтере. Процесс создания форм не требует программирования и заключается в перетаскивании мышью готовых компонентов из палитры с определением свойств этих компонентов. Формы проектируются в визуальном режиме. Этот процесс несложен и вполне доступен бизнес-аналитику, не искушенному в вопросах программирования.

Аналогично дизайнер отчетов (рис. 2.4) позволяет конструировать отчеты. При этом определяются набор полей, входящих в отчет, внешний вид отчета при его просмотре на экране и печати на принтере, осуществляется подключение необходимых процедур и так далее. Так же как и дизайнер форм, дизайнер отчетов работает в режиме визуального проектирования.

Рис. 2.3. Главное окно дизайнера форм

Рис. 2.4. Главное окно дизайнера отчетов

С помощью дизайнера процедур (рис. 2.5) бизнес-аналитик может подготавливать процедуры обработки документов, хранящихся в системе.

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

Основные понятия системы Тектон

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

Продолжение следует…..

Тараненко Андрей Георгиевич

С вопросами и предложениями обращайтесь digraph@rinet.ru

Copyright © 1994-2016 ООО "К-Пресс"