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

• добавление информации путем большей детализации уже существующих объектов;.

• создание новых объектов путем конкретизации существующих объектов, а не создание абсолютно новых.

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

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

Диаграммы классов (class diagrams).

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

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

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

На рис. 3.12 представлен пример диаграмм классов (или объектов).

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

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

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

Основные добавленные элементы информации это:.

• операции (методы);.

• концепция обобщения (generalization);.

• атрибуты внутри объекта.

Прецеденты (Use cases).

Прецеденты описывают взаимодействие, которое может иметь место между системой и ее пользователями (актерами; в иностранной литературе - actors).

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

Рис. 3.13 Диаграмма прецедентов для банковской системы.

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

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

На рис. 3.13 изображена диаграмма прецедентов для банковской системы.