Файл: Применение объектно-ориентированного подхода при проектировании информационной системы(Основы объектно-ориентированного подхода).pdf
Добавлен: 24.04.2023
Просмотров: 222
Скачиваний: 2
Рисунок 9. Полиморфизм фигур
1.2 Преимущества и недостатки объектно-ориентированного подхода при проектировании информационных систем
Объектно-ориентированный подход дает возможность уменьшить некоторые основные расходы, связанные с системами, такие как обслуживание и разработка программного кода. Далее рассмотрены некоторые преимущества объектно-ориентированного подхода [4,5]:
1. Одним из важных преимуществ использования объектно-ориентированного подхода является его близость к восприятию человеком реального мира. Главное преимущество объектно-ориентированного подхода состоит в том, что он делает возможным прямое и естественное соответствие между миром и его моделью.
2. Сокращение средств на техническое обслуживание. Основной целью объектно-ориентированной разработки является обеспечение того, чтобы система прослужила дольше, а затраты на обслуживание были намного меньше. Поскольку большинство процессов в системе инкапсулированы, то поведение объектов может быть повторно использовано и включено в новое поведение.
3. Моделирование в реальном мире: объектно-ориентированные системы, как правило, моделируют реальный мир более полно, чем традиционные методы. Объекты организованы в классы объектов, а объекты связаны с поведением. Модель основана на объектах, а не на данных и обработке [4].
4. Повышенная надежность и гибкость: объектно-ориентированная система намного более надежная, чем традиционные системы, в первую очередь потому, что из существующих объектов можно «построить» новое поведение. Поскольку объекты могут быть динамически вызваны и доступны, новые объекты могут быть созданы в любое время. Новые объекты могут наследовать атрибуты данных от одного или многих других объектов. Поведения могут быть унаследованы от суперклассов, и могут быть добавлены новые способы поведения, не влияющие на функции существующих систем.
5. Возможность многократного использования кода: при создании нового объекта он автоматически наследует атрибуты данных и характеристики класса, из которого он был создан. Новый объект также будет наследовать данные и поведения от всех суперклассов, в которых он участвует.
Также рассмотрим и недостатки объектно-ориентированной технологии. Существует несколько основных заблуждений, которые необходимо учитывать при рассмотрении использования объектно-ориентированной технологии [5,6]:
1. Объектно-ориентированная технология не является панацеей – объектно-ориентированная разработка лучше всего подходит для динамических интерактивных сред, о чем свидетельствует ее широкое распространение в системах CAD / CAM и инженерных системах проектирования. Для крупномасштабных объектно-ориентированных корпоративных системы вопрос пока открыт, и многие приложения для информационных систем (например, начисления заработной платы, бухгалтерский учет) могут не получить выгоды от объектно-ориентированного подхода.
2. Объектно-ориентированная разработка еще не полностью принята крупными поставщиками, хотя имеет вес на рынке.
Для оценки объектно-ориентированного подхода также выполнено сравнение с предыдущей технологией структурного подхода.
Ключевым отличием объектно-ориентированного принципа от структурного является применение подхода «от частного к общему» вместо подхода «от общего к частному». В объектно-ориентированном подходе организация программы выполнена по количеству классов, в отличие от множества подмодулей или функций в структурном подходе.
Отличие в передаче данных состоит в том, что в структурном подходе для этого используется вызов функции, а в объектно-ориентированном применяется передача сообщений. Особенно важным отличием является возможность многократного использования программного кода в объектно-ориентированном подходе, в отличие от структурного подхода [5,6].
Объектно-ориентированный подход также отличается от структурного подхода отсутствием четкого перехода от проектирования к реализации.
Назначение продуктов, созданных на основе каждого из подходов различно. Продукты на основе объектно-ориентированного подхода подходят для большинства бизнес-приложений, проектов по разработке игр, которые, будут настраиваться или расширяться. Продукты на основе структурного подхода подходят для систем реального времени, встроенных систем и проектов, где объекты не являются наиболее полезным уровнем абстракции.
Моделирование данных при использовании структурного подхода выполняется с помощью DFD и E-R диаграмм, в то время как при объектно-ориентированном подходе применяются диаграммы классов, последовательности, состояний [6].
ГЛАВА 2
ПРИМЕНЕНИЕ ЯЗЫКА UML ДЛЯ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ
2.1 Виды диаграмм на языке UML
Диаграммы вариантов использования описывают отношения и зависимости между группой вариантов использования и участниками, участвующими в процессе.
Важно отметить, что диаграммы вариантов использования не подходят для представления проекта и не могут описывать внутренние компоненты системы. Диаграммы вариантов использования предназначены для облегчения связи с будущими пользователями системы, а также с заказчиками, и особенно полезны для определения необходимых функций, которые должна иметь система. Диаграммы вариантов использования показывают, что должна делать система, но не указывают и не могут указать, как этого добиться [6,7].
Данная диаграмма описывает – с точки зрения участников – группу действий в системе, которая дает конкретный, ощутимый результат.
Диаграмма вариантов использования – это описания типичных взаимодействий между пользователями системы и самой системой. Они представляют внешний интерфейс системы и задают форму требований к тому, что должна делать система. При создании диаграммы вариантов использования важно помнить несколько простых правил:
- каждый вариант использования связан как минимум с одним актером;
- каждый вариант использования имеет инициатора (то есть актера);
- каждый вариант использования приводит к соответствующему результату.
Варианты использования также могут иметь отношения с другими вариантами использования. Три наиболее типичных типа отношений между вариантами использования [6,7]:
- include, который указывает, что вариант использования включает другой варианта использования;
- extends, который указывает, что в определенных ситуациях или в некоторой точке (называемой точкой расширения) вариант использования будет продолжен другим;
- обобщение указывает, что вариант использования наследует характеристики варианта верхнего уровня и может переопределять некоторые из них или добавлять новые аналогично наследованию между классами.
Актер – это внешняя сущность (вне системы), которая взаимодействует с системой, участвуя (и часто инициируя) вариант использования. Актерами могут быть в реальной жизни люди (например, пользователи системы), другие компьютерные системы или внешние события [7].
Актеры представляют не физических людей или системы, а их роль. Это означает, что когда человек взаимодействует с системой по-разному (принимая на себя разные роли), он будет представлен несколькими участниками. Например, человек, который обеспечивает поддержку клиентов по телефону и принимает заказы от клиента, будет представлен актером «Вспомогательный персонал» и актером «Торговый представитель» [8].
Описания вариантов использования – это текстовые описания, которые принимают форму заметки или документа, каким-либо образом связаны с вариантом использования, и объясняют процессы или действия, которые происходят в сценарии использования.
Пример диаграммы вариантов использования показан на рисунке10.
Рисунок 10. Диаграмма использования «Заказ авиабилета»
Диаграммы классов показывают различные классы, которые составляют систему, и как они связаны друг с другом. Диаграммы классов относятся к «статическим» диаграммам, поскольку они показывают классы, их методы и атрибуты, а также статические отношения между ними [7,8].
Класс определяет атрибуты и методы набора объектов. Все объекты этого класса (экземпляры этого класса) имеют одинаковое поведение и имеют одинаковый набор атрибутов (каждый объект имеет свой собственный набор). Термин «Тип» иногда используется вместо «Класс», но важно отметить, что эти два понятия не совпадают, и «Тип» является более общим термином.
В UML классы представлены прямоугольниками с именем класса (рисунок 11), а также могут отображать атрибуты и операции класса в двух других «областях» внутри прямоугольника [8].
Рисунок 11. Визуальное представление класса в UML
В UML атрибуты отображаются, по крайней мере, с именем, а также могут отображать тип, начальное значение и другие свойства. Атрибуты также могут отображаться с их видимостью [6,8]:
+ –публичный атрибут;
# – защищенный атрибут;
- личный атрибут.
Операции (методы) отображаются как минимум с именем, а также могут отображать параметры и типы возвращаемых данных. Операции могут, как и атрибуты, отображать видимость:
+ – публичные операции;
# – защищенные операции;
- частные операции.
Классы могут быть связаны друг с другом следующим образом [8,9]:
1. Обобщение.
Наследование является одним из фундаментальных понятий объектно-ориентированного программирования, в котором класс «получает» все атрибуты и операции класса, от которого он наследует, и может переопределять / изменять некоторые из них, а также добавлять дополнительные атрибуты и операции свой.
В UML обобщение связи между двумя классами определяет иерархию, представляющую концепцию наследования производного класса от базового класса. В UML обобщения представлены линией, соединяющей два класса со стрелкой на стороне базового класса (рисунок 12) [9].
Рисунок 12. Визуальное представление обобщения в UML
2. Ассоциация представляет отношения между классами и дает общую семантику и структуру для многих типов «связей» между объектами.
Ассоциация – это механизм, который позволяет объектам общаться друг с другом. Он описывает связь между различными классами (связь между фактическими объектами называется объектной связью или связью) [7,8].
Ассоциации могут иметь роль, которая определяет цель ассоциации и может быть однонаправленной или двунаправленной (указывает, могут ли два объекта, участвующие в отношениях, отправлять сообщения другому, или только один из них знает о другом). Каждый конец ассоциации также имеет значение множественности, которое определяет, сколько объектов на этой стороне ассоциации может относиться к одному объекту на другой стороне.
В UML ассоциации представлены в виде линий, соединяющих классы, участвующие в отношениях, а также могут показать роль и множественность каждого из участников (рисунок 13). Кратность отображается в виде диапазона [min..max] неотрицательных значений со звездочкой (*) на максимальной стороне, представляющей бесконечность [9].
Рисунок 13. Визуальное представление ассоциации в UML
3. Агрегирование
Агрегирование – это особый тип ассоциаций, в которых два участвующих класса не имеют равный статус, но создают отношения «целая часть». Агрегация описывает, как класс, который берет на себя роль целого, состоит из других классов, которые играют роль частей. Для агрегаций класс, действующий как целое, всегда имеет множественность, равную единице.
В UML, агрегация представлена ассоциацией с ромбом на стороне целого (рисунок 14) [8,10].
Рисунок 14. Визуальное представление отношений агрегации в UML
4. Композиция образует отношения целых частей, но отношения настолько сильны, что части не могут существовать сами по себе. Они существуют только внутри целого, и если целое разрушено, части тоже не существуют. В UML композиции представлены сплошным ромбом на стороне целого (рисунок 15) [5,9].