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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 12.03.2024

Просмотров: 10

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Содержание:

Введение

Современные тенденции развития рынка видео проката высоки, и моделирование предметной области по управлению взаимоотношениями с клиентами с использованием UML имеет большое значение для внесения инноваций и продвижения области.

Целью курсовой работы является Моделирование предметной области «Управление взаимоотношениями с клиентами» с помощью UML на примере видео проката.

  • Объектом исследования в курсовой работе является – процесс моделирования «Управления взаимоотношениями с клиентами» с помощью UML
  • Предмет исследования технологии, средства и методы для моделирования с использованием диаграмм UML

Для реализации данной цели в курсовой работе необходимо решить следующие задачи:

  • Проанализировать предметную область.
  • Сформулировать требования к программному обеспечению.
  • Разработать концептуальную модель и диаграммы в UML

Актуальность проблемы моделирования процесса управления взаимоотношениям с клиентами на примере видео проката высока, так как развитие и внедрения современных ИТ является приоритетным вектором развития.

Глава 1. Анализ методов моделирования и предметной области

1.1 Анализ методов моделирования

Этап проектирования структуры программы заключается в разработке детализированной схемы будущей программы, на которой указываются классы, их характеристики и способы, также разные связи меж ними. Результатом данного шага должна стать детализированная схема программы, на которой указываются все классы и связи меж ними в процессе функционирования программы, на которой указываются все классы и связи меж ними в процессе функционирования программы. Согласно методологии объектно-ориентированного анализа и проектирования (ООАП), конкретно данная схема должна служить начальной информацией для написания программного кода. [1]

Методология ООАП плотно сплетена с концепцией автоматической разработки программного обеспечения (Computer Aided Software Engineering, CASE).


Объектно-ориентированная методология (ООМ) сотворения автоматических систем состоит из последующих частей:

· объектно-ориентированный анализ (OOA),

· объектно-ориентированное проектирование (OOD),

· объектно-ориентированное программирование (OOР).

ООА - методология анализа сущностей реального мира на базе понятий класса и объекта, составляющих словарь предметной области, для осознания и разъяснения того, как они (сути) ведут взаимодействие меж собой.

OOР - совокупность мыслей и понятий, определяющая стиль написания программ, в какой основными концепциями являются понятия объектов и классов.

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

Главные понятия объектно-ориентированного проектирования: объект, класс, атрибут, операция, полиморфизм, наследование, компонент, связь.

Объект - это суть предметной области, имеющая верно определяемое поведение. Хоть какой объект обладает состоянием, поведением и индивидуальностью. Состояние объекта определяется значениями его параметров (атрибутов) и связями с другими объектами, оно может изменяться с течением времени. Поведение определяет деяния объекта и его реакцию на запросы от других объектов. Поведение представляется при помощи набора сообщений, воспринимаемых объектом (операций, которые может делать объект).

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

Атрибут – это поименованное свойство класса, определяющее спектр допустимых значений, которые могут принимать экземпляры данного характеристики. Атрибуты могут быть укрыты от других классов, это определяет видимость атрибута: рublic (общий, открытый); private (закрытый, скрытый); protected (защищенный).

Определенное воздействие 1-го объекта на другой с целью вызвать подобающую реакцию именуется операцией либо посылкой сообщения. Операция - это реализация услуги, которую можно запросить [2]у хоть какого объекта данного класса. Операции реализуют связанное с классом поведение, его обязанности. Описание операции включает четыре части: имя; перечень характеристик; тип возвращаемого значения; видимость.


Меж элементами объектной модели есть разные виды связей:

· ассоциация - это семантическая связь меж классами;

· агрегация - более сильный тип связи меж целым и его частями;

· зависимость - связь меж 2-мя элементами модели, при которой конфигурации в спецификации 1-го элемента могут повлечь за собой конфигурации в другом элементе;

· обобщение - связь «тип - подтип».

Способ объектно-ориентированного проектирования основывается на:

· модели построения системы как совокупит объектов абстрактного типа данных;

· модульной структуре программ;

· нисходящем проектировании, применяемом при выделении объектов.

В объектно-ориентированном проектировании выделяют последующие фундаментальные понятия:

Инкапсуляция: «Концепция сокрытия в вроде бы "капсуле" всей информации об объекте, другими словами объединение в некоторое целое данных и процедур (способов) их обработки. Единицей инкапсуляции в OOD является объект, в каком содержатся и данные состояния объекта и сообщения, которые объект может обрабатывать. Т.е. инкапсуляция — значит сочетание структур данных со способами их обработки в абстрактных типах данных - классах объектов».

Наследование: «Получение от предшественника - такое соотношение меж классами, находящимися в некой определенной иерархии, при которой один класс моделирует поведение и характеристики другого класса, добавляя свою специфику. Класс, поведение которого наследуется, именуется суперклассом, а класс, который наследует поведение, именуется подклассом».

