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

Содержание:

Введение

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

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

В начале 70-х гг. в США был отмечен кризис программирования (softwarecrisis). Это выражалось в том, что большие проекты стали выполнятся с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

Аналитические исследования и обзоры, выполняемые в течение ряда по­следних лет ведущими зарубежными аналитиками, показывали не слишком об­надеживающие результаты. Так, например, в 1995г. компания Standish Groupпроанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделали следующие вы­воды:

Только 16% проектов завершились в срок, 52,7% завершились с опозда­нием, расходы превысили запланированный бюджет.

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

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

Глава 1 Структура объектно-ориентированного программирования.

1.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.3 Варианты использования

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

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

Когда Якобсон в 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) и кооперативные диаграммы (collaborationdia­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. Иван Грэхем. Объектно-ориентированные метода. Принципы и практика. – 3-е изд. – М.: “Вильямс”, 2004г.
4. Гради Буч и др. "Объектно-ориентированный анализ и проектирование с примерами приложений" 2-е либо 3-е издание. Бином, Невский диалект, Вильямс ISBN
5. Лесневский А. С. Объектно-ориентированное программирование для начинающих: Бином. Лаб. знаний / Лесневский А. С. — М.: Бином. Лаб. знаний, 2010. — 232с.

Приложение.

Рис. 8 Диаграмма пакетов

Рис 9. Усовершенствованная диаграмма пакетов