Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Metodologia_SSADM.doc
Скачиваний:
67
Добавлен:
13.04.2015
Размер:
1.47 Mб
Скачать

3.9.12. Представление лмд пользователю.

Очень важно, чтобы пользователь проверил точность каждой разработанной ЛМД. Поэтому необходимо на регулярной и неформальной основе обсудить с пользователем и остальными членами проектной группы эти модели и факторы, обеспечивающие их точность. Официально ЛМД представляется на рассмотрение по окончании этапов 110, 140, 320, 340, и 360.

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

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

В процессе представления модели не рекомендуется сразу показывать полную схему. Сначала даются понятия и определения по каждому обозначению так, как будто это делается впервые. Модель выстраивается для пользователя постепенно по частям (на одну часть не более пяти новых объектов), что позволяет показать ему различные аспекты информационных требований, сохраняя при этом структуру модели достаточно стабильной.

3.9.13. Документирование лмд.

Составление документации на ЛМД - процесс, протекающий на всем протяжении этапов 140, 320, 340, и 360. Документация обеспечивает поддержку достоверности ЛМД.

По окончании стадии 3 ЛМД требуемой системы будет состоять из окончательной ЛСД и заполненных описаний объектов, атрибутов и сгруппированных доменов (за исключением индикаторов состояния, которые добавляются в "Описание объект» на этапе 520). Руководство по заполнению форм описаний приведено в приложении 2.

Обобщенная ЛСД не обеспечивается поддерживающей документацией.

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

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

ЛМД требуемой системы получается на этапе 320 путем модификации и расширения соответствующей ЛМД существующего системного окружения, исходя из информации о требованиях к новой системе, определяемых выбранной структуре проектируемой системы и содержащихся в "Каталоге требовании". На этом этапе должны быть заполнены формы с детальным описанием всех объектов, связей, атрибутов и сгруппированных доменов. Требования к новым данным должны быть обработаны так, чтобы можно было показать, где и как эти данные отражены на ЛМД.

Нефункциональные требования к ЛМД, содержащиеся в "Каталоге требовании", используются для внесения поправок в нее на этапе 320. Эти требования обычно

характеризуют уровень обслуживания, ограничения по доступу к данным, защиту данных, внешний надзор и управление, а также другие ограничения. Нефункциональные требования тоже должны быть обработаны так, чтобы можно было показать, где и как они отражены на ЛМД. Некоторые нефункциональные требования высокого уровня не могут быть полностью отражены на ЛМД, однако это должно упоминаться в "Каталоге требований". ЛМД, полученная как результат работ, выполненных на этапе 320, может потребовать дополнительных исследовании для дальнейшего уточнения модели.

Уже на стадии 1 удобно начинать документирование объемов объектов и связей. Это может помочь при выборе организационной структуры системы, а также потребуется при оценке пропускной способности и выборе структуры технических средств системы. После того как на этапе 360 получена ЛМД требуемой системы, на копии ЛДС можно отметить объемы объектов и связей (см. рис. 3.21). Значение объема объекта берется из поля "Среднее количество экземпляров" формы "Описание объекта", а объем связи подсчитывается, исходя из отношения объемов двух объектов, участвующих в связи.

Рис. 3.21. Пример ЛСД с отмеченными объемами

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]