Зарегистрировать заявление

I-; .;0ЦвНИТЬ

заявление

- Зая№1еиии< обеспе<>(ено

Закрыть заявление

Полис действителен

Получить

- предварительную

оценку суммы возмещения

- Получить расценки ремонт

Разрешив ремонт

Рис. 15.1 Иерархия функций для обработки заявлений о выплате страхового возмещения

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

Рассматривая иерархию функций, необходимо помнить о следующих важных моментах:

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

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

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

Определения функций

Помимо разработки иерархии функций (в которой есть только краткие их описания), аналитик должен написать текстовое пояснение к каждой функции. На каждом уровне иерархии это, возможно, и не понадобится, но вот для верхнего уровня (в нашем примере - Обработать заявление ) и для нижнего, или атомарного, уровня (2.2.1-2.2.5) это обязательно. Пример описания приведен ниже.

Пример 15.1. Краткий пример функционального определения

2.2.2. Проверить, обеспечено ли заявление

Получить и зарегистрировать все подробные сведения о заявлении (Claims Details), включая все подробные сведения о третьих сторонах (Third Party) и свидетелях] (Witness). Изучить полис (Policy) на предмет наличия исключений (Exlusion Clauses)] и определить, действуют ли они для данного заявления (Claim).

Если есть исключение, закрыть заявление и сгенерировать стандартное письмо\ (Standard Letter) заявителю (Claimant). Если такого исключения нет, изменить статус заявления на ожидающее оценки (Awaiting Estimate), назначить и уведо- \ мить оценщика размера убытка (Loss Adjuster).

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

Примечание

Имена сущностей, используемые в примере 15.1, не стандартизованы.! Они сформулированы так, чтобы пример был понятен, а не в расчете на соответствие какой-либо конкретной методике.

Другие результаты анализа

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

Конечно, выделение имен сущностей в описаниях функций помогает понять назначений функций, однако существует более строгий подход к достижению этого понимания - построение полной матрицы функции-сущности . Форма матрицы позволяет найти информацию о конкретной функции или конкретной сущности и провести проверку качества, т.е. проверку того, имеет ли каждая сущность конструктор, или источник (функцию, которая создает ее экземпляры), есть ли ссылки на эту сущность (т.е. используется ли она) и имеет ли она деструктор. Во многих случаях деструктором является комплект программ архивации, однако гораздо чаще он просто отсутствует. Процесс анализа ссылок на сущности обозначают аббревиатурой CRUD (Create, Reference, Update, Delete - создание, ссылка, обновление, удаление).

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

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

Отображение функций в модули

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

1. Начать анализ с рассмотрения функций.

2. Завершить анализ построением модели сущностей, поддерживающей эти функции.