Опытно-промышленная эксплуатация

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

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

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

Сопровождение и развитие системы

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

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

СЦЕНАРНЫЙ ПОДХОД

Диаграммы сценариев

Диаграммы прецедентов и их нотации. Что ж, у нас есть пример диаграммы. Итак, какие же элементы мы на ней видим? Первое, что бросается в глаза, - большой прямоугольник, внутри которого размещаются эллипсы, обозначающие, как мы уже поняли, прецеденты. В верхней части прямоугольника указано название моделируемой системы, а называют его рамками системы (system boundary, subject boundary), контекстом или просто системой. Этот элемент диаграммы показывает границу между тем, что вы как аналитик показали в виде прецедентов (внутри этих рамок), и тем, что вы изобразили как действующие лица (вне их). Чаще всего таким прямоугольником показывают границы самой моделируемой системы. То есть внутри границы находятся прецеденты - тот функционал, который реализует система (и в этом смысле прецеденты могут рассматриваться как представления подсистем и классов модели), а снаружи - действующие лица: пользователи и другие внешние сущности, взаимодействующие с моделируемой системой.

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

Кроме рамок системы или ее контекста на диаграмме мы видим еще два вида связанных с ней сущностей - это действующие лица (экторы, actors) и прецеденты. Начнем с экторов. Довольно часто в русскоязычной литературе по UML для обозначения действующих лиц можно встретить термин "актер". В принципе, смысл его более-менее понятен и оригинальному английскому термину он созвучен. Более того, есть еще одна причина такого перевода. Какое слово первым приходит к вам в голову, когда вы слышите слово "актер"? Да, конечно же - слово"роль"! Именно о ролях мы вскоре и поговорим, когда будем пытаться разобраться, что скрывается за понятием "действующее лицо". А пока, да простит нас читатель, далее мы все же будем пользоваться словом "эктор" - транскрипцией оригинального термина. Помнится, мы уже как-то писали о нашем отношении к буквальному переводу терминологии...

Итак, какой же смысл вкладывают в понятие эктора? Эктор - это набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью (системой, подсистемой, классом). Эктор может быть человеком, другой системой, подсистемой или классом, которые представляют нечто за пределами рассматриваемой сущности. Экторы "общаются" с системой путем обмена сообщениями. Четко выделив экторов, вы тем самым ясно определяете границу между тем, что внутри системы, и тем, что снаружи, - рамки системы.

Возможно, слова "роли, исполняемые пользователем" в определении эктора звучат не очень понятно. Очень забавно это понятие объясняется в Zicom Mentor:

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

На диаграммах UML экторы изображаются в виде стилизованных человечков, ведь, как вы, конечно, помните, идея была в создании нотации, любой символ которой легко может быть изображен от руки (рис 2.1):

Рис. 2.1.

Несмотря на "человеческий" вид этого обозначения, не следует забывать, что экторы - это не обязательно люди. Эктором, как мы уже говорили ранее, может быть внешняя система, подсистема, класс и т. д. Кстати, человечек ( "stick-person" ) - это не единственное обозначение эктора, используемое в UML. На диаграммах прецедентов обычно применяется именно "человекоподобная" форма эктора, но на других диаграммах, и особенно в случаях, когда эктор имеет атрибуты, которые важно показать, используется изображение эктора как класса со стереотипом <<actor>> (рис 2.2):

Рис. 2.2.

С системой экторы, как мы уже сказали, общаются через сообщения, но если говорить на более высоком уровне абстракции, в терминах модели прецедентов, то взаимодействуют они с системой через прецеденты. Один и тот же эктор может быть связан с несколькими прецедентами, и наоборот, один прецедент может быть связан с несколькими разными экторами. Ассоциации между эктором и прецедентом всегда бинарные - т. е. представляют отношения типа "один к одному", использование кратности недопустимо. Это не противоречит сказанному выше: действительно, один эктор может быть связан с несколькими прецедентами, но только с помощью отдельных ассоциаций - по одной на каждый прецедент. Мы видели это в нашем примере. Кстати, там мы видели ассоциации, изображенные не просто в виде линий, а стрелками. Думаем, смысл этого обозначения вполне понятен: это направленная ассоциация и стрелка (как и на других диаграммах) всегда направлена в сторону той сущности, от которой что-то требуют, чьим сервисом пользуются и т. д.

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

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

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

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

Рис. 2.3.

Внимательный читатель, возможно, отметил то, как незаметно мы ввели в употребление слово " сценарий ". Что же такое сценарий и как понятие сценария связано с понятием прецедента? На первый вопрос хорошо отвечают классики (Г. Буч):

Сценарий - это конкретная последовательность действий, иллюстрирующая поведение.

