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

Дискуссии

Много спорят о том, что происходит на каждом этапе процесса итеративного проектирования, и даже о том, как называется каждый этап. Откроем тайну: это не имеет значения. Основные этапы каждого процесса одни и те же: найдите, что надо построить, спроектируйте решение и реализуйте проект.

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

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

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

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

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

Ситуации использования

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

99993

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

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

Таким образом, определение ситуаций использования включает:

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

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

определение пользователя, для которого создается программный продукт.

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

Опрвдвлвнив пользоватвлвО

Обратите внимание, что пользователи - это не обязательно люди. Системы, которые будут взаимодействовать с создаваемой нами системой, тоже пользователи. Таким образом, если создается программа для автоматизированного кассового аппарата (ATM, известного как банкомат), то пользователем по отношению к нему будут клиенты и банковские клерки, а также другие банковские системы, например система по отслеживанию ипотек или по выдаче ссуд для студентов. Основные характеристики пользователей таковы:

они являются внешними по отношению к системе;

они взаимодействуют с системой.

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

В случае создания программного обеспечения для ATM необходимо учесть следующих возможных пользователей:

клиент;

менеджер;

компьютерная система банка;

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

Поначалу нет необходимости чрезмерно расширять и детализировать исходный список пользователей. Для описания ситуаций использования достаточно определить трех или четырех пользователей. Каждый из них по-разному взаимодействует с системой. Каждое взаимодействие должно быть учтено при определении ситуаций использования.

Опрвдвлвнив первой ситуации использования

Начнем с клиента. В обших чертах опишем, как клиент будет взаимодействовать с нашей системой.

Клиент проверяет, что осталось на его счетах.

Клиент кладет деньги на свой счет.

Клиент снимает деньги со своего счета.

Клиент переводит деньги со счета на счет.

Клиент открывает счет.

Клиент закрывает счет.

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

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

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

Анализируя действия разных пользователей, можно обнаружить дополнительные ситуации использования, ответив на ряд вопросов.

Почему пользователь использует систему?

Чтобы получить наличные, сделать вклад или проверить остаток на счете.

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

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

Что следует выполнить пользователю, чтобы воспользоваться системой? Вставить карточку в гнездо кассового аппарата ATM.

Ага! Нужно учесть ситуацию, когда клиент регистрируется в системе.

Какую информацию клиент должен предоставить системе? Ввести личный идентификационный номер.