Объектинкапсулирует данные и поведение. Данные объекта представляются атрибутами,а его поведение - операциями

Объект определяется в классе.

Классы

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

Обобщения

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

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

Модели

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

В Rational Unified Process используется несколько моделей системы. Это связано с тем, что в процессе жизненного цикла системы модели используются разными специалистами, каждый из которых имеет свои интересы. Когда Вы обсуждаете систему и требования к ней, например, с конечным пользователем или заказчиком, модель должна описывать то, что система должна делать, и абстрагироваться от подробностей выполнения. Позже, при проектировании, модель должна фокусироваться на потребностях проектировщиков, которые должны иметь возможность обсуждать проблемы декомпозиции, абстракции и иерархии на уровне выше уровня языка программирования.

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

Источник: Мартин Фаулер и Кендалл Скотт «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-карточки были созданы главным образом для обучения людей работе с объектами. Именно поэтому они намеренно отличаются от традиционных методов проектирова­ния. Запись на этих карточках ответственности класса и отсутствие сложной нотации делает их особенно важным средством.
• Диаграммы взаимодействия оказываются очень полез­ными, поскольку позволяют наглядно представить структуру сооб­щения и тем самым выявить излишне централизованные проекты, в которых один объект выполняет всю работу.
• Диаграммы классов, используемые для иллюстра­ции моделей классов, одновременно как хороши, так и плохи для изучения объектов. Модели классов столь же удобны, как и модели данных; многие принципы построения хорошей модели данных также пригодны для построения хорошей модели классов. Основ­ная проблема в использовании диаграмм классов состоит в том, что можно легко разработать модель классов, которая ориентирована на данные, а не на ответственность.
• Концепция образцов стала жизненно необхо­димой при изучении объектно-ориентированных методов, посколь­ку предоставляет возможность использовать результаты хорошо выполненных объектно-ориентированных проектов и обучаться на их примерах. После того как вы освоили некоторые базовые методы моделирования, такие как простые диаграммы классов и диаграммы взаимодействия, самое время приступить к рассмотрению об­разцов.
• Еще одним важным методом является итеративная разработка. Этот метод не поможет вам в изучении объектно-ориенти­рованного подхода непосредственно, однако он даст ключ к его эф­фективному использованию. Если вы применяете итеративную раз­работку с самого начала, то сможете правильно уяснить для себя характер процесса и начнете понимать, почему проектировщики предлагают делать некоторые вещи именно так, а не иначе.

Источник: Филипп Крачтен «Введение в Rational Unified Process»

Инструментальные средства поддержки

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

Ниже перечислены инструментальные средства, которые Вам потребуются, и некоторые примеры инструментальных средств Rational, отвечающих этим потребностям.

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

Пример: Rational Rose

· Инструмент управления требованиями для фиксации, организации, расположения по приоритетам и прослеживания всех требований.

Пример: Rational Requisite Pro

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

Пример: Rational SoDA

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

Примеры: Rational Apex/Ada, Rational Apex/C++ (Java ready)

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

Пример: Microsoft Project

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

Примеры: Rational ClearQuest

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

Пример: ClearCase.

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

Примеры: Rational SQA Suite, Rational TestMate, Rational Visual Test

Объектно-ориентированный подход к проектированию АСОИУ. Представление и общая характеристика объектов и классов. Виды отношений между классами. Использование языка UML для процесса проектирования.

Источник: лекция Арсеньева