Объектно-ориентированный подход к проектированию программного обеспечения на примере работы налоговой инспекции

Введение

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

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

В начале70-х гг. в США былотмечен кризиспрограммирования(software crisis).Это выражалосьв том, что большиепроекты сталивыполнятсяс отставаниемот графика илис превышениемсметы расходов,разработанныйпродукт необладал требуемымифункциональнымивозможностями,производительностьего была низка,качество получаемогопрограммногообеспеченияне устраивалопотребителей.

Аналитическиеисследованияи обзоры, выполняемыев течение рядапоследнихлет ведущимизарубежнымианалитиками,показывалине слишкомобнадеживающиерезультаты.Так, например,в 1995г. компанияStandishGroup проанализировалаработу 364 американскихкорпорацийи итоги выполненияболее 23 тыс.проектов, связанныхс разработкойПО, и сделалиследующиевыводы:

Только16% проектовзавершилисьв срок, 52,7% завершилисьс опозданием,расходы превысилизапланированныйбюджет.

В числепричин неудачфигурируют:нечеткая и неполная формулировкатребованийк ПО, недостаточноевовлечениепользователейв работу надпроектом,неудовлетворительноепланированиеи т.п.

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

ГлаваI Структураобъектно-ориентированногопрограммирования.

1.1 СУЩНОСТЬОБЪЕКТНО-ОРИЕНТИРОВАННОГОПОДХОДА

Принципиальноеразличие междуструктурными объектно-ориентированнымподходом заключаетсяв способедекомпозициисистемы.Объектно-ориентированныйподход используетобъектнуюдекомпозицию,при этом статическаяструктурасистемы описываетсяв терминахобъектов исвязей междуними, а поведениесистемы описываетсяв терминахобмена сообщениямимежду объектами.Каждый объектсистемы обладаетсвоим собственнымповедением,моделирующимповедениеобъекта реальногомира. Понятие"объект" впервыебыло использованооколо 30 лет назадв техническихсредствах припопытках отойтиот традиционнойархитектурыфон Нейманаи преодолетьбарьер междувысоким уровнемпрограммныхабстракцийи низким уровнемабстрагированияна уровнекомпьютеров.С объектно-ориентированнойархитектуройтакже тесносвязаныобъектно-ориентированныеоперационныесистемы. Однаконаиболее значительныйвклад в объектныйподход былвнесен объектнымии объектно-ориентированнымиязыками программирования:Simula, Smalltalk, C++, Object Pascal. На объектныйподход оказаливлияние такжеразвивавшиесядостаточнонезависимометоды моделированиябаз данных,в особенностиподход "сущность-связь".

Концептуальнойосновойобъектно-ориентированногоподхода являетсяобъектнаямодель. Основнымисе элементамиявляются:

• абстрагирование(abstraction);

• инкапсуляция(encapsulation);

• модульность(modularity);

• иерархия(hierarchy).

Кромеосновных имеютсяеще три дополнительныхэлемента, неявляющихсяв отличие отосновных строгообязательными:

• типизация(typing)',

• параллелизм(concurrency)',

• устойчивость(persistence).

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

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

Объектно-ориентированныйподход

Модульность— это свойствосистемы, связанноес возможностьюее декомпозициина ряд внутреннесвязных, нослабо связанныхмежду собоймодулей. Инкапсуляцияи модульностьсоздают барьерымежду абстракциями.

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

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

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

Устойчивость— свойствообъекта существоватьно времени (внезависимостиот процесса,породившегоданный объект)и/или в пространстве(при перемещенииобъекта изадресногопространства,в котором онбыл создан).

Основныепонятияобъектно-ориентированногоподхода - объекти класс.

Объектопределяетсякак осязаемаяреальность(tangible entity) — предметили явление,имеющие четкоопределяемоеповедение.Объект обладаетсостоянием,поведениеми индивидуальностью;структура иповедениесхожих объектовопределяютобщий для нихкласс. Термины"экземпляркласса" и "объект''являютсяэквивалентными.Состояниеобъекта характеризуетсяперечнем всехвозможных(статических)свойств данногообъекта итекущими значениями(динамическими)каждого из этихсвойств. Поведениехарактеризуетвоздействиеобъекта надругие объектыи наоборототносительноизменениясостоянияэтих объектови передачисообщений.Иначе говоря,поведениеобъекта полностьюопределяетсяего действиями.Индивидуальность— это свойстваобъекта, отличающиеего от всехдругих объектов.

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

Класс— это множествообъектов, связанныхобщностьюструктурыи поведения.Любой объектявляется экземпляромкласса. Определениеклассов и объектов— одна из самыхсложных задачобъектно-ориентированногопроектирования.

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

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

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

