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

	Загрузить архив:
	Файл: ref-18845.zip (979kb [zip], Скачиваний: 79) скачать

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

Введение

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

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

В начале 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) объек­та. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодей­ствия. Такую форму представления впервые ввел Ивар Якобсон.

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

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

Рис. 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. Усовершенствованная диаграмма пакетов

1

27

Окно

Ввода

Заказа

заказ

Строка

заказа

запас

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

Объект

Сообщение

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

интерация

Проверка ()

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

удалить()

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

условие

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

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

новый

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

Возврат

Поставка

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

новый

Создание

<
>