246071-Либерти-Освой-самостоятельно-С-за-21-день (852741), страница 91
Текст из файла (страница 91)
У клиента есть имя, личный идентификационныйномер и номер счета. Предусмотрена ли в системе возможность обработки и изменения этихданных? Счет имеет номер, остаток и записи трансакций. Как в системе будут возвращаться иобновлятьсяэтиданные?После детального изучения всех ситуаций использования, связанных с клиентом,следующимшагомбудетанализситуацийиспользованиядлявсехоставшихсяпользователей.Впримере с ATM можно получить следующий список ситуаций использования дляразрабатываемойнамисистемы:•Клиентпроверяетостаткинасвоихсчетах.•Клиенткладетденьгинасвойсчет.•Клиентснимаетденьгисосвоегосчета.•Клиентпереводитденьгисосчетанасчет.•Клиентоткрываетсчет.•Клиентзакрываетсчет.•Клиентполучаетдоступксвоемусчету.•Клиентпроверяетнедавниетрансакции.•Банковскийслужащийполучаетдоступкспециальномууправляющемусчету.•Банковскийслужащийрегулируетвыплатыпосчетамклиентов.• Банковская компьютерная система обновляет счет клиента на основе внешнихпоступлений.•Изменениянасчетеклиентаотображаютсяивозвращаютсявбанковскуюкомпьютернуюсистему.•ATMсигнализируетоботсутствииналичныхденегдлявыдачи.•БанковскийклеркзаправляетATMналичнымиивключаетего.СозданиемоделидоменаПосле того как сделан первый набросок ситуаций использования системы, можноприступать к описанию в документе требований модели домена.
Модель домена — этодокумент, фиксирующий все, что известно о домене (области использования программногопродукта). Модель домена состоит из объектов домена, каждый из которых соответствуетопределенному элементу, упоминавшемуся при описании ситуаций использования системы. Внашемпримерескассовымаппаратомнеобходимоучестьследующиеобъекты:клиент,персоналбанка,банковскаякомпьютернаясистема,расчетныйсчет,депозитныйсчетит.д.Для каждого из этих объектов домена требуется зафиксировать такие данные: имя(например,клиента,счетаит.д.),основныеатрибутыобъекта,являетсялиобъектпользователеми прочее.
Многие средства моделирования поддерживают фиксирование такого родаинформации в описаниях классов. На рис. 18.4 показано, как эта информация фиксируется спомощьюсистемыRationalRose.Важно понять, что мы имеем дело не с программными объектами, а с реальнымифигурантами,которыхследуетучитыватьприразработкепроекта.Никтонезаставляетнасдлякаждогообъектадоменасоздаватьобъектывпрограмме.Рис.18.4.СистемаRationalRoseИспользуя соглашения UML, можно создать диаграмму для нашего кассового аппарата, вкоторой будут отражены отношения между объектами домена точно так же, как изображаютсяотношения между классами в программе.
В этом одна из сильных сторон UML: на всех этапахпроектированияможноиспользоватьодниитежесредства.Например, можно зафиксировать, что расчетный и депозитный счета являютсяуточнениями более общего понятия банковского счета. Как уже отмечалось, в UML обобщениепроизводныхклассоввбазовыйотображаетсяспомощьюстрелок(рис.18.5).На диаграмме, показанной на этом рисунке, прямоугольники представляют различныеобъекты домена, а стрелки, направленные вверх, означают обобщение частных объектов вобщий.
Таким образом, в терминах языка C++ можно сказать, что объекты домена РасчетныйсчетиДепозитныйсчетявляютсяпроизводнымиотобъектаБанковскийсчет.Рис.18.5.Отношениямеждуобъектамидомена,выраженныесредствамиUMLUML — богатый язык моделирования, с помощью которого можно фиксировать самыеразныеотношения.Однакодлянаснаиболееважнымибудутотношенияобобщения,вложенияиассоциации.Примечание:Вновь обратите внимание, что в данном случае рассматриваютсяотношения между объектами домена.
Позднее, при разработке проекта, возможно, вызахотитереализоватьэтиотношениямеждуобъектамиклассовCheckingAcnount(Расчетныйсчет) и BankAccount (Банковский счет), используя наследование классов, но это будет лишьодин из возможных вариантов разработки проекта. Пока что мы просто пытаемсяразобраться,каквзаимодействуютдругсдругомреальныеобъектыдомена.Обобщение Обобщение часто рассматривают как синоним наследования, но между ними естьсущественное отличие. Обобщение описывает вид отношений, а наследование являетсяреализациейобобщениясредствамипрограммирования.Обобщение подразумевает, что производный объект является подтипом базового.
Такимобразом, расчетный счет является видом банковского счета. В свою очередь, банковский счетобобщаетатрибутыисвойстварасчетногоидепозитногосчетов.ВложениеЧастоодинобъектсостоитизмногихподобъектов.Например,автомобильсостоитизруля,шин,дверей,коробкипередачит.п.Расчетныйсчетсостоитизсальдо,записитрансакций,кодаклиентаит.д.Мыговорим,чторасчетныйсчетсодержитэтиобъектывсебе,другимисловами,этиобъектывложеныврасчетныйсчет.Вложенность,илисодержаниевсебесредствамиUMLобозначается стрелкой с ромбом на конце, которая направлена от внешнего объекта квнутреннему(рис.18.6).Рис.18.6.ОтношениевложенияРис.18.7.СложныеотношениямеждуобъектамиДиаграмма на рис. 18.6 показывает, что объект Расчетный счет содержит в себе другойдоменный объект — Сальдо, Чтобы показать достаточно сложный набор отношений, двепредыдущиедиаграммыможноскомбинировать(рис,18.7).Диаграмма на рис.
18.7 показывает, что объекты Расчетный счет и Депозитный счетобобщены в Банковский счет, а в объект Банковский счет вложены объекта Сальдо и Записитрансакций.АссоциацияТретьеотношение—ассоциацияобычнофиксируетсявовремяанализадоменаАссоциация предполагает, что два объекта "знают" друг друга и некоторым образомвзаимодействуют.Определениестанетнамноготочнеенаэтапепроектирования,нодляанализалишьпредполагается,чтоОбъектАиОбъектБвзаимодействуют,номиодинизнихнесодержити не является частным видом другого. В UML эта ассоциация показана с помощью простойпрямойлиниимеждуобъектами(рис,18.8).Рис.18.8.ОтношениеассоциацииДиаграмма на рис.
18.8 означает, что Объект А некоторым образом взаимодейетву' ет сОбъектомБ.РазработкасценариевТеперь,когдамыразобралисьсовсемиситуациямииспользованияпрограммыисредствамиотображенияотношениймеждуобъектамидомена,можноуглубитьсявдетализациютребованийкпрограммномупродукту.Каждыйслучайиспользованияможноразбитьнарядсценариев.Сценарий—этоописаниеопределенного набора обстоятельств, конкретизирующих ситуации использования. Например,ситуацияиспользования,прикоторойклиентснимаетденьгисосчета,можетиметьнесколькосценариев.• Клиент делает запрос на снятие $300 с расчетного счета, кладет наличные в кошелек иожидаетквитанции.•Клиентделаетзапроснаснятие$300срасчетногосчета,ноостатокнасчетесоставляетвсего $200.
Ему поступает информация, что для выполнения операции недостаточно денег нарасчетномсчете.• Клиент делает запрос на снятие $300 с расчетного счета, но сегодня с этого счета ужесняли $100, а дневной лимит составляет $300. Поступает информация, что ему разрешаетсяснятьтолько$200.• Клиент делает запрос на снятие $300 с расчетного счета, но в рулоне для печатанияквитанций закончилась бумага.
Ему поступает информация о возникшей техническойнеисправностиипредложениеподождать,покаперсоналбанкаустранитэтупроблему.Список сценариев можно продолжить. Каждый сценарий определяет вариантпервоначальной ситуации использования системы. Часто такие варианты являютсяисключительнымиситуациями(недостаточноденегнасчете,техническаянеисправностьит.д.).Иногда сценарий содержит в себе вариант решения, предлагаемого пользователю. Например,предложениеклиентуперевестиденьгисосчетадоегозакрытия.Различных сценариев можно придумать бесчисленное множество, но отобрать среди нихследует только те, на которые система готова ответить определенными действиями,сформулированнымивтребованияхкней.РазработкапутеводителейОпределивсписоксценариевдлякаждойситуациииспользования,необходиморазработатьпутеводители для всех сценариев, которые включаются в документ требований и содержат рядопределений.•Предварительныеусловия,определяющиеначалосценария.•Переключатели,включающиевыполнениеименноэтогосценария.•Действия,выполняемыепользователем.•Требуемыерезультатывыполненияпрограммы.•Информация,возвращаемаяпользователю.•Запускаемыециклыиусловиявыходаизних.•Логическоеописаниесценария.•Условиезавершениясценария.•Итогивыполнениясценария.Кроме того, в документе требований нужно указать ситуацию использования и имясценария,каквследующемпримере.Ситуацияиспользования:КлиентснимаетналичныесосчетаСценарий:УспешноеснятиеналичныхсрасчетногосчетаПредварительныеусловия:КлиентужеимеетдоступвсистемуПереключатель:ЗапросотклиентанаснятиеденегсосчетаОписание: От клиента поступил запрос на снятие денег с расчетного счета.
На счетеимеется достаточная сумма. В кассовом аппарате достаточно денег и заправлена бумага дляквитанций; сеть включена и работает. ATM просит клиента указать сумму денег для снятия.Клиентуказываетсумму,непревышающую$300.МашинавыдаетденьгиипечатаетквитанциюИтоги:Сосчетаклиентаснятауказаннаясумма;сальдосчетауменьшенонаэтусуммуЭту ситуацию использования можно изобразить с помощью простой диаграммы,представленнойнарис.18.9.Диаграмманеможетпохвастатьсяобилиемотображаемойинформации.Отношениямеждупользователем и системой показаны довольно абстрактно. Эта диаграмма станет гораздополезнее, когда будут показаны взаимоотношения между разными ситуациями использования.Таких отношений может быть только два: использование и расширение.
Отношениеиспользования означает, что одна ситуация использует другую. Например, невозможно снятьденьгисосчетабезрегистрациивсистеме.Этоотношениепоказанонарис.18.10.Рис.18.9.ДиаграммаситуациииспользованияРис.18.10.ОтношениеподчинениямеждуНарис.18.10показано,чтодляснятияденегсосчетанеобходимовыполнитьрегистрациювсистеме.Такимобразом,ситуацияСнятиесосчетаиспользуетситуациюРегистрациявсистеме,т.е.операциярегистрацииявляетсячастьюоперацииснятиясосчета.Расширение ситуации использования подразумевает установление каких-то логическихусловных отношений между разными ситуациями, что также может реализо- выватьсянаследованиемклассов.Вообще,средиспециалистовпообъектномумоделированиюсуществуетстолькоразногласийпоповодутого,чемотличаетсяиспользованиеотрасширения,чтомногиеиз них просто не применяют второй термин, считая его слишком неопределенным.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
