Главная Случайная страница


Полезное:

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


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






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





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

Главное требование применения ООП является полная классификация ПрО.

Основное свойство: ООП – описательный (классы описываются независимо, не обязательно сразу проектировать всю систему)

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

В основе ООП лежит понятие объект (м.б. искусственным, естественным)

Объект:

  • свойства (интерфейсные, внутренние)
  • методы (в результате из применения меняется значение свойств объекта, объект переходит в новое состояние)
  • события (в результате применения методов может генерировать события)
  • исключения (возникают, когда к объекту данного класса применяется метод другого класса) – нарушение классификации

Полиморфизм – исключение ООП

Класс – логическое понятие

Объект – физическое понятие

Это главные отличия ООП от других подходов

Структурный подход не имеет логической надстройки, у него нет модельной двойственности.

Отношение между классами и между объектами

Над классами – логическое отношение;

Над объектами – физические отношения (агрегации или «часть-целое»)

Пример: самое простое – род-вид

Свойства объектной модели (ОМ):

1) Абстрагируемость: может определять логическое описание ПрО. Связана с противоречивостью 2-х тенденций. Выделение некоторого множества общих свойств для описания класса, которые должны обеспечить точное отношение объекта к данному классу. Но эти свойства должны точно отделить объекты данного класса от объекта другого класса. – 2 противоположные задачи (дуализм). Компромисс: введение кластеризации и прототипов

ООП – класс => программирование

COM – interface

 

2) Инкапсуляция: отдаление интерфейса от реализации, сокрытие внутреннего устройства объекта (физич). Обеспечение лог. уровня описания ПрО. (реализация или исполнение лог. описания класса)

Инкапсуляция внутри данного конкретного объекта (Система строится только на уровне интерфейса)

3) Модульность: возможность представления решения задачи в виде модулей. Это свойство физ. представления, связано с принципом построения модулей. Модули в ОМ становятся похожи на физ. классы, имеющие один единственный физ. объект, сам модуль.

Модуль = интерфейс + реализация

В модуле должно быть всё, что относится к этому классу. Модуль должен иметь какое-то функциональное значение.

Модуль приобретает вид физического объекта с одним

Типизация

4) Полиморфизм – производное свойство типизации.

Как свойство оно не существует, т.к. противоречит ООП. Полиморфизм – может применять метод одного класса к объекту другого класса. Множественность происхождения.

Полиморфизм – искусственное нарушение целостность ОМ.

5) Иерархичность

Логическая – строится над классами;

Физическая – строится над объектами.

Наследование – следствие иерархичности, тоже свойство; типы: род-вид, агрегация, инстанцирование (отделение, отдаление от типов данных)

Физическая иерархичность – строить отношения над модулями

6) Параллелизм – возможность организации клиент-серверной работы с объектами, т.е. многопользовательский.

C++ - потоки

7) Сохраняемость – способность объекта существовать после разрушения породившего его объекта или процесса

 

Что является продуктом в ОМ?

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

Что входит в ПрО?

Система программирования оперирует средствами языка – основная часть ПрО. Язык = базовые конструкции + надстройки. Все, что определяет систему программирования входит в ПрО (текст редактор, отладчик, компилятор и т.д.)

ООП – естественный, понятный для человека.

Уровни моделирования ПрО:

ПрО (аналитическая, проектная и др.)

1) Фундаментальный

Представляется и моделируется фунд. знания ПрО и закономерности. Они верны вообще для окружающего мира.

Работает в любой ПрО. для любой задачи (в любом приложении)

Пример: идентификация человека по ДНК в мировом масштабе

2) Концептуальный

Верно только для данной ПрО: Основано на экспертных оценках по одному и тому же поводу. Обеспечение распределения на любой ПрО.

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

(1) и (2) можно строить независимо от приложения, от задачи. Сама задача – ПрО.

Может иметь

  • прикладную ориентацию
  • предметно-ориентированная компонента

(1), (2) – предметно – ориентированные

3) Логический

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

CASE – технологии относятся к логическому моделированию

4) Физическое моделирование

Например, реляционное

На одно фундаментальное представление может быть n концептуальных, на одно концептуальное – n логических и т.д.

Переход от низшего уровня к высшему – это повышение абстрагирования

 

Источник: Мартин Фаулер и Кендалл Скотт «UML. Основы»

Унифицированный язык моделирования (UML, Unified Modeling Lan­guage) является преемником методов объектно-ориентированного ана­лиза и проектирования (OOA&D), которые появились в конце 80-х и начале 90-х годов. Он непосредственно унифицирует методы Буча, Рамбо (ОМТ) и Джекобсона, однако обладает большими возможностя­ми. Язык UML прошел процесс стандартизации в рамках консорциу­ма OMG (Object Management Group) и в настоящее время является стандартом OMG.

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

 

