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

Введение

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

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

В начале 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 (не считая связей "использование" и "расшире­ние"). Следует предпочитать неболь­шие и детализированные варианты исполь­зования, поскольку они облегчают составление и реализацию согласованного плана проекта.

---