Сценарий - это повествовательный рассказ о совершаемых эктором действиях, история, эпизод, происходящий в данных временных рамках и данном контексте взаимодействия. Сценарии (в различных формах представления) широко применяются в процессе разработки программного обеспечения. Как мы уже только что отметили, написание сценария напоминает написание художественного рассказа, и этим объясняется тот факт, что использование сценариев широко распространено среди аналитиков, которые часто обладают художественными или литературными способностями. Несмотря на непрерывный повествовательный характер, сценарии можно рассматривать как последовательности действий (делать раскадровку ). При разработке пользовательского интерфейса сценарии описывают взаимодействие между пользователем (или категорией пользователей, например, администраторами системы, конечными пользователями) и системой. Такой сценарий состоит из последовательного описания комбинаций отдельных действий и задач (например, нажатий клавиш, щелчков поэлементам управления, ввода данных в соответствующие поля и т. д.). Вспомните, к примеру, описания последовательностей действий пользователя (предназначенных для достижения определенных результатов, решения определенных задач), которые вы находите в справке к малознакомой программе. То же самое можно сказать о модных сейчас "how-to videos", в которых такие последовательности отображаются визуально, на конкретных примерах. В любом случае, цель подобных справочных материалов - предоставить описание типичных сценариев использования системы, сценариев взаимодействия между пользователем и системой.

Сценарии также иногда можно увидеть на диаграмме прецедентов. Иногда их изображают в виде " листа бумаги ", на котором написано имя файла, - прямоугольника с загнутым нижним левым уголком. В этом случае указанный файл содержит в себе описание данного сценария. А иногда сценарий записывается в комментарий. Как вы, наверное, помните, комментарии (ноутсы, notes) изображаются прямоугольниками с загнутым верхним правым углом и соединяются с элементом, который они поясняют, пунктирной линией (рис 2.4).

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

Рис. 2.4.

Вот пример простого (неформализованного) текстового описания сценария (табл.2.1).

Таблица 2.1

Сценарий в табличном представлении

Пользователь вводит логин, пароль, адрес электронной почты и код подтверждения и нажимает кнопку "Далее". Система запрашивает ввод проверочного кода. Пользователь вводит код и нажимает кнопку "Далее". Система проверяет соответствие кода изображенному на картинке.

Не правда ли, знакомая процедура? Да, это описание регистрации пользователя на некотором сайте. Правда, не совсем полное: не рассмотрены случаи, когда выбранный пользователем логин уже занят, адрес электронной почты введен неправильно, пароль не удовлетворяет требованиям или код не соответствует изображенному на картинке. О таких случаях - альтернативных сценариях - мы поговорим чуть позже.

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

А пока попробуем ответить на второй вопрос, а именно: как связаны понятия сценария и прецедента. Прецеденты, как мы уже говорили, рождаются из требований к системе. Но говорят они о том, что делает система. Как система это делает, говорят сценарии. Таким образом, прецедент можно специфицировать путем описания потока действий или событий в текстовой форме - в виде, понятном для "постороннего" (не занятого в непосредственной разработке системы) читателя. А ведь такое описание - это и есть сценарий! Таким образом, сценарии специфицируют прецеденты. И еще. Поскольку сценарии - это, по сути, рассказы, они являются весьма эффективным средством извлечения информации из бесед с заказчиком и предоставляют превосходное, понятное непрофессионалу описание создаваемого приложения. Сценарии, да и вообще диаграммы прецедентов (дополненные сценариями) являются отличным средством общения между разработчиками и заказчиком, причем, в силу простоты нотации, - средством, понятным обеим сторонам. В конечном итоге, взаимосвязь между требованиями, прецедентами и сценариями можно изобразить такой "псевдодиаграммой" (рис 2.5).

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

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

Рис 2.5.

В диаграммах сценариев UML, актер - это роль объекта или объектов взаимодействующих с частью системы - соответствующим блоком сценария (use case). При этом актер - внешний по отношению к системе объект. Что мы подразумеваем под внешним объектом - это объекты, взаимодействующие с проектируемой системой, но при этом не являющиеся ее частью и которые обычно напрямую взаимодействуют с ее частью, но не имеют "непосредственного прямого" влияния на работу системы. Роли объекта - это роли, которые выполняет объект в различных сценариях. Т.е. объект может быть один, а выполняемых им ролей - несколько и таким образом он может моделироваться несколькими акторами.

Данная диаграмма действий этого проекта позволяет легко расписать действия, применяемые к проекту и все базе данных. Стрелками указаны основные действия актора. Пунктирные стрелки означают включаемые действия по отношению к общим они помечены заголовком <<include>>.

Диаграмма сценариев изображена на рисунке. Для пользователя (рис 2.6), для администратора (рис 2.7)

Рис. 2.6.

Рис. 2.7.

Не нашли, что искали? Воспользуйтесь поиском по сайту: