Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (подробно).pdf
Добавлен: 22.04.2023
Просмотров: 75
Скачиваний: 2
СОДЕРЖАНИЕ
1.Объектно-ориентированные методы анализа и проектирования
1.1. Элементы объектно-ориентированной системы
1.2.Особенности объектно-ориентированной системы
1.3. Недостатки и преимущества
1.3.1.Преимущества объектно-ориентированного подхода
1.3.2. Недостаток технологии объектов
2. Разработка объектно-ориентированной системы
2.1. Жизненный цикл разработки объектно-ориентированной системы
2.2. Виды разработки объектно-ориентированных систем
3. Унифицированный язык моделирования (UML)
3.2. Инструмент проектирования UML PowerDesigner
3.3. Инструмент проектирования UML Rational Software Modeler
Введение
Объектно-ориентированная технология развивается в различных
областях вычислительной техники как средство решения проблем связанных со сложностью создаваемых систем. Объектный подход применяется не только в программировании, но также в проектировании интерфейса пользователя, баз данных, баз знаний и даже компьютерной архитектуры.
Смысл такого широкого подхода состоит в том, что он позволяет применить объектную ориентацию для решения всего круга проблем, связанных со сложными системами. В основе объектно-ориентированного проектирования лежит представление о том, что программную систему необходимо проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определенного класса, причем классы образуют иерархию.
Повышение интереса разработчиков к этой методологии обусловлено тем, что методы структурного анализа и проектирования не обеспечивают дальнейшего снижения трудоемкости разработки. Объектно- ориентированный подход наиболее естественно соответствует реальному процессу разработки систем и не только программных, который является итеративным и может потребовать внести изменения в уже разработанные и отлаженные компоненты системы.
1.Объектно-ориентированные методы анализа и проектирования
В объектно-ориентированном подходе основное внимание уделяется структуре и приведения информационных систем в небольшие модули, которые объединяют как данные, так и процесс. Основная цель объектно-ориентированного проектирования (ООП) - улучшить качество и производительность системного анализа и конструированию, сделав его более удобным.
На этапе анализа модели OOП используются для заполнения пробелов между проблемой и решением. Он хорошо работает в ситуации, когда системы подвергаются непрерывному проектированию, адаптации и обслуживанию. Он идентифицирует объекты в проблемной области, классифицируя их в терминах данных и поведения.
Модель OOП имеет следующие плюсы:
- Легкость внедрения новых решений.
- Это способствует повторному использованию компонентов.
- Это упрощает задачу интеграции компонентов для настройки большой системы.
- Это упрощает проектирование распределенных систем.
В таблице объясняется, как объектно-ориентированный подход отличается от традиционного структурированного подхода.
Таблица 1
Структурированный подход |
Объектно-ориентированный подход |
Он работает с подходом «сверху вниз». |
Он работает с подходом «снизу вверх». |
Программа делится на количество подмодулей или функций. |
Программа организована с использованием количества классов и объектов. |
Используется вызов функции. |
Используется передача сообщений. |
Повторное использование программного обеспечения невозможно. |
Возможно повторное использование. |
Структурированное программирование проектирования обычно остается до конечных фаз. |
Программирование объектно-ориентированного проектирования выполняется одновременно с другими этапами. |
Структурированный дизайн более подходит для офшоринга. |
Он подходит для внутреннего развития. |
Он показывает ясный переход от проектирования к реализации. |
Не столь явный переход от проектирования к реализации. |
Он подходит для системы реального времени, встроенной системы и проектов, где объекты не являются самым полезным уровнем абстракции. |
Он подходит для большинства бизнес-приложений, проектов разработки игр, которые, как ожидается, будут настроены или расширены. |
Данные диаграммы DFD & ER. |
Диаграмма классов, диаграмма последовательности, диаграмма диаграммы состояния и все варианты использования. |
В этом случае проекты могут легко управляться из-за четко идентифицируемых фаз. |
При таком подходе проекты могут быть трудно управлять из-за неопределенных переходов между фазами. |
1.1. Элементы объектно-ориентированной системы
Рассмотрим характеристики системы OOП:
- Объекты. Объект - это то, что существует в пределах проблемной области и может быть идентифицировано данными (атрибутом) или поведением. Все материальные сущности (ученик, пациент) и некоторые нематериальные субъекты (банковский счет) моделируются как объект.
- Атрибуты. Они описывают информацию об объекте.
- Поведение. Он указывает, что может сделать объект. Он определяет операцию, выполняемую над объектами.
- Класс - класс инкапсулирует данные и их поведение. Объекты со сходным смыслом и целью сгруппированы вместе как класс.
- Методы. Методы определяют поведение класса. Это не что иное, как действие, которое может выполнять объект.
- Сообщение. Сообщение - вызов функции или процедуры от одного объекта к другому. Это информация, отправленная объектам для запуска методов. По сути, сообщение представляет собой вызов функции или процедуры от одного объекта к другому.
1.2.Особенности объектно-ориентированной системы
Объектно-ориентированная система поставляется с несколькими важными функциями.
Инкапсуляция - это процесс скрытия информации. Это просто комбинация процесса и данных в единый объект. Данные объекта скрыты от остальной части системы и доступны только через службы класса. Это позволяет улучшить или модифицировать методы, используемые объектами, не затрагивая другие части системы.
Абстракция - это процесс принятия или выбора необходимого метода и атрибутов для указания объекта. Он фокусируется на существенных характеристиках объекта относительно перспективы пользователя.
Отношения - все классы в системе связаны друг с другом. Объекты не существуют изолированно, они существуют в отношениях с другими объектами.
Существует три типа объектных отношений:
- Агрегация - указывает связь между целым и его частями.
- Ассоциация. В этом случае два класса связаны или связаны каким-то образом, например, один класс работает с другим для выполнения задачи или один класс действует на другой класс.
- Обобщение - дочерний класс основан на родительском классе. Это указывает на то, что два класса похожи, но имеют некоторые отличия.
Наследование - отличная функция, которая позволяет создавать подклассы из существующего класса путем наследования атрибутов и / или операций существующих классов.
Полиморфизм - это способность принимать различные формы. Он применяется как к объектам, так и к операциям. Полиморфным объектом является тот, который истинный тип скрывается в супер или родительском классе.
При полиморфной операции операция может выполняться по-разному различными классами объектов. Это позволяет нам манипулировать объектами разных классов, зная только их общие свойства.
1.3. Недостатки и преимущества
1.3.1.Преимущества объектно-ориентированного подхода
Объектно-ориентированные системы обещают сократить обслуживание, повторное использование кода, моделирование в реальном мире, а также повышают надежность и гибкость. Однако это всего лишь обещания, и в реальном мире некоторые пользователи считают, что объектно-ориентированные преимущества не столь убедительны, как они изначально предполагали.
Например, что такое повторное использование кода? Некоторые скажут, что они могут повторно использовать большую часть объектно-ориентированного кода, созданного для системы, но многие говорят, что в объектно-ориентированных системах больше нет повторного использования кода, чем в традиционных системах.
Повторное использование кода является субъективной вещью и в значительной степени зависит от того, как определяется система. Объектно-ориентированный подход дает возможность сократить некоторые из основных расходов, связанных с системами, таких как обслуживание и разработка кода программирования.
Сокращение технического обслуживания: основной целью объектно-ориентированного развития является уверенность в том, что система будет пользоваться более длительным сроком службы, имея значительно меньшие затраты на техническое обслуживание. Поскольку большинство процессов внутри системы инкапсулированы, поведение может быть повторно использовано и включено в новое поведение.
Моделирование в реальном мире: объектно-ориентированная система имеет тенденцию моделировать реальный мир более совершенным образом, чем традиционные методы. Объекты организованы в классы объектов, а объекты связаны с поведением. Модель основана на объектах, а не на данных и обработке.
Улучшенная надежность и гибкость: объектно-ориентированная система обещает быть намного более надежной, чем традиционные системы, в первую очередь потому, что новое поведение может быть «построено» из существующих объектов. Поскольку объекты могут быть динамически вызваны и доступны, новые объекты могут быть созданы в любое время. Новые объекты могут наследовать атрибуты данных из одного или многих других объектов. Поведение может быть унаследовано от суперклассов, и новое поведение может быть добавлено без использования существующих системных функций.
Высокая повторяемость кода. Когда создается новый объект, он автоматически наследует атрибуты данных и характеристики класса, из которого он был создан. Новый объект также наследует данные и поведение всех суперклассов, в которых он участвует.
1.3.2. Недостаток технологии объектов
Существует несколько серьезных заблуждений, которые необходимо учитывать при рассмотрении использования объектно-ориентированного метода:
Объектно-ориентированное развитие не является панацеей. Объектно-ориентированное развитие лучше всего подходит для динамических интерактивных сред, о чем свидетельствует его широкое признание в CAD / CAM и системах проектирования. Широкомасштабные объектно-ориентированные корпоративные системы до сих пор не используют данный метод.
Объектно-ориентированное развитие не является технологией. Хотя многие сторонники религиозны в своем стремлении к объектно-ориентированным системам, что все направлены на объектно-ориентированный подход к решению проблем, а не по какой-либо конкретной технологии.
Объектно-ориентированное развитие получило некоторую рыночную респектабельность. Тем не менее, есть большие оговорки в отношении того, станет ли объектно-ориентированное развитие одной из основных сил или исчезнет в истории, как в 1980-х годах, когда системы поддержки принятия решений дали большие обещания, только чтобы исчезнуть в неясности.
Невозможно найти квалифицированных программистов и администраторов баз данных. Большинство менеджеров хотели бы получить объектно-технологический подход, но у них нет времени для обучения своих сотрудников объектно-ориентированным методам. Другие скажут, что объектно-ориентированный метод предназначен только для графических систем рабочих станций и что нет неотложной необходимости объектно-ориентированной системы в основных бизнес-системах.
Несмотря на то, что коммерческие объектно-ориентированные языки программирования уже несколько лет находятся на рынке, системы, написанные на объектно-ориентированных языках, составляют сегодня менее 1% систем.
2. Разработка объектно-ориентированной системы
2.1. Жизненный цикл разработки объектно-ориентированной системы
Он состоит из трех макропроцессов:
- Объектно-ориентированный анализ;
- Объектно-ориентированный дизайн;
- Объектно-ориентированная реализация;
- Объектно-ориентированный жизненный цикл;
Разработка объектно-ориентированных систем включает в себя следующие этапы:
- Объектно-ориентированный анализ;
- Объектно-ориентированное проектирование;
- макетирования;
- Реализация;
- Инкрементное тестирование;
- Объектно-ориентированный анализ.
Объектно-ориентированный анализ – этот этап связан с определением системных требований и пониманием требований к системе, создающих модель использования. Вариант использования - сценарий для описания взаимодействия между пользовательской и компьютерной системой. Эта модель представляет собой пользовательские потребности или пользовательский вид системы.