Объектно-ориентированный подход к моделированию сложных систем

Автор работы: Пользователь скрыл имя, 19 Декабря 2012 в 21:46, реферат

Краткое описание

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

Прикрепленные файлы: 1 файл

Объектно-ориентированный подход к моделированию сложных систем.doc

— 624.00 Кб (Скачать документ)

 

 

 

Министерство науки  и образования РФ

Российский  Государственный Социальный Университет

Филиал в г. Электростали

 

 

 

 

 

РЕФЕРАТ

по курсу «Компьютерные модели в экономике»

на тему

 

«Объектно-ориентированный подход к моделированию сложных систем»

 

 

 

 

 

 

 

 

                                                                              Выполнила студентка

3го курса группы  ФИН-Д-3

 Серова Т.

Преподаватель: Балакший Р.А.

 

 

 

 

 

 

Электросталь 2011

 

Содержание:

 

 

 

Предпосылки возникновения  объектно-ориентированного подхода

 

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

Объектно-ориентированные  подход – это подход при котором  требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области.

С ООП тесно связанно объектно-ориентированное проектирование или моделирование. Если программирование направленно на правильное и эффективное  использование контекстных языков, то проектирование направленно на правильное и эффективное структурирование сложных систем.  

 

База объектно-ориентированного стиля

 

Каждый стиль программирования имеет свою базу. Для объектно-ориентированного стиля концептуальная база – это объектная модель, создание которой требует особого ОО мышления.

ОО модель имеет 4 главных свойства:

1) Абстрагирование –  выделение искусственных характеристик  некоторого объекта, отличающих  его от других видов объектов. Оно включает понятия агрегации и обобщения:

а) Агрегация – это  абстракция, которая превращает связь между объектами в некоторый агрегированный объект более высокого уровня.

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

b) Обобщение – это абстракция, превращающая класс объекта в родовой объект.

2) Инкапсуляция – скрытие  объекта за представляемым этим  объектом интерфейсом.

3) Модульность – способность  системы быть разложенной на  внутренние модули.

4) Иерархия – упорядочение компонентов и разложение их по уровням.

Эти свойства являются главными и, при отсутствии хотя бы одного их них, модель не будет ОО.

Также существуют 3 дополнительных свойства:

1) Типизация – создание объектов  на основе шаблонов определенного  типа.

2) Параллелизм – способность  системы обрабатывать несколько  сообщений или задачи параллельно.

3) Сохраняемость – способность  хранить не только данные, но  и объекты в промежутке между  отдельными запусками системы.

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

Важнейшими свойствами класса являются:

1) Наследование – это свойство, в соответствии с которым знания о более общей категории разрешается применять для более узкой категории. Наследование тесно связано с иерархией класса.

2) Инкапсуляция – Взаимодействующему с классом субъекту нет необходимости знать, каким образом реализован тот или иной метод класса, услугами которого он решил воспользоваться.

3) Полиморфизм – это свойствво некоторых объектов принимать различные внешние формы в зависимости от обстоятельств.

 

Диаграммы языка UML

 

UML (англ. Unified Modeling Language —  унифицированный язык моделирования)  — язык графического описания  для объектного моделирования в области разработки программного обеспечения.

История развития языка UML начинается с 1994 г

В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций – диаграмм.

В терминах языка UML представлены следующие виды диаграмм:

I. Диаграмма вариантов использования

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

III. Диаграмма поведения

Делится на следующие  диаграммы:

1) Диаграмма состояния 

2) Диаграмма деятельности 

3) Диаграмма взаимодействия 

a) Диаграмма последовательности

b) Диаграмма кооперации

IV. Диаграмма реализации

1) Диаграмма компонентов

2) Диаграмма развертывания

 

Диаграмма вариантов  использования

 

Диаграмма вариантов  использования – это графическое представление взаимодействия пользователя и компьютерной системы. Каждый use case охватывает очевидную для пользователя функцию системы и решает некоторую дискретную задачу пользователя.

Суть диаграммы вариантов использования состоит в следующем: проектируемая система представляется в виде множества сущностей (актеров), взаимодействующих с системой с помощью, так называемых, вариантов.

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

 Каждый вариант определяет некоторый набор действий системы при диалоге с действующим лицом.

Кроме вариантов и лиц элементами данной диаграммы являются интерфейс и примечание.

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

Пример:

Система продажи товаров  по каталогу.

 

Между компонентами use case могут существовать различные отношения, которые описывают различные взаимодействия актеров друг с другом.

Два use case, определенные для одной и той же сущности не могут взаимодействовать друг с другом, поскольку каждый из них самостоятельно описывает законченный use case этой сущности.

 

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

 

ДК принято считать  графическим представлением таких  структурных взаимосвязей логической модели системы, которые зависят от времени.

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

Обязательным элементом обозначения класса является его имя. Рекомендуется в качестве имен классов использовать существительные. Имена классов образуют словарь предметной области. 

Отношения между  классами:

Отношение зависимости используется только в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели.

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

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

Отношение композиции служит для выделения специальной формы отношения «часть-целое». Части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются все его составные части.

Отношение обобщения. Является отношением между более общим элементом и более частным или специальным элементом.

 

Диаграмма состояний.

 

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

Диаграмма деятельности

 

Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности.  Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой операции в предыдущем состоянии.

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

 

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

 

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

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

 

 

 

 

 

 

Диаграмма кооперации.

 

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

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

Физические  диаграммы

 

Диаграмма размещения позволяет анализировать взаимодействие процессов, работающих на разных компьютерных сетях.

Основные элементы:

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

2. Устройство – обозначает устройство не способное выполнять программы;

3. Соединение.

Диаграмма компонентов показывает организацию и взаимосвязи программы компонентов. Связи в данном типе диаграммы представляют зависимости одного компонента от другого. Так же данный тип диаграмм позволяет получить представление о поведении компонентов.

 Пример. Состояние  воды в кулере зависит от  показателей температуры и кислотности.

 

Диаграммы структурного системного анализа

 

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

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

Связь определяется как отношение или некоторая ассоциация между отдельными сущностями.

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

 

Объектно-ориентированные  базы данных

 

Объектно-ориентированные БД по сравнению с традиционными БД отличают следующие преимущества:

- данные в них инкапсулированы в объекты;

- повышают уровень абстракции при работе с данными;

- упрощают работу со сложно структурированными БД.

При всех достоинствах современных  объектных технологий разработки БД имеется несколько препятствий для перехода на объектную технологию:

- значительный объем разработок приходиться на реляционную (логическую) БД;

- в объектной технологии нет развитого и стандартизованного языка генерации отчетов и анализа данных каким является языка запросов SQL.

Данные проблемы были решены при создании БД фирмы “Inter Systems” – обеспечивает не только реализацию основных возможностей объектно-ориентированных технологий, но и позволяет во многом облегчить переход с реляционной технологии на объектную, а также может выступать в роли шлюза к реляционной БД.




Информация о работе Объектно-ориентированный подход к моделированию сложных систем