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

Содержание:

Введение

Современные тенденции развития рынка видео проката высока и моделирования предметной области по управлению взаимоотношениями с клиентами с использованием 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 разными категориями профессионалов. 1-ые отзывы и реакция на язык UML указывали на необходимость его дополнения отдельными понятиями и конструкциями.

В это время стало ясно, что некие компании и организации лицезреют в языке UML линию стратегических интересов для собственного бизнеса. Компания Rational Software совместно с несколькими организациями, изъявившими желание выделить ресурсы для разработки серьезного определения версии 1.0 языка UML, организовала консорциум партнеров UML, в который сначало вошли такие компании, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку следующей работы по более четкому и серьезному определению нотации, что привело к возникновению версии 1.0 языка UML. В январе 1997 года был размещен документ с описанием языка UML 1.0, как исходный вариант ответа на запрос предложений RTP. Эта версия языка моделирования была довольно отлично определена, обеспечивала требуемую выразительность и мощность и подразумевала решение широкого класса задач.

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

В текущее время все вопросы предстоящей разработки языка UML сконцентрированы в рамках консорциума OMG. Соответственная группа профессионалов обеспечивает публикацию материалов, содержащих описание следующих версий языка UML и запросов предложений RFP по его стандартизации. Очередной шаг развития данного языка завершился в марте 1999 года, когда консорциумом OMG было размещено описание языка UML 1.3.

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

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

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