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

Введение

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

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

В начале 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 изображена типичная диаграмма классов. Перед тем как присту­пить к описанию диаграмм классов, следу­ет обратить внимание на один важ­ный момент, связанный с характером использования этих диаграмм разработ­чиками. Этот момент обычно никак не документируется, однако оказывает су­щественное воздействие на способ интерпретации диаграмм и поэтому имеет ножное отношению к тому, что описывается с помощью модели.

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

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

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