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

TYPE=RANDOM FORMAT=PAGE>30

Введение

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

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

В начале 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 г. они создали первую спецификацию объединенного метода, на­зван­ного ими Unified Method, версия 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

Заключение.

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

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

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

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

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

Приложение.

Рис. 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 год.