1.2 УНИФИЦИРОВАННЫЙЯЗЫК МОДЕЛИРОВАНИЯUML

Большинствосуществующихметодовобъектно-ориентированногоанализа ипроектирования(ООАП) включаюткак язык моделирования,так и описаниепроцессамоделирования.Язык моделирования— это нотация(в основномграфическая),которая используетсяметодом дляописания проектов.Нотацияпредставляетсобой совокупностьграфическихобъектов, которыеиспользуютсяв моделях; онаявляется синтаксисомязыка моделирования.Например, нотациядиаграммыклассов определяет,каким образомпредставляютсятакие элементыи понятия, каккласс, ассоциацияи множественность.Процесс— это описаниешагов, которыенеобходимовыполнить приразработкепроекта.

Унифицированныйязык моделированияUML (Unified Modeling Language) —это преемниктого поколенияметодов ООАП,которые появилисьв конце 80-х и начале90-х гг. СозданиеUML фактическиначалось вконце 1994 г., когдаГради Буч иДжеймс Рамбоначали работупо объединениюметодовBooch и ОМТ(Object Modeling Technique) подэгидой компанииRational Software. К концу1995 г. они создалипервую спецификациюобъединенногометода, названногоими UnifiedMethod, версия0.8. Тогда же, в 1995г., к ним присоединилсясоздательметодаOOSE (Object-oriented Software Engineering)Ивар Якобсон.Таким образом,UML является прямымобъединениеми унификациейметодов Буча,Рамбо и Якобсона,однако дополняетих новымивозможностями.Главными вразработкеUML были следующиецели:

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

• предусмотретьмеханизмырасширяемостии специализациидля расширениябазовых концепций;

• обеспечитьнезависимостьот конкретныхязыков программированияи процессовразработки;

• обеспечитьформальнуюоснову дляпонимания этогоязыка моделирования(язык долженбыть одновременноточным и доступнымдля понимания,без лишнегоформализма);

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

Класс —это множествообъектов, связанныхобщностьюструктурыи поведения.Любой объектявляется экземпляромкласса. Определениеклассов и объектов— одна из самыхсложных задачобъектно-ориентированногопроектирования.

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

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

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

1.3 ВАРИАНТЫИСПОЛЬЗОВАНИЯ

В течениедостаточнодлительногопериода временив процессе какобъектно-ориентированного,так и традиционногоструктурногопроектированияразработчикииспользовалитипичные сценарии,помогающиелучше понятьтребованияк системе. Этисценарии трактовалисьвесьма неформально- они почти всегдаиспользовалисьи крайне редкодокументировались.И вар Якобсонвпервые ввелпонятие "вариантиспользования"(use case) и придалему такуюзначимость,что он превратилсяв основнойэлемент разработкии планированияпроекта.

Вариантиспользованияпредставляетсобой последовательностьдействий(транзакций),выполняемыхсистемой вответ на событие,инициируемоенекоторымвнешним объектом(действующимлицом). Вариантиспользованияописываеттипичноевзаимодействиемежду пользователеми системой.Например, дватипичных вариантаиспользованияобычного текстовогопроцессора— "сделатьнекоторый текстполужирным"и "создатьиндекс". Дажена таком простомпримере можновыделить рядсвойств вариантаиспользования:он охватываетнекоторуюочевидную дляпользователейфункцию, можетбыть как небольшим,так и достаточнокрупным и решаетдля пользователянекоторуюдискретнуюзадачу В простейшемслучае вариантиспользованияопределяетсяв процессеобсужденияс пользователемтех. функций,которые онхотел бы реализовать.

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

Рис.1 Диаграммавариантовиспользования

Действующеелицо(actor) — этороль, которуюпользовательиграет по отношениюк системе. Нарис.1 четыредействующихлица: Менеджерпо продажам,Оптовый торговец,Продавец иСистема учета.Действующиелица представляютсобой роли, ане конкретныхлюдей илинаименованияработ. Несмотряна то, что надиаграммахвариантовиспользованияони изображаютсяв виде стилизованныхчеловеческихфигурок, действующеелицо можеттакже бытьвнешней системой,которой необходиманекотораяинформацияот данной системы(например, Системаучета). Показыватьна диаграммедействующихлиц системыследует тольков том случае,когда им действительнонеобходимынекоторыевариантыиспользования.

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

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

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

В дополнениек связям междудействующимилицами и вариантамииспользованиясуществуютдва других типасвязей (см.рис.1): "использование"(uses) и "расширение"(extends) междувариантамииспользования.Связь типа"расширение"применяетсятогда, когдаодин вариантиспользованияподобен другому,но несет несколькобольшую нагрузку

