Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 48
Текст из файла (страница 48)
Если компании нужен продукт с какими-либо особыми функциями, она могла бы стать партнером производителя. Или же такая компания могла бы создать отдельную организацию, которая создаст программное обеспечение, продаст его спонсору, после чего начнет распространять его на рынке. В нашем примере мы предполагаем, что наша фирма — это производитель банкомата, который сам разрабатывает для него программное обеспечение. Будем считать, что мы создаем обыкновенный продукт, потому что сложности предметной области банкоматов лежат за рамками нашей книги.
° Какие задачи приложение будет решать? Программное обеспечение банкомата должно работать как на банк, так и на клиента. С точки зрения банка, программное обеспечение повышает уровень автоматизации и сокращает объем ручной канцелярской работы. С точки зрения клиента, банкоматы должны быть распространены повсеместно и обязаны быть круглосуточно доступны.
С их помощью клиент должен иметь возможность выполнять повседневные транзакции, где и когда ему удобно. Программное обеспечение банкомата должно быть простым в использовании и удобным, чтобы клиентам было приятнее работать с ним, чем с банковскими кассирами. Система должна быть надежной и защищенной, так как она будет работать с деньгами. ° Где будет использоваться система? Программное обеспечение банкоматов стало насущной необходимостью для финансовых учреждений.
Клиенты считают естественным, что у всех банков есть свои банкоматы. Банкоматы установлены во множестве магазинов и в других местах по всему миру. 11.3. Подготовка задачи к постановке 213 ° Когда будет нужна система? Любой проект по разработке программного обеспечения является деловым предложением. Инвестиция в разработку в конечном итоге приводит к получению доходов. С экономической точки зрения лучше всего сокращать инвестиции, увеличивать доходы и по возможности приближать их получение.
Достижению этой цели во многом и служат объектно-ориентированные технологии, применяемые в процессе вдумчивого моделирования. ° Почему нужна эта система? У производителя оборудования может найтись множество причин для создания программного продукта. Если другие компании зарабатывают деньги на аналогичных продуктах, это является достаточно веским основанием для вступления на рынок.
Новый продукт может позволить производителю обойти конкурентов и дать ему возможность установить цену выше номинала. Предприятия обычно стараются производить труднодоступные технологии самостоятельно, если они им действительно нужны. Единственной мотивацией разработки программного обеспечения для банкомата у авторов этой книги была необходимость продемонстрировать применение объектно-ориентированных технологий на хорошем примере. ° Как она будет работать? Мы планируем реализовать трехуровневую архитектуру, отделив пользовательский интерфейс от программной логики, а логику — от базы данных.
В реальности архитектура будет многоуровневой (с неопределенным числом уровней), потому что промежуточных программных уровней, взаимодействующих друг с другом, может быть сколько угодно. Архитектура будет обсуждаться в главе 14. 11.3. Подготовка задачи к постановке После того как нечеткая идея кристаллизуется благодаря ответам на перечисленные выше вопросы, вы будете готовы записать требования к системе, которые будут описывать цели и общий подход к созданию системы.
Разработчик должен хорошо представлять разницу между требованиями, проектом и реализацией. Требования описывают, каким образом система должна себя вести с точки зрения пользователя. Система считается черным ящиком. Все, что нас интересует — это ее внешнее поведение. Например, в числе требований к автомобилю может быть такое: когда вы давите на педаль газа, автомобиль начинает ехать быстрее, а когда нажимаете на тормоз — машина замедляет движение. Проект— это принятые решения о том, каким образом должно быть предоставлено поведение, указанное в требованиях. Например, проект описывает способ прокладки внутренних соединений, управление двигателем автомобиля, разновидность тормозных колодок.
Реализация — это окончательное воплощение в программном коде. Часто заказчики путают требования с проектными решениями. Обычно это приводит к плохим последствиям. Отделяя требования от проектных решений, вы сохраняете свободу маневра. Большинство систем могут быть спроектированы 214 Глава 11 ° 'коицептуалиэация системы множеством способов, поэтому принятие решения следует отложить до тех пор, пока вы не разберетесь в задаче полностью. В документе, описывающем концепцию системы, может быть приведен пример реализации. Назначение примера состоит в том, чтобы показать, каким образом система может быть реализована с использованием существующих технологий по приемлемой цене. Это просто «доказательство существования».
Однако нужно ясно понимать, что в окончательной системе реализация идей может быть выполнена совсем другим способом. Пример реализации предлагается исключительно для демонстрации возможностей. Например, в конце 60-х годов ХХ века был впервые предложен проект «Аполлон» (высадка человека на Луну). В первом его варианте предлагалось вывести ракету на орбиту Земли, затем запустить посадочный аппарат прямо на поверхность Луны. В окончательном варианте программы (который был успешно осуществлен) ракета была выведена на орбиту Луны, а затем с ракеты на поверхность Луны опустился посадочный модуль.
Первый вариант был предложен не зря: он дал людям уверенность в том, что проект действительно может быть осуществлен. Как показано на рнс. 11.2, постановка (или формулировка) залачи должна содержать утверждения о том, что следует сделать (а не о том, как это должно быть реализовано). Это должен быть список требований, а не вариант реализации системы. Не нужно описывать внутренности систегяы, так как это снизит гибкость процесса разработки. В качестве допустимых требований можно привести список эксплуатационных характеристик и протоколы взаимодействия с внешними системами.
Также допустимо перечисление стандартов технологии разработки программного обеспечения; модульное устройство, проектирование с расчетом на возможность тестирования н на дальнейшее расширение. Рис. 11.2. Разновидности требований Постановка задачи может быть более или менее подробной. Требования к обычному продукту, например к программе для составления ведомостей или для рассылки счетов, могут содержать довольно много подробностей. Требования к исследовательскому проекту в новой области могут иметь меньшее количество деталей, однако исследование должно, по крайней мере, иметь некоторую цель, которая должна быть ясно выражена.
Чаще всего постановка задачи оказывается неоднозначной, неполной и даже внутренне противоречивой. Некоторые требования впоследствии оказываются просто неправильными. Другие требования могут быть ясно сформулированы, но окажут плохое влияние на поведение системы или приведут к неприемлемому повышению стоимости реализации. Некоторые требования сработают не так, как 11.4. Резюме 215 рассчитывал инициатор создания системы. Постановка задачи — это отправная точка пути к ее пониманию, а не непреложная истина.
Цель последующего анализа, описанного в главе 12, состоит в том, чтобы полностью понять задачу и ее подтекст. Нет никаких оснований предполагать, что постановка задачи, подготовленная без полного анализа, окажется правильной. Пример с банкоматом. На рис. 11.3 показана постановка задачи для сети банкоматов. Рис. 11.3. Сеть банкоматов Разработать программное обеспечение компьютеризованной банковской сети, включающей кассиров и банкоматы. Банкоматы могут совместно использоваться группой банков. Каждый банк предоставляет свой компьютер для учета своих счетов и обработки транзакций с ними.
Кассиры также принадлежат отдельным банкам и взаимодействуют непосредственно с банковскими компьютерами. Кассиры вводят номера счетов и данные транзакций вручную. Банкоматы взаимодействуют с центральным компьютером, который осуществляет транзакции с соответствующими банками. Банкомат принимает от клиента его карту, взаимодействует с клиентом, соединяется с центральной системой для выполнения транзакции, выдает наличные и печатает чеки. Система требует ведения записей и обеспечения безопасности. Система должна корректно обрабатывать одновременное обращение к одному и тому же счету.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
