Если вы больше ничего не хотите...
Как!? А разве еще что-нибудь осталось? Осталось. Много. Восемь небольших статей о Lotus Notes и Domino способны возбудить интерес к предмету, но никак не удовлетворить его. Давайте договоримся: если вы, уважаемые читатели, захотите познакомиться с основами конструирования баз данных Notes, их форм, видов и агентов, то напишите о своих пожеланиях.
(c) Компьютерная газета
А напоследок разрешите рассказать о том, что должно подкупить любого специалиста, не понаслышке знающего, какого труда стоит работа, скромно и невыразительно называемая "поддержкой программного обеспечения". И заодно мы коснемся методологии разработки приложений в среде Lotus Notes.
Теоретически жизненный цикл программного обеспечения (именно так это и называется!) включает в себя минимум четыре стадии: постановку задачи, проектирование системы, разработку программного обеспечения и его поддержку, еще известную как сопровождение ПО. На практике первые три стадии зачастую очень нелегко различить, особенно для проектов небольшого масштаба, относящихся к категории разработки средств малой "настольной" автоматизации.
А вот сопровождения своих программ, насколько мне известно, еще никто не избегал, будь то именитая фирма или рядовой "халтурщик", если, конечно, заказчик этими программами действительно пользовался. Сопровождение включает в себя обучение и консультации конечных пользователей, устранение обнаруживающихся в ходе эксплуатации программ ошибок и модернизацию программ согласно текущим запросам заказчика.
Не будем говорить об обслуживании пользователей, к которому нередко привлекают непосредственных разработчиков ПО, - это совершенно отдельная тема. Устранение ошибок и модернизация: вот сущее проклятье специалиста, сопровождающего программное обеспечение. И дело даже не в том, что для этого требуется что-нибудь до- или перепрограммировать. Головная боль начинается в момент, когда следует в очередной раз заняться обновлением уже установленных и эксплуатируемых программ.
Типичная технология для баз данных FoxPro такова, что нужно пойти к заказчику, скопировать его данные, "погонять" на них программу, устранить ошибку и установить исправленную версию каждому из пользователей программы, даже тех, кто ни на что не жаловался. Последнее особенно важно, поскольку в противном случае различные версии программы начнут плодиться с энтузиазмом кроликов и положение очень быстро станет неуправляемым.
Не лучше обстоит дело у разработчиков баз данных MS Access, которые любят подчеркивать, что с легкостью могут устранять ошибки в ПО прямо на рабочем месте пользователя, так как MS Access служит одновременно и средой пользователя и средой разработки. Проблема та же: нужно посетить заказчика, а потом распространить сделанные изменения. Не обходить же программисту каждое рабочее место, внося изменения в код по памяти!
Для борьбы с указанными трудностями широко применяется метод рассылки обновлений, будь то с использованием электронных коммуникаций или рассылки дискет или компакт-дисков. Это, конечно, решает проблему, но решение не идеально, так как каждое обновление требует переустановки и/или восстановления конфигурации программного обеспечения и данных. Однако существует и другой подход, демонстрируемый Lotus Notes.
С точки зрения Lotus Notes база данных и приложение, то есть программа, управляющая базой, неразделимы. И уж не знаю, следовала ли реализация из концепции, или наоборот, но дизайн, конструкция базы данных хранится в самой базе в виде обыкновенных документов. Одним из следствий данной архитектурной особенности Notes является тот факт, что репликация различных экземпляров базы данных приводит не только к синхронизации пользовательских документов, но и к синхронизации документов, описывающих дизайн базы.
Теперь можно говорить о схеме поддержки приложений (БД) Notes в масштабах одной организации, охваченной системой компьютерных коммуникаций. Программисту, осуществляющему сопровождение, достаточно произвести необходимые изменения и дополнения в конструкции своего локального экземпляра базы данных, убедиться, что они отлажены, и произвести репликацию с сервером. Пользователи, работающие с серверным экземпляром базы, изменения "увидят" немедленно, а те, у кого стоят локальные реплики, получат изменения после очередной репликации.
Таким образом устраняется необходимость в явной переустановке программного обеспечения и личного посещения пользователей обслуживающим персоналом. Кроме того, все пользователи, сами того не зная, будут получать абсолютно все изменения. Иными словами, проблемы разрастания количества одновременно применяемых версий не существует: изменения в ПО распространяются автоматически и очень быстро. И еще я не упомянул, что репликация осуществляется не только между сервером и конечным пользователем, но и между серверами организации.
Внимательный читатель мог обратить внимание на оговорку, согласно которой схема распространения изменений путем репликации баз данных подходит для сопровождения ПО в рамках одной организации. А как быть со сторонними организациями, программное обеспечение которых нуждается в обслуживании? Сразу можно сказать только одно: приведенная схема не подходит по соображениям безопасности. Для репликации с сервером нужно быть на нем зарегистрированным. Не думаю, что найдется много учреждений, согласных допустить в свою внутреннюю сеть посторонних, хотя бы и с целью сопровождения ПО.
Есть, однако, и другая схема, основанная на концепции шаблонов баз данных Notes, которая немного сложнее, но во многих отношениях лучше. Итак, программист, разработавший базу данных, имеет возможность преобразовать ее в так называемый шаблон. Пользователь, заводя базу данных, выбирает шаблон, документы дизайна которого копируются во вновь создаваемую БД. При создании БД устанавливается режим наследования изменений от шаблона. Каждое изменение в шаблоне сервер автоматически распространяет на все базы, созданные на его основе.
Дальше события развиваются следующим образом. Программист, осуществляющий поддержку, "курочит" свою локальную, нереплицируемую базу данных, не опасаясь, что случайно попортит рабочий экземпляр или удалит реальные данные, а изменения бесконтрольно разойдутся путем репликации. В тот момент, когда он окончательно решит, что отладил новую версию БД, программист внесет соответствующие изменения в шаблон на сервере. Другие серверы получат изменения шаблона по репликации и обновят дизайн рабочих баз данных. Ну разве не прелесть?
Таким образом, можно включить в схему поддержки и сторонние организации, для которых операция обновления ПО отныне будет сводиться к замене имеющегося на сервере шаблона новым. Все остальное сделает механизм обновления и репликации в пределах локальной сети заказчика. Ну, а получать обновления шаблонов по электронной почте, не жертвуя безопасностью своей сети, согласится всякий.
Отдельного упоминания заслуживает влияние, которое оказала описанная технология распространения изменений в ПО, на методологию разработки в среде Lotus Notes. Легкость модификации баз данных привела к тому, что корпорация Lotus Development рекомендует программистам заниматься протоциклированием. Говоря по-человечески, процесс разработки превращается в процедуру многократной переработки прототипа.
Самое примечательное, что к участию в процессе пользователей рекомендуется подключають на самой ранней стадии, практически сразу после того, как в общих чертах "сляпан" макет пользовательского интерфейса. Через день-другой они опрашиваются, в макет вносятся изменения и все повторяется снова. Говорят, что подобных циклов должно быть шесть-семь. Этот подход коренным образом отличается от привычного, когда речь идет о единственном этапе опытной эксплуатации и последующей отладке продукта, созданного полностью вне постоянного контакта с пользователями.
Вот, пожалуй, и все. Итак, если вы больше ничего не хотите...
Евгений Щербатюк
(c) Компьютерная газета
А напоследок разрешите рассказать о том, что должно подкупить любого специалиста, не понаслышке знающего, какого труда стоит работа, скромно и невыразительно называемая "поддержкой программного обеспечения". И заодно мы коснемся методологии разработки приложений в среде Lotus Notes.
Теоретически жизненный цикл программного обеспечения (именно так это и называется!) включает в себя минимум четыре стадии: постановку задачи, проектирование системы, разработку программного обеспечения и его поддержку, еще известную как сопровождение ПО. На практике первые три стадии зачастую очень нелегко различить, особенно для проектов небольшого масштаба, относящихся к категории разработки средств малой "настольной" автоматизации.
А вот сопровождения своих программ, насколько мне известно, еще никто не избегал, будь то именитая фирма или рядовой "халтурщик", если, конечно, заказчик этими программами действительно пользовался. Сопровождение включает в себя обучение и консультации конечных пользователей, устранение обнаруживающихся в ходе эксплуатации программ ошибок и модернизацию программ согласно текущим запросам заказчика.
Не будем говорить об обслуживании пользователей, к которому нередко привлекают непосредственных разработчиков ПО, - это совершенно отдельная тема. Устранение ошибок и модернизация: вот сущее проклятье специалиста, сопровождающего программное обеспечение. И дело даже не в том, что для этого требуется что-нибудь до- или перепрограммировать. Головная боль начинается в момент, когда следует в очередной раз заняться обновлением уже установленных и эксплуатируемых программ.
Типичная технология для баз данных FoxPro такова, что нужно пойти к заказчику, скопировать его данные, "погонять" на них программу, устранить ошибку и установить исправленную версию каждому из пользователей программы, даже тех, кто ни на что не жаловался. Последнее особенно важно, поскольку в противном случае различные версии программы начнут плодиться с энтузиазмом кроликов и положение очень быстро станет неуправляемым.
Не лучше обстоит дело у разработчиков баз данных MS Access, которые любят подчеркивать, что с легкостью могут устранять ошибки в ПО прямо на рабочем месте пользователя, так как MS Access служит одновременно и средой пользователя и средой разработки. Проблема та же: нужно посетить заказчика, а потом распространить сделанные изменения. Не обходить же программисту каждое рабочее место, внося изменения в код по памяти!
Для борьбы с указанными трудностями широко применяется метод рассылки обновлений, будь то с использованием электронных коммуникаций или рассылки дискет или компакт-дисков. Это, конечно, решает проблему, но решение не идеально, так как каждое обновление требует переустановки и/или восстановления конфигурации программного обеспечения и данных. Однако существует и другой подход, демонстрируемый Lotus Notes.
С точки зрения Lotus Notes база данных и приложение, то есть программа, управляющая базой, неразделимы. И уж не знаю, следовала ли реализация из концепции, или наоборот, но дизайн, конструкция базы данных хранится в самой базе в виде обыкновенных документов. Одним из следствий данной архитектурной особенности Notes является тот факт, что репликация различных экземпляров базы данных приводит не только к синхронизации пользовательских документов, но и к синхронизации документов, описывающих дизайн базы.
Теперь можно говорить о схеме поддержки приложений (БД) Notes в масштабах одной организации, охваченной системой компьютерных коммуникаций. Программисту, осуществляющему сопровождение, достаточно произвести необходимые изменения и дополнения в конструкции своего локального экземпляра базы данных, убедиться, что они отлажены, и произвести репликацию с сервером. Пользователи, работающие с серверным экземпляром базы, изменения "увидят" немедленно, а те, у кого стоят локальные реплики, получат изменения после очередной репликации.
Таким образом устраняется необходимость в явной переустановке программного обеспечения и личного посещения пользователей обслуживающим персоналом. Кроме того, все пользователи, сами того не зная, будут получать абсолютно все изменения. Иными словами, проблемы разрастания количества одновременно применяемых версий не существует: изменения в ПО распространяются автоматически и очень быстро. И еще я не упомянул, что репликация осуществляется не только между сервером и конечным пользователем, но и между серверами организации.
Внимательный читатель мог обратить внимание на оговорку, согласно которой схема распространения изменений путем репликации баз данных подходит для сопровождения ПО в рамках одной организации. А как быть со сторонними организациями, программное обеспечение которых нуждается в обслуживании? Сразу можно сказать только одно: приведенная схема не подходит по соображениям безопасности. Для репликации с сервером нужно быть на нем зарегистрированным. Не думаю, что найдется много учреждений, согласных допустить в свою внутреннюю сеть посторонних, хотя бы и с целью сопровождения ПО.
Есть, однако, и другая схема, основанная на концепции шаблонов баз данных Notes, которая немного сложнее, но во многих отношениях лучше. Итак, программист, разработавший базу данных, имеет возможность преобразовать ее в так называемый шаблон. Пользователь, заводя базу данных, выбирает шаблон, документы дизайна которого копируются во вновь создаваемую БД. При создании БД устанавливается режим наследования изменений от шаблона. Каждое изменение в шаблоне сервер автоматически распространяет на все базы, созданные на его основе.
Дальше события развиваются следующим образом. Программист, осуществляющий поддержку, "курочит" свою локальную, нереплицируемую базу данных, не опасаясь, что случайно попортит рабочий экземпляр или удалит реальные данные, а изменения бесконтрольно разойдутся путем репликации. В тот момент, когда он окончательно решит, что отладил новую версию БД, программист внесет соответствующие изменения в шаблон на сервере. Другие серверы получат изменения шаблона по репликации и обновят дизайн рабочих баз данных. Ну разве не прелесть?
Таким образом, можно включить в схему поддержки и сторонние организации, для которых операция обновления ПО отныне будет сводиться к замене имеющегося на сервере шаблона новым. Все остальное сделает механизм обновления и репликации в пределах локальной сети заказчика. Ну, а получать обновления шаблонов по электронной почте, не жертвуя безопасностью своей сети, согласится всякий.
Отдельного упоминания заслуживает влияние, которое оказала описанная технология распространения изменений в ПО, на методологию разработки в среде Lotus Notes. Легкость модификации баз данных привела к тому, что корпорация Lotus Development рекомендует программистам заниматься протоциклированием. Говоря по-человечески, процесс разработки превращается в процедуру многократной переработки прототипа.
Самое примечательное, что к участию в процессе пользователей рекомендуется подключають на самой ранней стадии, практически сразу после того, как в общих чертах "сляпан" макет пользовательского интерфейса. Через день-другой они опрашиваются, в макет вносятся изменения и все повторяется снова. Говорят, что подобных циклов должно быть шесть-семь. Этот подход коренным образом отличается от привычного, когда речь идет о единственном этапе опытной эксплуатации и последующей отладке продукта, созданного полностью вне постоянного контакта с пользователями.
Вот, пожалуй, и все. Итак, если вы больше ничего не хотите...
Евгений Щербатюк
Компьютерная газета. Статья была опубликована в номере 46 за 1999 год в рубрике soft :: субд