Вданном примереосновным вариантомиспользованияявляется Заключитьсделку В этомвариантепредполагаетсянормальныйход процесса.Однако в случаепревышениянекотороголимита — например,максимальнойсуммы торговойсделки, установленнойдля конкретнопклиента, процесс,связанный сданным вариантомиспользования,имеются исключения,то такое действующеелицо не имеетотношения креализациидругих вариантовиспользования.

Выбор применяемойсвязи определяетсяследующимиправилами:

• связь"расширение"следует применятьпри описанииизменений внормальномповедениисистемы;

• связь"использование"следует применятьдля избежанияповторов вдвух (или более)вариантахиспользования.Вариантыиспользованияявляются необходимымсредством настадии формированиятребованийк ПО. Каждыйвариант использования— это потенциальноетребованиек системе, ипока оно невыявлено, невозможнозапланироватьего реализацию.

Различныеразработчикиподходят кописанию вариантовиспользованияс разной степеньюдетализации.Например, ИварЯкобсон утверждает,что для проектас трудоемкостьюв 10 человеко-летколичествовариантовиспользованияможет составлятьоколо 20 (не считаясвязей "использование"и "расширение").Следует предпочитатьнебольшиеи детализированныевариантыиспользования,поскольку ониоблегчаютсоставлениеи реализациюсогласованногоплана проекта.

ГлаваIIДИАГРАММЫ

2.1Диаграммыклассов

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

• ассоциации(например, клиентможет сделатьзаказ);

• подтипы(частный клиентявляетсяразновидностьюклиента).

Рис. 2Диаграммаклассов

На диаграммахклассов изображаютсятакже атрибутыклассов, операцииклассов иограничения,которые накладываютсяна связи междуобъектами.

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

Построениедиаграмм классовможно рассматриватьв различныхаспектах:

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

• аспектспецификации— модельспускаетсяна уровень ПО,но рассматриваютсятолько интерфейсы,а не программнаяреализацияклассов (подинтерфейсомздесь понимаетсянабор операцийкласса, видимыхизвне);

• аспектреализации- модельдействительноопределяетреализациюклассов ПО.Этот аспектнаиболее важендля программистов.

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

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

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

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

Ассоциациипредставляютсобой связимежду экземплярамиклассов (личностьработает вкомпании, компанияимеет ряд офисов).

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

Каждаяассоциацияобладает двумяролями; каждаяроль представляетсобой направлениеассоциации.Таким образом,ассоциациямежду Клиентоми Заказом содержитдве роли: однаот Клиента кЗаказу, другая- от Заказа кКлиенту.

Роль можетбыть явнопоименованнаяс помощью метки.Например, рольассоциациив направленииот Заказа кСтрокам заказаназывается«позиция заказа».Если такаяметка отсутствует,роли присваиваетсяимя класс –цели – такимобразом, рольассоциацииот Заказа кКлиенту можетбыть названаКлиент (термины«начало» (source)и «цель» (target)употребляютсядля обозначенияклассов, являющихсясоответственноначальным иконечным дляассоциации).

2.2 ДИАГРАММЫВЗАИМОДЕЙСТВИЯ

Диаграммывзаимодействия(interaction diagrams) являютсямоделями,описывающимиповедениевзаимодействующихгрупп объектов.

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

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

• Окно ВводаЗаказа посылаетЗаказу сообщение"приготовиться".

• Заказ посылаетданное сообщениекаждой Строкезаказа в данномЗаказе.

• Каждая Строказаказа проверяетсостояниеопределенногоЗапаса товара:

Если даннаяпроверкаудовлетворяется(результат -true), то Строказаказа удаляетсоответствующееколичествотовара из Запаса.

В противномслучае количествоЗапаса снижаетсядо уровня повторногозаказа, и Запасзапрашиваетновую поставкутовара.

Существуютдва вида диаграммвзаимодействия:диаграммыпоследовательности(sequence diagrams) и кооперативныедиаграммы(collaboration diagrams).

На диаграммепоследовательностиобъект изображаетсяв виде прямоугольникана вершинепунктирнойвертикальнойлинии (рис.3).

Эта вертикальнаялиния называетсялиниейжизни(lifeline) объекта.Она представляетсобой фрагментжизненногоцикла объектав процессевзаимодействия.Такую формупредставлениявпервые ввелИвар Якобсон.

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

Окно

Ввода

Заказа

запас

Строка

заказа

заказ

Объект

Приготовится()

Сообщение

