Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Применение и структура объектно-ориентированного подхода при проектировании информационной системы

Содержание:

Введение

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

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

В начале 70-х гг. в USA был отмечен упадок программирования (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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•подтипы(частный клиент является типом клиент

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

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

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

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

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

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

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

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

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

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

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

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

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

Любая связь обладает 2-мя ролями; любая роль представляет со­бой направленность связи. Таковым образом, связь меж Клиентом и Заявкой охватывает 2 роли: 1 от Клиента к Заявке, иная - от Заявки к Кли­енту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

.

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

Список литературы

  1. Грекул В.И. Проектирование информационных систем. www.intuit.ru, 2005
  2. Мацяшек Л.А. Анализ требований и проектирование систем. — М: Вильямс, 2002
  3. Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов. Проектирование экономических информационных систем — М: Финансы и статистика, 2003
  4. С. В. Маклаков. Создание информационных систем с All Fusion Modeling Suite. — М: Диалог-МИФИ, 2003
  5. А. М. Вендров. Практикум по проектированию программного обеспечения экономических информационных систем. — М: Финансы и статистика, 2004
  6. С. В. Черемных, И. О. Семенов, В. С. Ручкин. Моделирование и анализ систем. IDEF-технологии: практикум — М: Финансы и статистика, 2002
  7. Л.Г. Гагарина, Д.В. Киселёва, Е.Л. Федотова. Разработка и эксплуатация автоматизированных информационных систем — М: ИД «Форум» - ИНФРА-М, 2007
  8. Н.З. Емельянова, Т.П. Партыка, И.И. Попов Проектирование информационных систем — М: ИД «Форум», 2009