Задачей информационной модели является отображение существующих типов информации и связей, которые могут или должны существовать между ними.
Будет также полезно рассмотреть диаграммы состояний, использующиеся для описания того, как с течением времени изменяется состояние каждого типа информации, что дает наглядное представление о том, когда и как происходит информационное взаимодействие между процессами.
Классы информации.
.
В контексте общего процесса нами уже рассмотрены следующие типы информации:.
• входящие требования;.
• производные требования;.
• стратегия проверки для входящих требований;.
• стратегия проверки для производных требований;.
• запрос на изменение.
На рис. 2.7 эти пять типов информации представлены в виде диаграммы классов UMLмодели.
Название класса всегда указывается в самой верхней (часто она же и единственная) части прямоугольника, обозначающей класс. Средняя часть (если она существует) содержит название атрибутов, которые может иметь класс. В нижней же части (если она
Рис. 2.7 Информационная модель общего процесса.
Линии, соединяющие классы, обозначают связи между ними. В UML эти связи также называют «ассоциациями». Как следует из диаграммы, входящее требование может быть связано с производным требованием связью «удовлетворяется». Аналогично производное требование может быть связано с входящим требованием связью «удовлетворяет». (Обозначение связи в UML также называют «ролью».)
существует) перечисляются названия операций класса (часто также называемых «методами»), которыми может оперировать класс.
Звездочкой обозначается, что ноль или более экземпляров класса могут быть вовлечены в ассоциацию. Звездочки на обоих концах ассоциации обозначают, что ассоциация имеет тип многие ко многим.
Следовательно, в модели на рис. 2.7 ноль или более входящих требований могут быть удовлетворены одним производным требованием, и входящее требование может быть удовлетворено нулем или более производных требований.
Некоторые читатели могут засомневаться в том, что нижнем уровнем должен быть ноль, ведь в этом случае нет необходимости иметь ассоциацию вообще? Однако это необходимо и вот почему. Представьте себе, что нижний уровень все-таки был бы равен единице, тогда это означало бы, что входящее требование просто не могло бы существовать до тех пор, пока оно не было бы ассоциировано с хотя бы одним производным требованием. Естественно, что такая ситуация неприемлема. Входящие требования должны существовать еще до того, как появятся производные требования. Следовательно, нулевой уровень - это вполне нормальная ситуация, поскольку периодически в процессе работы могут отсутствовать связи между входящими и производными требованиями (например, на ранних стадиях разработки, когда связи еще не установлены). Тем не менее, руководитель проекта должен следить за тем, чтобы связи устанавливались как можно раньше. С помощью связей можно оценить, какой объем работы уже выполнен; определить, что все производные требования удовлетворяют входящие требования, и, наоборот, что все вхоящие требования удовлетворяются производными требованиями.
Каждый из классов стратегии проверки (правая часть рисунка) оценивает соответствующий тип требований. При этом стратегия проверки производных требований может предусматривать большую детализацию, нежели стратегия проверки входящих требований. Такой подход, например, может применяться при разработке систем, связанных с потенциальной опасностью для жизни и здоровья людей. В этом случае необходимо делать более детальные низкоуровневые проверки, совокупность которых помогает удовлетворить критерии проверки более высокого уровня.
Как отмечалось ранее, разработка стратегии проверки может привести к необходимости разработки специальных тестовых стендов или установок. В этом случае появляются связи типа налагает между стратегией проверки для входящих требований и одним или более производных требований. Хорошим примером появления связи такого типа может быть случай, когда (чтобы в дальнейшем проверить компонент) возникает необходимость установить некую контрольную точку (monitor point). Такие контрольные точки часто нужны для проверки производительности системы в реальных рабочих условиях (скорость, время отклика, пропускная способность и т.д.).
Запрос на изменение может относиться к любому из перечисленных четырех классов.
На диаграмме это показано с помощью прямоугольника, который охватывает все четыре класса, и наличия связи между этим прямоугольником и запросом на изменение.
Как уже упоминалось выше, средняя часть символа класса служит для отражения имеющихся атрибутов класса. Классы требований имеют три атрибута:.
• статус согласования;.
• статус проверки;.
• статус удовлетворения.
Эти атрибуты описываются в последующих разделах с помощью диаграмм состояний. Статус согласования для классов стратегии проверки подразумевает только два возможных значения:.
- согласованно.
- несогласованно.
2.5.2 Статус согласования.
Диаграмма состояний для статуса согласования представлена на рис. 2.8.
На диаграммах данного типа каждый прямоугольник с закругленными углами отражает состояние одного требования в некий момент времени его истории.
Прямоугольник, помеченный заголовком Оценка, называется «супер-состоянием» (superstate) поскольку содержит внутри себя другие состояния. Стрелки, связывающие между собой разные состояния, обозначают переходы, вызывающие изменение состояния.
В самом начале требование возникает в состоянии (статусе) Предложено. Затем заказчик - как только посчитает формулировку требования достаточно удовлетворительной - посылает это требование поставщику. Статус согласования требования меняется на суперсостояние Оценка. В рамках этого состояния поставщик и заказчик могут проводить многократные согласования требования до тех пор, пока требование не станет окончательно согласованным, - тогда оно меняет свой статус на Согласовано.
Рис. 2.8 Диаграмма состояний статуса согласования.
Согласованное требование остается в этом состоянии до тех пор, пока кто-либо заказчик или поставщик - не создаст запрос на изменение для этого требования. Если это происходит, то требование вновь возвращается в супер-состояние Оценка и имеет этот статус до тех пор, пока вновь не станет согласованным.
Как видно из рисунка, внутри супер-состояния Оценка заказчик и поставщик по очереди предлагают альтернативные формулировки требования пока вновь не придут к согласию. Следовательно, внутри супер-состояния Оценка требование может находиться только в одном из двух состояний - в зависимости от того, какая из сторон в данный момент производит оценку требования.
2.5.3 Статус проверки.
На рис. 2.9 представлена диаграмма состояний для статуса проверки требования. Начальное состояние - Стратегия проверки не определена.
Рис. 2.9 Статус проверки.
В этом состоянии статус проверки требования находиться до момента предложения изменения. При этом надо иметь в виду, что изменение может быть предложено как в отношении самого требования, так и для стратегии проверки, связанной с данным требованием.
После согласования стратегии проверки требования, статус проверки переходит в состояние Стратегия проверки определена.
В случае прихода запроса на изменение, статус проверки переходит в состояние Стратегия проверки сомнительна и остается в этом состоянии на время проведения анализа влияния возможного изменения. В результате анализа должно быть четко определено влияет ли предлагаемое изменение на стратегию проверки. Если не влияет, то стратегия проверки остается прежней, а статус проверки возвращается в состояние Стратегия проверки определена. В случае, если предлагаемое изменение оказывает влияние на стратегию проверки, то ее необходимо пересмотреть, и в этом случае статус проверки переходит в Стратегия проверки не определена.
2.5.4 Статус удовлетворения.
Диаграмма состояний для статуса удовлетворения требования представлена на рис. 2.10. Диаграмма очень похожа на диаграмму состояний статуса проверки.
Начальной точкой является состояние Неудовлетворенно, что означает отсутствие производных требований связанных с данным требованием. После того, как входящее требование удовлетворено одним или несколькими производными требованиями, и при этом «поставщик» с более низкого уровня согласовал требования, а «заказчик» с более высокого уровня согласился с тем, что производные требования удовлетворяют входящее требование, статус удовлетворения может смениться на Удовлетворено. Необходимо заметить, что возможно потребуется согласовать много производных требований для того, чтобы каждое конкретное входящее требование имело статус Удовлетворено.
Рис. 2.10 Статус удовлетворения.
Сразу же после предложения изменения статус удовлетворения переходит в состояние Удовлетворенность сомнительна, независимо от того, направлено ли предложенное изменение на требование верхнего или нижнего уровня. Этот статус сохраняется до тех пор, пока не произведен анализ предложенного изменения, и статус удовлетворения не переведен или в состояние Неудовлетворенно, или в состояние Удовлетворенно.
2.5.5 Внутренние связи информационной модели.
Запросы на изменение связывает между собой статусы согласования, проверки и удовлетворения. Получение (регистрация) запроса на изменение меняет сразу же все три состояния (их статус) и приводит к необходимости проведения дополнительной работы: вопервых, - необходимо оценить возможное влияние предлагаемого изменения, а во-вторых, если влияние существует, - необходимо правильно его адресовать, чтобы принять меры для его адаптации. Необходимо также учитывать, что статус удовлетворения может волнообразно «раскачиваться» вверх-вниз, поскольку все требования связанны между собой связями удовлетворения. Этот «волновой» эффект определяет потенциальные рамки любых побочных изменений, определяя, тем самым, степень «влияние» предложенного изменения.
Статус согласования для производных требований должен находиться в соответствии со статусом удовлетворения входящих требований, поскольку входящее требование не может стать удовлетворенным до тех пор, пока поставщик с нижнего уровня не согласует все производные требования, удовлетворяющие это входящее требование.