Приготовится()

Проверка()

условие

[Проверка= “true”]

удалить()

интерация

Нужен повторныйзаказ ()

самоделигирование

[Нуженповторныйзаказ = “true”]

Возврат

новый

Повторныйзаказ

[проверка= “true”]

новый

Поставка

Создание

Рис.3 Диаграммапоследовательности

(self-delegation) —сообщение,которое объектпосылает самомусебе, при этомстрелка сообщенияуказывает нату же самуюлинию жизни.

Из всейвозможнойуправляющейинформациидва ее видаимеют существенноезначение. Во-первых,это условие,показывающее,когда посылаетсясообщение(например,[нуженПовторныйЗаказ="true"]). Сообщениепосылаетсятолько привыполненииданного условия.Другой полезныйуправляющиймаркер - этомаркер итерации,показывающий,что сообщениепосылаетсямного раз длямножестваобъектов-адресатов(например,*приготовиться).

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

Диаграмма(см. рис. 3) содержитвозврат, означающийне новое сообщение,а возврат изсообщения. Надиаграммевозврат отличаетсяот обычныхсообщенийтем, что егострелка несплошная, аимеет вид парылиний.

Диаграммыпоследовательностиможно такжеиспользоватьдля представленияпараллельныхпроцессов.

Нарис. 4 изображенряд объектов,участвующихв проверкебанковскойтранзакции.В момент созданияТранзакцииона порождаетКоординаторТранзакциив целях координациипроверок,выполненныхТранзакцией.Этот координаторсоздает несколькообъектовТранзакционногоКонтролера(в данном случаедва объекта),каждый из которыхотвечает заопределеннуюпроверку. Такойпроцесс облегчаетсоздание различныхдополнительныхпроцессовпроверки,посколькукаждая проверкавызываетсяасинхроннои выполняетсяпараллельнос другими.

рис.4Параллельныепроцессы иактивизации

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

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

• создаватьновую ветвьпроцесса (вэтом случаеоно связанос самой верхнейчастью активизации);

• создаватьновый объект;

• устанавливатьсвязь с ужевыполняющейсяветвью процесса.

Удалениеобъекта показанос помощью большогознака "X". Объектымогут выполнитьсамоуничтожениеили могут бытьуничтоженыпосредствомеще одногосообщения.

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

ГлаваIIIПРИМЕРИСПОЛЬЗОВАНИЯОБЪЕКТНО-ОРИЕНТИРОВАННОГОПОДХОДА

В

качестве предметнойобласти, каки в главе 2,рассматриваетсяработа подразделенияучета налогоплательщиков-организаций.

На начальнойстадии(или стадииформированиятребований)строитсяначальнаядиаграммавариантовиспользования(рис.5).

Рис.5 Начальнаядиаграммавариантовиспользования

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

• Кто используетсистему непосредственно?

• Кто отвечаетза эксплуатациюсистемы?

• Какое внешнееоборудованиеиспользуетсясистемой?

• Какие другиесистемы взаимодействуютс данной системой?

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

Настадии проектированияуточняетсядиаграммавариантовиспользованияи строитсяархитектурасистемы, основойкоторой являютсядиаграммыклассов. В данномпримере ограничимсяпостроениемдиаграммыклассов и диаграммывзаимодействия.Диаграммывзаимодействиястроятся дляуточнениядиаграммывариантовиспользованияи перехода кдиаграммамклассов. Так,диаграммапоследовательности(рис. 6) иллюстрируетодин из возможныхсценариевразвития событийв рамках вариантаиспользования"Зарегистрироватьналогоплательщика".Предполагается,что налогоплательщикставится научет впервыеи все его документыв полном порядке.

Структурапрограммнойсистемы описываетсяс помощью несколькихдиаграммклассов, главнаяиз которыхпредставляетсобой диаграммупакетов (подобнуюдиаграммам,представленнымв приложениирис. 8 и 9), а остальныедиаграммыраскрываютсодержимоекаждого изпакетов. Припостроениидиаграммыклассов предметнойобласти выделениеэтих классов(классов-сущностей)может бытьаналогичновыделениюсущностей впроцессемоделированияданных. Данныеклассы должныиметь концептуальныйхарактер иотвечать навопрос "что?",а не "как?". Начальныйсписок можетбыть составленследующимобразом:

• в описанииисходных данныхвыделяютсякандидаты вклассы-существительные,которые потенциальномогут соответствоватьклассам (приэтом следуетпомнить, чтосуществительныемогут такжеотноситьсяк объектам,ассоциациямили атрибутамклассов);

