20. Сложная система с точки зрения объектного подхода

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

2) Выбор нижнего уровня абстракции произволен :и зависит от наблюдателя. И следовательно нижний уровень для одного может оказаться достаточно высоким для другого. Кроме того, в процессе развития системы объекты, которые на начальных этапах считались сложными на более поздних этапах рассматриваются, как элементы нижних уровней абстракции, из которых строятся более сложные компоненты.

3)Иерархическая система называется разложимой, если она может быть разделена на независимые части и почти разложимой, если ее составляющие не являются абсолютно независимыми.

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

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

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

D1

С1

С3

С4

С2

С5

С7

С6

D5 D6

D7

D8

На схеме мы видим две иерархии принадлежащие одной сложной системе:

- структуру классов и

- структуру объектов.

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

20. Этапы создания по при объектном подходе. Объектно-ориентированный и прикладной анализ

Методика ООП основана на описании и обработке классов и объектов.

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

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

НАПРИМЕР. Рассмотрим в качестве объекта лифт:

- он может быть исправным или нет,

- двигаться вверх, вниз или не двигаться вовсе,

- может быть загруженным или пустым,

- грузовым или пассажирским,

оставаясь при этом тем, что он есть и двигаясь в пределах своих направляющих.

При создание программы с использованием объектного подхода можно выделить три основных этапа:

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

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

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

Объектно-ориентированный анализ направлен на создание моделей близких к реальности. Это методология, при которой требования формируются на основе классов и объектов, которые составляют словарь предметной области. На результатах ООА строятся модели, на которых базируется OOD, создающее основу для ООР. Говоря о ООА нельзя не вспомнить о прикладном анализе. Его методы аналогичны методам ООА, но если ООА используется для решения какой-то конкретной задачи, то прикладной анализ направлен на поиск общих классов и объектов, свойственных всем переменным внутри определенной сферы применения.

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

- построение каркаса модели,

- изучение уже существующих систем данной предметной области,

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

- пересмотр существующей системы на основе предъявляемых требований.