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

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

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

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

• подтипы (частный клиент является разновидностью клиента).

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждая ассоциация обладает двумя ролями; каждая роль представляет со­бой направление ассоциации. Таким образом, ассоциация между Клиентом и Заказом содержит две роли: одна от Клиента к Заказу, другая - от Заказа к Кли­енту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Окно

Ввода

Заказа

запас

Строка

заказа

заказ

Объект

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

Сообщение

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

Проверка ()

условие

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

удалить()

интерация

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

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

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

Возврат

новый

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

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

новый

Поставка

Создание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В
качестве предметной области, как и в главе 2, рассматривается работа подразделения учета налогоплательщиков-организаций.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение.

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

Список использованной литературы.

А. М. Вендров //Проектирование программного обеспечения экономических информационных систем// Москва 2000 г.

О. Ефимова // Курс компьютерных технологий//Москва1998г.

Всемирная сеть Интернет

Приложение.

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

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

Содержание

Введение……………………………………………………………………………..3

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

1.1 Сущность объектно-ориентированного программирования...……….5

1.2 Унифицированные языки моделирования UML……….……………..8

1.3 Варианты использования объектно-ориен­тированного программирования………………………………………………………………………………...11

Глава II Диаграммы

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

2.2 Диаграммы взаимодействия………………………………………….17

Глава III Применение объектно – ориентированного подхода в работе налоговой службы………………………………………………………………………….22

Заключение………………………………………….………………………………27

Список использованной литературы……………………………………………...28

Приложение…………………………………………………………………………29

Буч отмечает также ряд следующих преимуществ объект­но-ориентированного подхода:

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

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

3. Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.

4. Объектная модель позволяет в полной мере использовать вы­разительные возможности объектных и объектно-ориентированных языков программирования.

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

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

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

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

Министерство науки и образования Республики Казахстан Семипалатинский Государственный Университет имени Шакарима
Кафедра: «Экономической кибернетики» Дисциплина: «Проектирование информационных систем»
Курсовая работа

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

Выполнил: студент группы ЭК-306

Тлекин Б.С.

Проверила:

старший преподаватель

Бекмухаметова Т.М.

Семипалатинск 2004