Рис. 6 Диаграммапоследовательностидля вариантаиспользования"Зарегистрироватьналогоплательщика"

• анализируютсяроли кандидатовв системе. Каждыйкласс долженвыполнятьнекоторыедействия ивзаимодействоватьс другими классами.Каждый классдолжен иметьуникальноеимя, отражающеехарактер абстракции,представляемойданным классом.Если классутрудно придуматькраткое исодержательноеимя, то это являетсяхарактернымпризнакомнеудачноговыделениякласса. Рассматриваетсякаждая возможнаяпара классови устанавливаетсясуществованиеассоциациимежду ними (поаналогии сустановлениемсвязей междусущностямив процессемоделированияданных). Присваиваютсянаименованияролям ассоциаций,и определяетсяих множественность.

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

Рис. 7Диаграммаклассов предметнойобласти

Определяютсядействия (операции),выполняемыекаждым классом.При определенииопераций нужноучитыватьследующиерекомендации:

• каждаяоперация должнавыполнять однупростую функцию;

• названиеоперации должноотражать результатфункции, а нето,

как она выполняется.

Примерамипростых операциймогут быть:получить значениеатрибута, установитьзначение атрибута,добавить илиисключить связьс другим объектом,удалить данныйобъект.

Полученнаяв результатедиаграммаклассов предметнойобласти показанана рис. 7

Заключение.

Яхоте лбы отметить,что на примереналоговойинспекции мывоочию убедилисьв целесообразностииспользованияобъектно –ориентированногоподход. Но этоне предел иперспективаразвития объектно– ориентированногометода проектированиявелика. Егоотличает следующее:« объектно-ориентированныесистемы болееоткрыты и легчеподдаютсявнесению изменений,посколькуих конструкциябазируетсяна устойчивыхформах. Этодает возможностьсистеме развиватьсяпостепеннои не приводитк полной еепереработкедаже в случаесущественныхизмененийисходных требований.» К недостаткамотносятся:некотороеснижениепроизводительностифункционированияПО и высокиеначальныезатраты, этинедостаткине столь существенныв целом и начаше весовперевес будетв сторону плюсов.

Списокиспользованнойлитературы.

1. А. М. Вендров//Проектированиепрограммногообеспеченияэкономическихинформационныхсистем//Москва 2000г.

2. О. Ефимова// Курскомпьютерныхтехнологий//Москва1998г.

3. Всемирнаясеть Интернет

Приложение.

Рис. 8 Диаграммапакетов

Рис 9.Усовершенствованнаядиаграммапакетов

Содержание

Введение……………………………………………………………………………..3

Глава I Структураобъектно-ориентированногопрограммирования

1.1 Сущностьобъектно-ориентированногопрограммирования...……….5

1.2 Унифицированныеязыки моделированияUML……….……………..8

1.3Вариантыиспользованияобъектно-ориентированногопрограммирования………………………………………………………………………………...11

Глава IIДиаграммы

2.1 Диаграммыклассов…………………………………………………...15

2.2Диаграммывзаимодействия………………………………………….17

Глава IIIПрименениеобъектно –ориентированногоподхода в работеналоговойслужбы………………………………………………………………………….22

Заключение………………………………………….………………………………27

Списокиспользованнойлитературы……………………………………………...28

Приложение…………………………………………………………………………29

Буч отмечаеттакже ряд следующихпреимуществобъектно-ориентированногоподхода:

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

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

3. Объектнаямодель вполнеестественна,поскольку впервую очередьориентированана человеческоевосприятиемира, а не накомпьютернуюреализацию.

4. Объектнаямодель позволяетв полной мереиспользоватьвыразительныевозможностиобъектных иобъектно-ориентированныхязыков программирования.

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

Припереходе отструктурногоподхода к объектному,как при всякойсмене технологии,необходимовкладыватьденьги в приобретениеновых инструментальныхсредств. Здесьследует учестьи расходы наобучение (овладениеметодом, инструментальнымисредствамии языком программирования).Для некоторыхорганизацийэти обстоятельствамогут статьсерьезнымипрепятствиями.

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

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

Министерствонауки и образования РеспубликиКазахстан

СемипалатинскийГосударственныйУниверситетимени Шакарима

Кафедра:«Экономическойкибернетики»

Дисциплина:«Проектированиеинформационныхсистем»

Курсоваяработа

Тема:«Объектно-ориентированныйподход к проектированиюпрограммногообеспеченияна примереработы отделаналоговойинспекции».

Выполнил:

студентгруппы ЭК-306

ТлекинБ.С.

Проверила:

старшийпреподаватель

БекмухаметоваТ.М.

Семипалатинск2004 год.