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

Введение

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

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

В начале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 dia­grams).

На диаграммепоследовательностиобъект изображаетсяв виде пря­мо­угольникана вершинепунктирнойвертикальнойлинии (рис.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 год.