Полиморфизм: «Возможность единообразного воззвания (посылки объектам одноименных сообщений) при сохранении уникального поведения объектов».

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

В период меж 1989-1994 гг. общее число более узнаваемых языков моделирования возросло с 10 до более чем 50. Многие пользователи испытывали суровые затруднения при выборе языка ООАП, так как никакой из них не удовлетворял всем требованиям, предъявляемым к построению моделей сложных систем. Принятие отдельных методик и графических нотаций в качестве эталонов (IDEF0, IDEF1X) не сумело поменять сложившуюся ситуацию непримиримой конкуренции меж ними сначала 90-х годов, которая тоже получила заглавие "войны способов". [3]


К середине 1990-х некие из способов были значительно усовершенствованы и заполучили самостоятельное значение при решении разных задач ООАП.

Более известными в этот период становятся:

· Способ Гради Буча (Grady Booch), получивший условное заглавие Booch либо Booch'91, Booch Lite (позднее - Booch'93).

· Способ Джеймса Румбаха (James Rumbaugh), получивший заглавие Object Modeling Technique - ОМТ (позднее - ОМТ-2).

· Способ Айвара Джекобсона (Ivar Jacobson), получивший заглавие Object-Oriented Software Engineering - OOSE.

Способ OOSE содержал средства представления вариантов использования, которые имеют существенное значение на шаге анализа требований в процессе проектирования бизнес-приложений. Способ ОМТ-2 более подходил для анализа процессов обработки данных в информационных системах. Способ Booch'93 отыскал наибольшее применение на шагах проектирования и разработки разных программных систем.

Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к возникновению первых документов, содержащих описание фактически языка UML, эти документы послужили типичным катализатором для широкого обсуждения языка UML разными категориями профессионалов.

Язык UML нацелен для внедрения в качестве языка моделирования разными юзерами и научными обществами для решения широкого класса задач ООАП. Многие специалисты по методологии, организации и поставщики инструментальных средств обязались использовать язык в собственных разработках. При всем этом термин "унифицированный" в заглавии UML не является случайным и имеет два нюанса. С одной стороны, он практически избавляет многие из несущественных различий меж известными ранее языками моделирования и методиками построения диаграмм. С другой стороны, делает предпосылки для унификации разных моделей и шагов их разработки для широкого класса систем, не только лишь программного обеспечения, да и бизнес-процессов. Семантика языка UML определена таким макаром, что она не является препятствием для следующих усовершенствований при возникновении новых концепций моделирования.

Подводя результат анализу методологии ООАП и исторических предпосылок возникновения UML, можно утверждать последующее. Имеются все основания полагать, что в наиближайшие годы язык UML в его современном виде станет основой для разработки и реализации в почти всех многообещающих инструментальных средствах: в RAD-средствах зрительного и имитационного моделирования, также в CASE-средствах самого различного мотивированного предназначения. Более того, заложенные в языке UML потенциальные способности могут быть применены не только лишь для объектно-ориентированного моделирования систем, да и для представления познаний в умственных системах, которыми, по существу, станут многообещающие сложные программно-технологические комплексы.


Унифицированный язык моделирования UML стал основой для целого диапазона разных средств поддержки разработки программного обеспечения - CASE-средств (Computer-Aided Software Engineering).

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

Таким образом, CASE-технология представляет собой методологию проектирования ИС, также набор инструментальных средств, позволяющих в приятной форме моделировать предметную область, рассматривать эту модель на всех шагах разработки и сопровождения ИС и разрабатывать приложения в согласовании с потребностями юзеров. Большая часть CASE-средств употребляет методологию структурного (в главном) либо нацеленного анализа и проектирования, использующих спецификации в виде диаграмм либо текстов для описания наружных требований, связей меж моделями системы, динамики поведения системы и архитектуры программных средств.

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

Все современные CASE-средства можно систематизировать по типам и категориям. Систематизация по типам отражает многофункциональную ориентацию CASE-средств на те либо другие процессы актуального цикла. Кроме этого CASE-средства можно систематизировать по категориям, используемым методологиям и моделям систем и БД; степени интегрированности с СУБД; легкодоступным платформам.

К главным плюсам CASE-средств можно отнести:

· обширное обилие свойства и способностей CASE-средств;

· относительно маленькое время использования CASE-средств в разных организациях и недочет опыта их внедрения;

· обширное обилие в практике внедрения разных организаций;

· отсутствие детализированных метрик и данных для уже выполненных и текущих проектов;

· широкий спектр предметных областей проектов;

· разная степень интеграции CASE-средств в разных проектах.

Rational Rose - CASE-средство компании Rational Software Corporation (США) - создано для автоматизации шагов анализа и проектирования ПО, также для генерации кодов на разных языках и выпуска проектной документации.