Вот простой сценарий, с помощью которого мы проверяем, правильно ли поняты назначение и функции системы:

Клиент подходит к дежурному и спрашивает, можно ли взять напрокат машину, у которой рычаг переключения передач установлен на полу (stick shift). Служащий использует CRTS0301 - Query cars in stock (запрос машин в наличии) и дает простой запрос, указывая в нем stick sliift . Запрос выполняется по сущности RENTAL CAR, ограниченной определенным населенным пунктом (SITE).

При поиске обнаруживается, чтов данном пункте таких автомобилей сейчас нет. Клиент выражает готовность подождать 30 минут, если мы сможем доставить нужный ему автомобиль.

Поиск расширяется путем указания близлежащего населенного пункта в CRTS3010 и повторного запуска запроса. Это нужно делать для каждого пункта; поиск по близости не предусмотрен.

При поиске автомобиль нужного типа обнаруживается в одном из близлежащих

пунктов, и клиент решает взять его.

Автомобиль можно заказать лишь в случае, если он находится в пункте, где сделан заказ, или перегоняется в этот пункт. Служащий нажимает в экранной форме кнопку Request Transit. Это действие удаляет связь сейчас находится в между RENTAL CAR и старым SITE и заменяет ее связью в процессе переезда в с нашим пунктом. В офис, расположенный в пункте, где есть нужный автомобиль, посылается предупреждение (в форме срочного электронно-почтового сообщения) о том, что нужно перегнать автомобиль.

Заказав автомобиль и его перегон, служащий может обработать условия

проката и оплаты.

Этот клиент уже обращался в фирму, поэтому служащий с помощью CTRS0430 сверяет данные его водительского удостоверения с хранящимися в системе; при этом также проверяется, имеет ли клиент право на скидку за приверженность фирме.

Определение критических участков

Здесь имеются в виду так называемые критические факторы успеха (КФУ) проекта. Например, важна ли производительность? (И если важна, то определена ли она в функциональном выражении, например, как длительность временного интервала, необходимого пользователю для создания заказа, а не просто как время ответа на рабочей станции?)

Какой смысл мы вкладываем в слово критические ? Обычно критические ушстки изухаются при первом анализе системы, однако затем акцент На Них часто не делается. Термин критические может означать как Жизненно важные для приемки и успешной реализации проекта , так и критические с точки зрения бизнеса или функциональности . Участки системы, определенные как критические, - хорошие кандидаты на макетирование. Макеты помогают проектировщику лучше понять поставленные

требования. Кроме того, они помогают доказать, что требования, связанные с критическим участком, могут быть выполнены. Во многих случаях полезно макетировать несколько подходов к решению проблемы и сравнить полученные результаты.

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

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

Одним из критических факторов успеха системы проката автомобилей является маленький временной интервал для прогона программы составления и выдачи счетов. Эту проблему мы решаем путем разработки данной программы на ранней стадии проекта, чтобы осталось побольше времени для тестирования, оптимизации и настройки. Мы знаем, что время ответа приложения, работающего в диалоговом режиме, является определяющим фактором - обычно клиент спешит, и довольно часто в офисе стоит очередь. Мы согласны с пользователями, что для 80% всех поэкранных транзакций необходимо обеспечить время ответа в пределах секунды. Еще один важнейший критерий - пропускная способность, так как прогон программы оформления счетов-фактур должен длиться не более 6 часов, а за один прогон может обрабатываться до 500000 операций со счетами. На наш взгляд, следует использовать средства параллельной обработки Oracle в сочетании с симметричной многопроцессорной системой. Кроме того, мы рассмотрим вопросы создания распределенной базы данных, охватывающей удаленные офисы.

Оценка системных ограничений

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

проверить осуществимость поставленных при анализе требований в свете всех этих ограничений (и увидеть, что собираетесь решить воистину невыполнимую задачу!).

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

Определение щелевой архитектуры

Что мы имеем в виду под словом архитектура ? Конечно, нам необходимо выбрать аппаратную платформу (или платформы). Обратите внимание на то, что мы говорим платформы . В системе может работать несколько компьютеров, относящихся к разным платформам; весьма вероятно, что у нас будет именно такая ситуация. Поэтому нам дополнительно потребуется решить следующее:

Будет ли это система клиент/сервер?

Будет ли база данных распределенной или реплицированной? Если да, то все базы данных будут продуктами Oracle или же это будет неоднородная сеть?

Может быть, для обработки требуемой нагрузки или достижения заданной пропускной способности нам понадобится Oracle Parallel Server?

Эти решения часто принимают до этапа проектирования. Поэтому в процессе проектирования полезно опять рассмотреть причины, по которым были приняты такие решения. Довольно часто возникают препятствия, которые не были предусмотрены. Предположим, вы решили спроектировать удобную для пользователя систему клиент/сервер с графическим пользовательским интерфейсом. Однако затем вы узнали, что доступ к этой системе необходим еще одной группе пользователей, у которых есть только текстовые терминалы VT100. В этом случае можно выбрать один из следующих вариантов: создать общие приложения и не использовать некоторые возможности архитектуры клиент/сервер и графического пользовательского интерфейса или разработать два комплекта прикладного программного обеспечения.

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

В системе проката автомобилей запланировано использование технологии клиент/сервер. Внешний интерфейс основан на Microsoft Windows 95, а серверные машины - на базе Unix. Эти серверы будут симметричными