246071-Либерти-Освой-самостоятельно-С-за-21-день (852741), страница 92

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

Текст из файла (страница 92)

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

Это можно документировать диаграммойвзаимодействий,показаннойнарис.18.11.Этадиаграммафиксируетдеталисценария,которыемогутнебытьочевиднымипричтениитекста. Взаимодействующие объекты являются объектами домена. Весь пользовательскийинтерфейс кассового аппарата рассматривается как единый объект. В деталях рассматриваетсятолькоопределениесистемойрасчетногосчетавбанкеиснятиеснегозаказаннойсуммыденег.Рис.18.11. Диаграмма взаимодействий системы кассового аппарата АTM с клиентом привыполненииоперацииснятиясосчетаОтношения между объектами домена пока раскрыты лишь в общих чертах, но это ужебольшой шаг в выявлении ключевых моментов этих отношений, на базе которых будутформироватьсятребованиякразрабатываемойсистеме.СозданиепакетовТак как при анализе любой более-менее серьезной проблемы число возможных ситуацийиспользования разрастается как снежный ком, бывает сложно отобразить все эти ситуации водной диаграмме.

Язык моделирования UML предоставляет возможность группироватьразличныеситуациивпакеты.Пакет напоминает папку в файловой системе компьютера. Он является набором объектовмоделирования (классов, деятелей и т.п.). Чтобы упорядочить ситуации использования, ихможнораспределитьпопакетамвсоответствиисконкретнымилогическимиконцепциями.Так,можнообъединитьвместеситуациииспользованияопределенныхбанковскихсчетов(расчетныхили депозитных) либо разделить их по типам клиентов или любым другим важнымхарактеристикам. Одна и та же ситуация использования может быть представлена в разныхпакетах,врезультатечегомеждупакетамиобразуютсялогическиевзаимосвязи.АнализсовместимостиприложенияВ дополнение к определению ситуаций использования в документе требований следуетчеткоописатьпредполагаемыхклиентовсистемы,ограниченияитребованияквычислительнойаппаратуреиоперационнымсистемам.Документтребованийкприложениюможнопредставитькак первого абстрактного пользователя вашей системы, желания и предпочтения которогоследует учесть при разработке приложения.

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

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

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

Часто крайний срок диктуется заказчиком: "Наэту работу у вас 18 месяцев". У программиста на этот счет может быть свое мнение, котороенеобходимо высказать. Идеально, если заказчик и исполнитель придут к компромиссу, но влюбом случае время и бюджет всякого проекта всегда ограничены. Уложиться в сроки и непревыситьбюджетчастобываеттруднее,чемнаписатьпрограмму.Приопределениибюджетаисроковследуетучестьдвамомента.• Если вы определили, во сколько в среднем обойдется проект, то попросите немногобольше,тогда,можетбыть,вамдадуттусумму,накоторуювырассчитывали.•ЗаконЛибертиутверждает,чтонавсетребуетсябольшевремени,чеможидалось,дажееслибылучтензаконЛиберти.После того как время и бюджет будут установлены, определитесь с приоритетами.

Вы всеравно не уложитесь в срок, будьте к этому готовы. Важно, чтобы к тому моменту, когда нужнобудет что-то показывать, у вас уже было что показать. Если вы строили мост, а время ужеистекло, то позаботьтесь о том, чтобы была проложена хотя бы велосипедная дорожка. Это,конечно,неБогвестьчто,нолучшечемничего.Покрайнеймере,можнобудетпопроситьденегнапродолжение.Еслижевремяистекло,авыдошлитолькодосерединыреки,тоэтоещехуже.Ко всем цифрам, зафиксированным в документации, следует относиться серьезно, но не"брать дурного в голову". В начале работ фактически невозможно точно оценить срокивыполненияпроекта.Желательноприберечьдлясебяот20до25%временидляманевра,есливходе выполнения проекта возникнут неожиданности. В конце концов, для всех важен успехпроектаиобоснованныеколебаниявсрокахвсегдадопустимы.Примечание:Мы вовсе не призываем к бесшабашному отношению к срокам,зафиксированным в документе.

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

Частографическое приложение к документации лучше всего справляется с функцией определениятребованийкпроекту,таккакпозволяетнаглядноувидеть,какойдолжнабытьсистемаикаконадолжнаработатьвконечномварианте.АртефактыК концу каждого этапа анализа и проектирования накапливается ряд документов,называемыхартефактами.Приблизительныйнабортакихдокументовпоказанвтабл.18.1.Этидокументы используются для организации взаимодействия и протоколирования отношениймежду заказчиком и исполнителем. Их подписание обеими сторонами гарантирует, чтоисполнитель четко понял и принял все требования заказчика и обязуется разработать вуказанные сроки проект, который в окончательном варианте должен выполнять точноопределенныйрядфункций.Таблица18.1.Артефакты,составляющиедокументациюпроектаПроектированиеВовремяанализаосновноевниманиеуделяетсярассмотрениюдоменаиопределениюзадачи требований к проекту, в то время как проектирование сосредоточено на поиске решений.Проектирование — это планирование практической реализации нашей идеальной моделисредствами программирования.

Результатом этого процесса является создание документапроектаприложения.Документ проекта состоит из двух разделов: проекта классов и архитектуры приложения.Первый раздел, в свою очередь, содержит статический (описание различных классов, ихструктурыихарактеристик)идинамический(описаниевзаимодействийклассов)подразделы.В разделе "Архитектура приложения" определяется время жизни различных объектов, ихвзаимоотношения, системы передачи объектов и другие механизмы реализации классов. Далеена этом занятии основное внимание уделяется проектированию классов, а все оставшиесязанятияпосвященырассмотрениюразличныхструктурархитектурыприложения.ЧтотакоеклассыИзучаяматериалыэтойкниги,выуженеразделалипопыткусоздаватьклассывпрограммахна языке C++.

Но поскольку в данный момент речь идет не о разработке программы, а о еепроектировании, следует различать проекты классов и их реализацию средствами C++, хотя,безусловно,этимоментытесновзаимосвязаны.Каждомуклассувпроектебудетсоответствоватьклассвпрограммномкоде,новсежененадоихпутать.Ведьдляреализацииспроектированногокласса можно использовать другой язык программирования, и даже в пределах C++ дляреализацииклассаможноиспользоватьразличныесредствапрограммирования.Далеенебудемзаострятьнаэтомвнимание,простопомните,чтоеслипланируетсясоздатьклассКотсметодомМяу(),товпрограммубудутдобавленыклассCatсметодомMeow(),хотяреализоватьихможнопо-разному.Обратитевнимание,чтовтекстекнигидляклассовпроектаиклассовпрограммыиспользованыразныестили,чтобыпомочьвамотличатьих.

Классы модели приложения отображаются в диаграммах UML, а классы C++ — в кодепрограммы,которыйможноскомпилироватьизапустить.У начинающих программистов часто возникает проблема с определением необходимогоколичества классов для программы и функций, которые должен выполнять каждый отдельныйкласс. Один из наиболее упрощенных подходов к решению этой проблемы состоит в записисценариядляситуациииспользованияприложения.Затемможнопопытатьсясоздатьклассыдлякаждогосушествительного(объекта),упоминающегосявэтомсценарии.Возьмемдляпримераприведенныйнижесценарий.Клиентвыбираетоперациюснятияналичныхсрасчетногосчета.Насчетевбанкеимеетсядостаточная сумма, в ATM достаточно наличных и заправлена лента для квитанций, а сетьвключена и работает.

Характеристики

Список файлов книги