246071-Либерти-Освой-самостоятельно-С-за-21-день (852741), страница 90
Текст из файла (страница 90)
И если по поводу языка моделированияудалось прийти к общим соглашениям и выработать UML, то споры по поводуосновополагающихпринципованализаипроектированияпрограммпродолжаютсяпосейдень.Появилась даже новая профессия — методологи: это программисты, которые изучают иразрабатывают методы программирования. Часто в литературе можно встретить статьи,посвященные описанию нового метода программирования. Метод — это совокупность языкамоделирования и подходов анализа и проектирования. Три наиболее известных методолога вмире—этоГрейдиБуч(GradyBooch),создавшийметодБуча,АйверЯкобсон(IvarJa-cobson),разработавший подходы объектно-ориентированного программирования, и Джеймс Рамбо(JamesRumbaugh),создавшийтехнологиюобъектногомоделирования.ВместеонисоздалиметодObjectory~ коммерческий продукт от фирмы Rational Software, Inc.
Это фирма, в которой ониработаютигдеихлюбовновеличают"триамигос".Материал, изложенный на этом занятии, приблизительно следует методам Objectory.Точногосоответствиянебудет,таккакяневерюврабскоеследованиеакадемическойтеории.Ясчитаю создание конкурентно способной профессиональной программы более важным, чемточное соответствие этой программы каким бы то ни было абстрактным методам. В концеконцовнаObjectoryсветклиномнесошелся,иярекомендуювамбытьэклектикамиивыбиратьвселучшееизвсехметодов,которыевамизвестны.Процесспроектированияпрограммитеративен.Этозначит,чтоприразработкепрограммымы периодически повторяем весь процесс, по мере того как растет понимание требований,Проект нацелен на решение задачи, но нюансы, возникающие в ходе поиска оптимальногорешения,воздействуютнасампроект.Невозможноразработатьсерьезныйкрупныйпроектидяпо прямой от начала до конца.
Вместо этого на отдельных этапах приходится возвращаться кначалу,постоянносовершенствуяинтерфейсыипроцедурывыполненияотдельныхобъектов.Итеративнуюразработкуследуетотличатьоткаскадной,прикоторойвыходизоднойстадиистановится входом в следующую и назад дороги нет (рис. 18.3). Этот процесс напоминаетконвейер сборки автомобилей, где на каждом этапе собирается и тестируется один узел,постепенно формируя автомобиль. Но программа, в отличие от автомобиля, продукт штучный.Разработкупрограммредкоудаетсяпоставитьнаконвейер.Приитеративномпроектированиитеоретикпредлагаетновуюидею,априкладникначинаеттворческую реализацию этой абстрактной идеи в программе.
По мере того как начнутпрорисовываться детали проекта, будут меняться наши представления о форме реализацииисходной идеи. Работа над проектом начинается с формулирования требований к проекту,которыевходеразработкимогутменяться,чтопотребуетвнесенияизмененийвужесозданныепрограммные блоки. Большой проект разбивается на отдельные блоки, для которых сначаласоздаютсяпрототипы,азатемпроцедурыихвыполнения.Тестированиевыполненияотдельныхмодулей может привести к необходимости внесения изменений в их прототипы, а измененияотдельныхблоковзаставляютвремяотвременипересматриватьпринципыихвзаимодействиявцеломпроекте.Рис.18.3.КаскадныйпроцесспроектированияХотя цикличность работы над проектом очевидна, описать эти процессы в виде какого-тостабильного цикла довольно сложно.
Поэтому предлагаю вам лишь логическуюпоследовательность действий: возникновение идеи, анализ и осмысление ее, проектирование,программирование,тестированиеивозвращениектомуэтапу,которыйможномодернизировать.Таким образом, итеративность разработки проекта не заставляет вас кружить по замкнутомуциклу,апозволяеттворческиподойтикрешениюзадачивозвращатьсявсякийразктомуэтапу,гдевывидитевозможностьповыситьэффективностьвыполненияпрограммы.Ещеразповторимпоследовательностьдействий.1.Разработкаконцепции.2.Анализ.3.Проектирование.4.Реализация.5.Тестирование.6.Возвращение.Разработкаконцепции—этовынашиваниечистойидеи,ксожалению,далекойотреальнойжизни.
Анализ — это процесс осознания требований к проекту. Проектирование — процессформирования модели классов, на основе которой будет создаваться код. Реализация —написание кода (например, на C++); тестирование — проверка того, все ли в порядке, ивозвращение—этошлифовкавашегопродуктадотогосостояния,когдаегоможнобудетотдатьзаказчику.Осталосьреализоватьвсеэтонапрактике.ИдеяЛюбаягениальнаяпрограмманачинаетсясидеи.Нектодумаетопродукте,который,сеготочки зрения, было бы хорошо создать.
Реже сногсшибательную идею выдают комитеты. Насамой первой стадии анализа и проектирования объектно-ориентированного программногопродукта эта самая идея должна быть зафиксирована одним предложением (в крайнем случае,кратким абзацем). Идея становится ведущим принципом разработки, и команда, собравшаясядля ее реализации, по мере продвижения вперед должна на нее оглядываться, а в случаенеобходимостиикорректировать.ДискуссииМного спорят о том. что происходит на каждом этапе процесса итеративногопроектирования, и даже о том, какназывается каждый этап. Откроем тайну: это не имеетзначения. Основные этапы каждого процесса одни и те же: найдите, что надо постро- ить,спроектируйтерешениеиреализуйтепроект.Хотя на дискуссиях расцвели пышным цветом группы новостей и списки электронныхадресов специалистов по объектнымтехнологиям, в сущности, объектно-ориентированныйанализ и проектирование довольно просты.
В этой главе описан практиче- ский подход кпроцессусозданияархитектурыприложения.Целью всей этой работы является создание кода, соответствующего установленнымтребованиям,атакжеотличающегосянадежностью,расширяемостьюинастраивае-мостью.Неменее важным является создание высококачественного продукта в уста- новленные сроки и впределахбюджета.Дажееслиноваяидеяисходитотгруппытоварищейизотделамаркетинга,кто-товсе-такидолжен стать "крестным отцом" этой идеи и блюсти ее чистоту.
Из идеи проистекаюттребования к проекту. Детали исходной идеи могут преобразиться с учетом реалий сроков итребований рынка, но основная задача, которую планируется решить с помощью новойпрограммы,должнаоставатьсянеизменной,иначезачемжебратьсязаэтотпроект.Есливходепроработкидеталейвызабудетеотом,радичегобылзадуманпроект,тотакойпроектобречен.АнализтребованийЭтапразработкиконцепции,когдаформулируетсяидея,оченькороткий.Этонеболеечемвспышка озарения с последующим изложением на бумаге идеи, рожденной в уме теоретика.Большинствопрограммистоввключаютсявпроектнаболеепозднихэтапах,когдаосновнаяидеяужесформулирована.Иногдаформулированиеидеипутаютсопределениемтребованийкпроекту.Сильнаяидеянеобходима,ноэтогонедостаточно.Чтобыперейтиканализу,требуетсяпонять,какимобразом,гдеикембудетиспользоватьсяданныйпрограммныйпродукт.Цельэтапаанализасостоитвтом,чтобы сформулировать и зафиксировать эти требования.
Результатом анализа должен бытьдокумент с четкими требованиями к разработчикам проекта. Первым его разделом будетопределениеситуацийиспользованияпроекта.СитуацияиспользованияОпределение ситуаций использования проекта лежит в основе анализа и проектированияпрограммного продукта. Ситуация использования — это описание в общих чертах того, какимобразомбудетиспользоватьсяпрограммныйпродукт.Отэтогозависитподборметодовиклассовдляреализацииосновнойидеи.Обсуждение всех возможных ситуаций использования может быть важнейшей задачейанализа. На этом этапе просто необходимо прибегнуть к помощи экспертов, которые помогутучесть многие моменты, далекие от обычного программирования, например особенностиспросаипредложениянарынкепрограммныхпродуктовимногоедругое.На этом этапе также следует уделить некоторое внимание проектированию интерфейсапрограммного продукта, но внутренние методы реализации проекта нас еще не должныволновать.Поканашевниманиесконцентрированонапользователе.Пользователемможетбытьне только отдельный человек, но и определенная группа людей, организация или другойпрограммныйпродукт.Такимобразом,определениеситуацийиспользованиявключает:• формулирование общих представлений о том, где и каким образом будет использоватьсясоздаваемыйпрограммныйпродукт;•работусэкспертамиповыяснениюособенностейпредполагаемогоместаиспользованияпродукта,несвязанныхспроблемамиобычногопрограммирования;•определениепользователя,длякоторогосоздаетсяпрограммныйпродукт.Подситуациейиспользованияследуетпониматьбольше,нежелипростотипкомпьютернойсистемы или конкретная организация-заказчик.
Необходимо также учесть особенностивзаимодействиябудущихпользователейсразрабатываемымпрограммнымпродуктом.Наданномэтапе программный продукт следует рассматривать как "черный ящик". Важно четкоопределить, какие вопросы будет ставить пользователь перед системой и какие ответы оножидаетполучить.ОпределениепользователейОбратитевнимание,чтопользователи—этонеобязательнолюди.Системы,которыебудутвзаимодействовать с создаваемой нами системой, тоже пользователи.
Таким образом, еслисоздается программа для автоматизированного кассового аппарата (ATM, известного какбанкомат),топользователемпоотношениюкнемубудутклиентыибанковскиеклерки,атакжедругиебанковскиесистемы,напримерсистемаnoотслеживаниюипотекилиnoвыдачессуддлястудентов.Основныехарактеристикипользователейтаковы:•ониявляютсявнешнимипоотношениюксистеме;•онивзаимодействуютссистемой.При анализе ситуаций использования нередко самым трудным бывает начало. Лучше наэтомэтапеслишкоммногонедумать,асразуброситьсяватаку:простонапишитесписоклюдейи систем, которые будут взаимодействовать с вашей системой. Помните, что важно не то, какзовут человека, а в какой роли он будет выступать по отношению к новой системе: клерком,менеджером,клиентомит.д.Одинчеловекможетиметьнесколькоролей.В случае создания программного обеспечения для ATM необходимо учесть следующихвозможныхпользователей:•клиент;•менеджер;•компьютернаясистемабанка;• клерк, заправляющий кассовый аппарат деньгами и ответственный за его включение ивыключение.Поначалу нет необходимости чрезмерно расширять и детализировать исходный списокпользователей.Дляописанияситуацийиспользованиядостаточноопределитьтрехиличетырехпользователей.Каждыйизнихпо-разномувзаимодействуетссистемой.Каждоевзаимодействиедолжнобытьучтеноприопределенииситуацийиспользования.ОпределениепервойситуациииспользованияНачнем с клиента.
В общих чертах опишем, как клиент будет взаимодействовать с нашейсистемой.•Клиентпроверяет,чтоосталосьнаегосчетах.•Клиенткладетденьгинасвойсчет.•Клиентснимаетденьгисосвоегосчета.•Клиентпереводитденьгисосчетанасчет.•Клиентоткрываетсчет.•Клиентзакрываетсчет.Надо ли различать ситуации, когда клиент кладет деньги на свой расчетный, а когда надепозитный счет, или можно скомбинировать эти действия в одну ситуацию: клиент кладетденьгинасвойсчет,какбылосделановсписке?Ответзависитотзначимоститакогоразличиядляконкретногобанка.Чтобы определить; представляют ли эти действия одну ситуацию использования или две,надо выяснить, различны ли механизмы обработки (делает ли клиент нечто существенноразличноесэтимивкладами)иразличныливыходы(реагируетлисистемапо-разному).Наобавопроса в нашем случае ответ будет отрицательным: механизм внесения клиентом денег наразныесчетавцеломодинаковисистемавобоихслучаяхпрореагируетоднотипно—увеличитсуммунасоответствующемсчете.Приусловии,чтопользовательисистемаведутсебяболее-менееидентичновдвухразныхситуациях,этиситуацииможнообъединитьводну.Позднееможноконкретизироватьсценариииспользованиясистемыиразделитьэтиситуации,есливозникнетнеобходимость.Анализируядействияразныхпользователей,можнообнаружитьдополнительныеситуациииспользования,ответивнарядвопросов.•Почемупользовательиспользуетсистему?Чтобыполучитьналичные,сделатьвкладилипроверитьостатокнасчете.•Какойрезультатожидаетпользовательотсвоегозапросаксистеме?Положитьналичныенасчетилиснятьих,чтобысделатьпокупку.• Что заставило пользователя прибегнуть к этой системе сейчас? Возможно, ему недавновыплатилизарплатуилинадосделатьпокупку.• Что следует выполнить пользователю, чтобы воспользоваться системой? ВставитькарточкувгнездокассовогоаппаратаATM.Ага!Нужноучестьситуацию,когдаклиентрегистрируетсявсистеме.• Какую информацию клиент должен предоставить системе? Ввести личныйидентификационныйномер.Ага! Нужно предоставить возможность клиенту получить или изменить личныйидентификационныйномер.•Какуюинформациюпользовательхочетполучитьотсистемы?Остаткинасчетахит.д.Часто можно обнаружить дополнительные ситуации использования, обратив внимание наструктуру учета пользователей в доменах.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