«Трое друзей», Гради Буч, Айвар Джекобсон и Джим Рамбо также разработали некий унифицированный процесс, который они назвали Рациональный унифицированный процесс (RUP, Rational Unified Process). Для применения языка UML вовсе не обязательно использовать процесс RUP, поскольку они совершенно независимы. Тем не менее, в этой книге я описываю этот процесс с целью рассмотрения методов языка моделирования в некотором кон­тексте. В рамках этого обсуждения используются основные этапы и терминология RUP, однако полное описание процесса RUP в книге не приводится. Должен сказать, что в своей работе мне приходится ис­пользовать много различных процессов, что зависит от заказчика и ти­па разрабатываемого программного обеспечения. Несмотря на то что я нахожу весьма важным стандартный язык моделирования, я не вижу такой же насущной необходимости в стандартном процессе, хотя неко­торое согласование терминологии все же будет полезным.

 

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

  • Одним из наилучших способов изучения объектно-ориентирован­ных методов являются CRC-карточки. Они не являются составной частью языка UML, хотя могут и должны ис­пользоваться вместе с ним. CRC-карточки были созданы главным образом для обучения людей работе с объектами. Именно поэтому они намеренно отличаются от традиционных методов проектирова­ния. Запись на этих карточках ответственности класса и отсутствие сложной нотации делает их особенно важным средством.
  • Диаграммы взаимодействия оказываются очень полез­ными, поскольку позволяют наглядно представить структуру сооб­щения и тем самым выявить излишне централизованные проекты, в которых один объект выполняет всю работу.
  • Диаграммы классов, используемые для иллюстра­ции моделей классов, одновременно как хороши, так и плохи для изучения объектов. Модели классов столь же удобны, как и модели данных; многие принципы построения хорошей модели данных также пригодны для построения хорошей модели классов. Основ­ная проблема в использовании диаграмм классов состоит в том, что можно легко разработать модель классов, которая ориентирована на данные, а не на ответственность.
  • Концепция образцов стала жизненно необхо­димой при изучении объектно-ориентированных методов, посколь­ку предоставляет возможность использовать результаты хорошо выполненных объектно-ориентированных проектов и обучаться на их примерах. После того как вы освоили некоторые базовые методы моделирования, такие как простые диаграммы классов и диаграммы взаимодействия, самое время приступить к рассмотрению об­разцов.
  • Еще одним важным методом является итеративная разработка. Этот метод не поможет вам в изучении объектно-ориенти­рованного подхода непосредственно, однако он даст ключ к его эф­фективному использованию. Если вы применяете итеративную раз­работку с самого начала, то сможете правильно уяснить для себя характер процесса и начнете понимать, почему проектировщики предлагают делать некоторые вещи именно так, а не иначе.

 

 

Статические и динамические модели объектно-ориентированных систем. Основные средства языка UML для представления статических и динамических моделей. Использование коопераций и паттернов.

Источник: Мартин Фаулер и Кендалл Скотт «UML. Основы»

 

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

  • Одним из наилучших способов изучения объектно-ориентирован­ных методов являются CRC-карточки. Они не являются составной частью языка UML, хотя могут и должны ис­пользоваться вместе с ним. CRC-карточки были созданы главным образом для обучения людей работе с объектами. Именно поэтому они намеренно отличаются от традиционных методов проектирова­ния. Запись на этих карточках ответственности класса и отсутствие сложной нотации делает их особенно важным средством.
  • Диаграммы взаимодействия оказываются очень полез­ными, поскольку позволяют наглядно представить структуру сооб­щения и тем самым выявить излишне централизованные проекты, в которых один объект выполняет всю работу.
  • Диаграммы классов, используемые для иллюстра­ции моделей классов, одновременно как хороши, так и плохи для изучения объектов. Модели классов столь же удобны, как и модели данных; многие принципы построения хорошей модели данных также пригодны для построения хорошей модели классов. Основ­ная проблема в использовании диаграмм классов состоит в том, что можно легко разработать модель классов, которая ориентирована на данные, а не на ответственность.
  • Концепция образцов стала жизненно необхо­димой при изучении объектно-ориентированных методов, посколь­ку предоставляет возможность использовать результаты хорошо выполненных объектно-ориентированных проектов и обучаться на их примерах. После того как вы освоили некоторые базовые методы моделирования, такие как простые диаграммы классов и диаграммы взаимодействия, самое время приступить к рассмотрению об­разцов.
  • Еще одним важным методом является итеративная разработка. Этот метод не поможет вам в изучении объектно-ориенти­рованного подхода непосредственно, однако он даст ключ к его эф­фективному использованию. Если вы применяете итеративную раз­работку с самого начала, то сможете правильно уяснить для себя характер процесса и начнете понимать, почему проектировщики предлагают делать некоторые вещи именно так, а не иначе.

 

 

Кооперации

Так же как классы-контейнеры, пакет может содержать кооперации. Кооперация представляет собой имя, которое присваивается взаимо­действию двух и более классов. Обычно подобное взаимодействие изображается на диаграмме взаимодействия. Так, например, диаграм­ма последовательности на рис. 7.3 представляет кооперацию Организа­ция Продажи.

 

Рис. 7.3. Диаграмма последовательности для организации продажи

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

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

Рис. 7.4. Диаграмма классов для кооперации организации продажи

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

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

Сначала рисуется диаграмма, подобная рис. 7.5, где показаны разные роли, которые исполняют различные объекты в данной кооперации. (Заметим, что классы на этой диаграмме не являются реальными классами системы; в действительности они являются ролями этой ко­операции.) Затем следует добавить диаграммы взаимодействия, чтобы показать особенности взаимодействия этих ролей.

Рис. 7.5. Параметризованная кооперация Продажа

Далее можно показать, как множество классов участвует в этой коопе­рации, нарисовав диаграмму, подобную рис. 7.6.

Рис. 7.6. Использование кооперации Продажа

В языке UML используется также термин образец (pattern) как сино­ним параметризованной кооперации. Довольно спорно называть об­разцом подобную ситуацию, поскольку здесь присутствуют по сути более одного образца. Но, без сомнения, эта нотация может быть приме­нена для изображения ситуации, когда в конкретной системе исполь­зуются общие образцы.

Этот вид нотации может быть использован также в процессе моделиро­вания на основе ролей, в рамках которого вначале моделируются коо­перации и роли, а затем разрабатываются классы, которые реализуют эти роли. Дополнительную информацию об этом стиле проектирова­ния можно найти в книге Ринскауга (Reenskaug), 1996 [35].

Date: 2016-05-25; view: 511; Нарушение авторских прав; Помощь в написании работы --> СЮДА...



mydocx.ru - 2015-2024 year. (0.006 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию