ОБЪЕКТНООРИЕНТИРОВАННЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ
Сущность объектно-ориентированного подхода
ОСОБЕННОСТИ СОВРЕМЕННЫХ КРУПНЫХ ПРОЕКТОВ ИС сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов; наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным); отсутствие полных аналогов, ограничивающее возможность использования каких либо типовых проектных решений и прикладных систем; необходимость интеграции существующих и вновь разрабатываемых приложений; функционирование в неоднородной среде на нескольких аппаратных платформах; разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств; значительная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков и, с другой стороны, масштабами организации заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
СЛОЖНОСТЬ Как отмечает Фредерик Брукс, руководитель проекта разработки операционной системы OS/360, самым существенным и неотъемлемым свойством программных систем является их сложность. Сами компьютеры сложнее, чем большинство продуктов человеческой деятельности. Количество их возможных состояний очень велико, поэтому их так трудно понимать, описывать и тестировать. У программных систем количество возможных состояний на порядки величин превышает количество состояний компьютеров. Аналогично, масштабирование программного объекта это не просто увеличение в размере тех же самых элементов, это обязательно увеличение числа различных элементов. В большинстве случаев эти элементы взаимодействуют между собой нелинейным образом, и сложность целого также возрастает нелинейно. Сложность ПО и ИС является второстепенным свойством. существенным, а не
РЕШЕНИЕ ПРОБЛЕМЫ СЛОЖНОСТИ (1) Проблема сложности является главной проблемой, которую приходится решать при создании больших и сложных систем любой природы, в том числе и ИС. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера, и т. д. , до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй» (divide et impera), иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделять (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня держать в уме информацию только о ней, а не обо всех остальных частях системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем ПО. Понятие «правильная» по отношению к декомпозиции означает следующее: количество связей между отдельными подсистемами должно быть минимальным; связность отдельных частей внутри каждой подсистемы должна быть максимальной.
РЕШЕНИЕ ПРОБЛЕМЫ СЛОЖНОСТИ (2) Структура системы должна быть таковой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки. Иначе говоря: каждая подсистема должна инкапсулировать содержимое (скрывать его от других подсистем); свое каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами. Инкапсуляция позволяет рассматривать структуру каждой подсистемы независимо от других подсистем. Интерфейсы позволяют строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя ее внутреннее устройство. Существует два подхода решения этой проблемы: структурный и объектно ориентированный
ПРОБЛЕМЫ, СТИМУЛИРОВАВШИЕ РАЗВИТИЕ ООП: Необходимость повышения производительности разработки за счет многократного (повторного) использования ПО Необходимость упрощения сопровождения и модификации разработанных систем (локализация вносимых изменений) Облегчение проектирования систем (за счет сокращения семантического разрыва между структурой решаемых задач и структурой ПО)
Краткая история объектноориентированного подхода • 1967: Simula • 1970 -е: Smalltalk • 1980 -е: Теоретические основы, C++, Objective-C. • 1990 -е: Методы OOA и OOD (Booch, OMT, . . ), Java • 1997: Стандарт UML (OMG)
КОНЦЕПТУАЛЬНАЯ ОСНОВА ООП Концептуальной объектная модель. основой объектно ориентированного подхода является Ее основными понятиями являются: объекты и атрибуты, целое и часть, классы и экземпляры. Объектная модель является наиболее естественным способом представления реального мира. В разделе «Теория классификации» Британской Энциклопедии сказано следующее: В постижении реального мира люди пользуются тремя методами, организующими их мышление: (1) разделение окружающей действительности на конкретные объекты и их атрибуты например, когда явно различаются понятия дерева и его высоты или пространственного расположения по отношению к другим объектам. (2) различие между целыми объектами и их составными частями например, ветви являются составными частями дерева. (3) формирование и выделение различий между различными классами объектов например, между классом всех деревьев и классом всех камней. Объектно ориентированный подход (ООП) использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира.
ОБЪЕКТ Объект определяется как осязаемая реальность (tangible entity) предмет или явление, имеющий четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс. Термины «экземпляр класса» и «объект» являются эквивалентными. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на другие объекты и наоборот с точки зрения изменения состояния этих объектов и передачи сообщений. Иначе говоря, поведение объекта полностью определяется его действиями. Индивидуальность это свойства объекта, отличающие его от всех других объектов. Определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию называется операцией. Как правило, в объектных и объектно ориентированных языках операции, выполняемые над данным объектом, называются методами и являются составной частью определения класса.
ПРЕДСТАВЛЕНИЕ ОБЪЕКТОВ Только имя объекта Только имя класса Имя объекта и имя класса
КЛАСС Класс это множество объектов, связанных общностью структуры и поведения. Класс инкапсулирует (объединяет) в себе данные (атрибуты) и поведение (операции). Любой объект является экземпляром класса. Определение классов и объектов одна из самых сложных задач объектно ориентированного проектирования.
Атрибут поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства Операция реализация услуги, которую можно запросить у любого объекта данного класса Операции отражают поведение объекта Операция-запрос не изменяет состояния объекта. Операциякоманда может изменить состояние объекта Результат операции зависит от текущего состояния объекта
Представление классов
ОСНОВНЫЕ МЕХАНИЗМЫ Основными механизмами объектной модели являются: абстрагирование (abstraction); инкапсуляция (encapsulation); наследование (inheritance); полиморфизм (polymorphism); модульность (modularity); иерархия (hierarchy).
АБСТРАГИРОВАНИЕ Абстрагирование это выделение существенных характеристики некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы с точки зрения дальнейшего рассмотрения и анализа. Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности его поведения от деталей их реализации. Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу объектно ориентированного проектирования.
ИНКАПСУЛЯЦИЯ Инкапсуляция это объединение в рамках объекта операций и атрибутов, отражающих его состояние, с целью обеспечить доступность и изменяемость состояния только посредством интерфейса, предоставляемого объектом. Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта. Объектный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы самого класса, скрыты от внешней среды. Абстрагирование и инкапсуляция являются взаимодополняющими операциями: абстрагирование фокусирует внимание на внешних особенностях объекта; инкапсуляция (или иначе ограничение доступа) не позволяет объектам пользователям различать внутреннее устройство объекта.
НАСЛЕДОВАНИЕ, МОДУЛЬНОСТЬ означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Модульность это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей. Инкапсуляция и модульность создают барьеры между абстракциями. Наследование
Полиморфизм способность скрывать множество различных реализаций под единственным общим интерфейсом Интерфейс совокупность операций, определяющих набор услуг класса или компонента Принцип: инкапсуляция
Иерархия ранжированная или упорядоченная система абстракций, расположение их по уровням в виде древовидной структуры Элементы, находящиеся на одном уровне иерархии, должны также находиться на одном уровне абстракции Виды иерархии: • иерархия агрегации • иерархия наследования • . . .
ПОСТРОЕНИЕ ОБЪЕКТНО ОРИЕНТИРОВАННЫХ СИСТЕМ Объектно ориентированная система изначально строится с учетом ее эволюции. Наследование и полиморфизм обеспечивают возможность определения новой функциональности классов с помощью создания производных классов потомков базовых классов. Потомки наследуют характеристики родительских классов без изменения их первоначального описания и добавляют при необходимости собственные структуры данных и методы.
ПОСТРОЕНИЕ ОБЪЕКТНО ОРИЕНТИРОВАННЫХ СИСТЕМ Другим важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой системы от стадии формирования требований до стадии реализации. Требование согласованности моделей выполняется благодаря возможности применения абстрагирования, модульности, полиморфизма на всех стадиях разработки. Модели ранних стадий могут быть непосредственно подвергнуты сравнению с моделями реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы.
ПРЕИМУЩЕСТВА ОБЪЕКТНО ОРИЕНТИРОВАННОГО ПОДХОДА объектная декомпозиция дает возможность создавать программные системы меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования не только программ, но и проектов; что в конце концов ведет к созданию среды разработки и переходу к сборочному созданию ПО. Системы зачастую получаются более компактными, чем их не объектно ориентированные эквиваленты, что означает не только уменьшение объема программного кода, но и удешевление проекта за счет использования предыдущих разработок; объектная декомпозиция уменьшает риск создания сложных систем ПО, так как она предполагает эволюционный путь развития системы на базе относительно небольших подсистем. Процесс интеграции системы растягивается на все время разработки, а не превращается в единовременное событие; объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию; объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно ориентированных языков программирования.
НЕДОСТАТКИ ОБЪЕКТНО ОРИЕНТИРОВАННОГО ПОДХОДА К недостаткам объектно ориентированного подхода относятся некоторое снижение производительности функционирования ПО и высокие начальные затраты. Объектная декомпозиция существенно отличается от функциональной декомпозиции, поэтому переход на новую технологию связан как с преодолением психологических трудностей, так и дополнительными финансовыми затратами.
UML - унифицированный язык объектноориентированного моделирования ИС
UML язык для определения, представления, проектирования и документирования программных систем, организационно экономических систем, технических систем и других систем различной природы
Развитие подхода Появление объектно ориентированных методов анализа и проектирования начало 1990 х годов Методы Буча, OMT и OOSE становятся наиболее популярными и известными Различия в методах не принципиальны: Затрагивают только синтаксис и терминологию Практика применения методов в реальных проектах требует унификации и стандартизации
Создание UML …. OMG Acceptance, Nov 1997 Final submission to OMG, Sep ‘ 97 UML 1. 1 First submission to OMG, Jan ´ 97 UML 1. 0 UML partners UML 0. 9 Web - June ´ 96 OOPSLA ´ 95 Other methods Unified Method 0. 8 Booch method OMT OOSE
Консорциум UML • • • • Rational Software Corporation Hewlett Packard I Logix IBM ICON Computing Intellicorp MCI Systemhouse Microsoft Objec. Time Oracle Platinum Technology Taskon Texas Instruments/Sterling Software Unisys
Вклад в создание UML Harel Meyer Before and after conditions Gamma, et al Statecharts Frameworks and patterns, HP Fusion Booch Operation descriptions an message numbering Booch method Embley Rumbaugh Singleton classes and high-level view OMT Jacobson Wirfs-Brock OOSE Responsibilities Shlaer - Mellor Odell Object lifecycles Classification
UML: назначение и свойства • Унификация методов Буча, OMT и OOSE • Включение других методов • Использование практического опыта и методик • Ориентация на перспективные средства разработки – Языки программирования: Java, C++, Smalltalk, Ada, Visual Basic, Power. Builder, Delphi и др. – Распределенные и многопользовательские системы – Компонентная архитектура – Моделирование бизнес процессов • Стремление сделать язык моделирования простым
“Унификация” означает, что • Унифицируются языки моделирования, используемые в предыдущих методах • Унифицируется нотация и семантика самого языка • Невозможно унифицировать технологию разработки программных систем
Средства UML u диаграммы вариантов использования (use case diagrams) u диаграммы классов (class diagrams) u диаграммы взаимодействия (interaction diagrams): u диаграммы последовательности (sequence diagrams) u кооперативные диаграммы (collaboration diagrams) u диаграммы состояний (statechart diagrams) u диаграммы деятельности (activity diagrams) u диаграммы компонентов (component diagrams) u диаграммы размещения (deployment diagrams)
ИНТЕГРИРОВАННАЯ МОДЕЛЬ СЛОЖНОЙ СИСТЕМЫ ИС НА ЯЗЫКЕ UML
ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ В течение достаточно длительного периода времени, в процессе как объектно ориентированного, так и традиционного структурного проектирования разработчики использовали типичные сценарии, помогающие им лучше понять требования к системе. Эти сценарии трактовались весьма неформально они почти всегда использовались и крайне редко документировались. Ивар Якобсон впервые понятие ввел понятие варианта использования (use case) и придал ему такую значимость, что он превратился в основной элемент разработки и планирования проекта. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Например, два типичных варианта использования обычного процессора «сделать некоторый текст полужирным» и «создать индекс» . текстового Даже на таком простом примере можно выделить ряд свойств варианта использования: он охватывает некоторую очевидную для пользователей функцию, может быть как небольшим, так и достаточно крупным и решает для пользователя некоторую дискретную задачу. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать.
СОЗДАНИЕ ПРЕЦЕДЕНТОВ Поведение разрабатываемой системы (то есть функциональность, обеспечиваемая системой) описывается с помощью функциональной модели, которая отображает системные прецеденты (use cases), системное окружение (действующих лиц или актеров actors) и связи между прецедентами и актерами (диаграммы преце дентов use cases diagrams). Основная задача модели прецедентов представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы. Разработка модели прецедентов начинается на стадии задумки с выбора актеров и определения общих принципов функционирования системы. Затем на этапе проработки модель дополняется детальной информацией к существующим прецедентам, а при необходимости добавляются новые.
АКТЕРЫ Актеры не являются частью системы они представляют собой кого то или что то, что должно взаимодействовать с системой. Актеры могут: только снабжать информацией систему; только получать информацию из системы; снабжать информацией и получать информацию из системы. Обычно актеры определяются из описания задачи или путем переговоров с заказчиками и экспертами. Для выявления актеров может быть использована следующая группа вопросов: 1. Кто заинтересован в определенном системном требовании? 2. Какую роль система будет выполнять в организации? 3. Кто получит преимущества от использования системы? 4. Кто будет снабжать систему информацией, информацию и получать информацию от системы? использовать 5. Кто будет осуществлять поддержку и обслуживание системы? 6. Использует ли система внешние ресурсы? 7. Выступает ли какой либо участник системы в несколь ких ролях? 8. Выступают ли различные участники в одной роли? 9. Будет ли новая система взаимодействовать со старой?
ПРЕЦЕДЕНТЫ С помощью прецедентов (use cases) моделируется диалог между актером и системой. Другими словами, они определяют возможности, обеспечиваемые системой для актера. Набор всех прецедентов системы определяет способы ее использования. Можно сказать, что прецедент это последовательность транзакций, выполняемых системой, которая приводит к значимому результату для определенного актера. Чтобы выделить прецеденты для системы, можно использовать следующую серию вопросов: 1. Каковы задачи каждого актера? 2. Будет ли актер создавать, хранить, изменять, удалять или получать инфор мацию из системы? 3. Какой прецедент будет создавать, хранить, изменять, удалять или получать эту информацию? 4. Должен ли актер информировать систему о внезапных изменениях внеш ней среды? 5. Должен ли актер быть проинформирован об изменени ях состояния системы? 6. Какие прецеденты будут поддерживать и обслуживать систему? 7. Могут ли все функциональные реализованы прецедентами? требования быть
ПОТОК СОБЫТИЙ Поток событий (flow of events) для прецедента это последовательность событий, необходимых для обеспечения требуемого поведения. Поток событий опи сываетсяв терминах того, «что» система должна делать, а не «как» она должна это делать. То есть он описывается на языке предметной области, а не терминами реализации. Поток событий должен определять: когда и как прецедент начинается и заканчивается; как он взаимодействует с актером; какие данные ему нужны; нормальную последовательность событий для прецедента; описание потоков в альтернативных и исключительных ситуациях. Документация на потоки событий обычно составляется в момент проработки итеративным способом. Сначала дается только краткое описание необходимых шагов для нормального выполнения прецедента. В ходе анализа шаги уточняются. На завершающем этапе в прецедент добавляют потоки для исключительных ситуаций. В каждом проекте должен использоваться стандартный шаблон для создания документа, описывающего поток событий.
ВОЗМОЖНАЯ СТРУКТУРА ПОТОКА СОБЫТИЙ Наименование. Краткое описание. Цели и результаты Предусловия (pre conditions). Предусловия варианта использования это такие условия, которые должны быть выполнены, прежде чем вариант использования начнет выполняться сам. Например, таким условием может быть выполнение другого варианта использования или наличие у пользователя прав доступа, требуемых для запуска этого. Не у всех вариантов использования бывают предварительные условия. Основной поток событий. Альтернативный поток событий. Поток событий поэтапно описывает, что должно происходить во время выполнения заложенной в варианты использования функциональности. Поток событий уделяет внимание тому, что будет делать система, а не как она будет делать это, причем описывает все это с точки зрения пользователя. Основной и альтернативный потоки событий включают следующее описание: Каким образом запускается вариант использования; Различные пути выполнения варианта использования; Нормальный, или основной, поток событий варианта использования; Отклонения от основного потока событий (так называемые альтернативные потоки); Потоки ошибок; Каким образом завершается вариант использования. Постусловия (post conditions). Постусловиями называются такие условия, которые всегда должны быть выполнены после завершения варианта использования. Например, в конце варианта использования можно пометить флажком какой нибудь переключатель. Информация такого типа входит в состав постусловий. Как и для предусловий, с помощью постусловий можно вводить информацию о порядке выполнения вариантов использования системы. Если например, после одного из вариантов использования должен всегда выполняться другой, это можно описать как постусловие. Такие условия имеются не у каждого варианта использования.
Пример модели Business Use Case (регистрация пассажиров в аэропорту) Пассажир Руководитель туристической группы Индивидуальная регистрация Групповая регистрация 41
Пример • • • Наименование - Индивидуальная регистрация Краткое описание - Процесс регистрации пассажира на рейс Цели - Получить посадочный талон и сдать багаж Основной сценарий: 1. Пассажир предъявляет билет регистратору 2. Пассажир сдает багаж 3. Регистратор определяет льготы пассажира 4. Регистратор выдает пассажиру посадочный талон и квитанцию на багаж Альтернативные сценарии: 1 а. Билет неправильно оформлен - регистратор отсылает пассажира к агенту по перевозкам 2 а. Багаж превышает установленный вес - регистратор оформляет доплату Специальные требования - Время регистрации не 42 должно превышать 2 минут
ТИПЫ СВЯЗЕЙ. В языке UML для вариантов использования и действующих лиц поддерживается несколько типов связей. Это связи коммуникации (communication), использования (uses, include relationship), расширения (extends, extend relationship) и обобщения действующего лица (actor generalization). Связи коммуникации описывают связи между действующими лицами и вариантами использования. Связи использования (включения) и расширения (дополнения) отражают связи между вариантами использования. Связи обобщения действующего лица между действующими лицами.
СВЯЗЬ КОММУНИКАЦИИ Связь коммуникации (communication relationship) — это связь между вариантом использования и действующим лицом. На языке UML связи коммуникации показывают с помощью обычной стрелки. Связь может быть либо двухсторонней (от актера к прецеденту и от прецедента к актеру), либо односторонней (от актера к прецеденту или от прецедента к актеру). Направление связи показывает, кто является ее инициатором (актер или прецедент). Такой тип отношений изображается в виде линии, соединяющей взаимодействующие элементы.
СВЯЗЬ ОБОБЩЕНИЯ С помощью связи обобщения действующего лица (actor generalization relationship) показывают, что у нескольких действующих лиц имеются общие черты. Например, клиенты могут быть двух типов: корпоративные и индивидуальные. Это отношение можно моделировать с помощью нотации, показанной на рисунке. Оформление и обработка багажа Оформление обычного багажа Оформление специального багажа Оформление ручной клади
СВЯЗЬ ИСПОЛЬЗОВАНИЯ ИЛИ ВКЛЮЧЕНИЯ Связь использования (uses relationship) или включения (include) позволяет одному варианту Индивидуальная Групповая использования регистрация использовать функциональность другого. С помощью таких связей <<include>> обычно моделируют многократно используемую функциональность, встречающуюся в двух или более вариантах Оформление и использования. обработка багажа
СВЯЗЬ РАСШИРЕНИЯ Связи расширения (extends relationships) позволяют варианту использования только при необходимости использовать функциональные возможности, предоставляемые другим вариантом использования. <<extend>> Отношение дополняет (extend relationship) применяется для отражения: дополнительных режимов; режимов, которые запускаются только при определенных условиях, например сигнала тревоги; альтернативных потоков, которые запускаются по выбору актера. Индивидуальная регистрация Регистрация на рейс прямого назначения
Общая модель Регистрация на рейс прямого сообщения <<extend>> <<include>> Пассажир Индивидуальная регистрация <<include>> Оформление и обработка багажа Групповая регистрация Руководитель туристической группы Оформление обычного багажа Оформление специального багажа Оформление ручной клади 48
ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой. Сообщение (message) средство, с помощью которого объект отправитель запрашивает у объекта получателя выполнение одной из его операций. Информационное (informative) сообщение - сообщение, снабжающее объект получатель некоторой информацией для обновления его состояния. Сообщение-запрос (interrogative) - сообщение, запрашивающее выдачу некоторой информации об объекте получателе. Императивное (imperative) сообщение - сообщение, запрашивающее у объекта получателя выполнение некоторых действий. Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). Диаграммы Последовательности отражают поток событий, происходящих в рамках варианта использования.
ПРИМЕР (USE CASES) Например, вариант использования "Снять деньги" предусматривает несколько возможных последовательностей, такие как снятие денег, попытка снять деньги, не имея их достаточного количества на счету, попытка снять деньги по неправильному идентификационному номеру и некоторые другие.
ПРИМЕР (ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ) Эта диаграмма Последовательности показывает поток событий в рамках варианта использования "Снять деньги". Все действующие лица показаны в верхней части диаграммы; в приведенном выше примере изображено действующее лицо Клиент. Объекты, требуемые системе для выполнения варианта использования "Снять деньги", также представлены в верхней части диаграммы. Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций. Следует отметить также, что на диаграмме Последовательности показаны именно объекты. В нашем примере – объект – Джо. На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон. Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию, и, кроме того, можно показать само делегирование (self delegation) сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.
52
КООПЕРАТИВНЫЕ ДИАГРАММЫ Подобно диаграммам последовательности, кооперативные диаграммы (collaborations) отображают поток событий через конкретный сценарий варианта использования. Диаграммы последовательности упорядочены по времени, а кооперативные диаграммы больше внимание заостряют на связях между объектами. У разных разработчиков имеются различные предпочтения по поводу выбора вида диаграммы взаимодействия. В диаграмме последовательности делается акцент именно на последовательность сообщений: легче наблюдать порядок, в котором происходят различные события. На кооперативной диаграмме можно использовать пространственное расположение объектов для того, чтобы показать их статическое взаимодействие.
КООПЕРАТИВНАЯ ДИАГРАММА (ВАРИАНТ ИСПОЛЬЗОВАНИЯ «СНЯТЬ ДЕНЬГИ СО СЧЕТА» ) 54
ДИАГРАММЫ КЛАССОВ Диаграммы классов являются центральным звеном объектно ориентированных методов. Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Диаграммы классов отражают взаимодействие между классами системы. Классы можно рассматривать как типы объектов. Например, счет Джо это объект. Типом такого объекта можно считать счет вообще, то есть "Счет" (account) это класс. Классы содержат данные и поведение (действия), влияющее на эти данные. Класс Account содержит идентификационный номер клиента и действия, проверяющие его. На диаграмме классов класс создается для каждого типа объектов из диаграмм последовательности или кооперативных диаграмм.
<<Entity>> Card Reader Card Number : integer Пример АТМ <<Boundary>> ATM Screen Accept Card() : integer Eject Card() : integer Read Card() : integer 0. . 1 <<Entity>> Account Prompt() : integer Accept. Input(Input : Integer) : integer 0. . 1 0. . n <<Boundary>> Cash Dispenser Account Number : integer PIN : integer Balance : long Open() : integer Withdraw Funds(Amount : long) : integer Deduct Funds(Amount : long) : integer Verify Funds() : integer Cash Balance : long 1 0. . 1 Provide Cash() : integer Provide Receipt() : integer 56
СТЕРЕОТИПЫ КЛАССОВ Стереотипы это механизм, позволяющий разделять классы на категории. Допустим, например, вы хотите найти все формы в вашей модели. Для этого можно создать стереотип Form (форма) и назначить его всем окнам вашего приложения. При поиске форм в дальнейшем надо только искать классы с этим стереотипом. В языке UML определены три основных стереотипа: Boundary (пограничные), Entity (сущности) и Control (управление).
ПОГРАНИЧНЫЕ КЛАССЫ Пограничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами. Чтобы найти пограничные классы, надо исследовать диаграммы вариантов использования. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать по крайней мере один пограничный класс. Именно такой класс позволяет действующему лицу взаимодействовать с системой. Необязательно создавать уникальные пограничные классы для каждой пары действующее лицо вариант использования. Например, если два действующих лица инициируют один и тот же вариант использования, они могут использовать общий пограничный класс для взаимодействия с системой.
КЛАССЫ СУЩНОСТИ Классы сущности (entity classes) содержат информацию, сохраняемую постоянно. Например, в системе работы с данными о сотрудниках таким классом является класс Employee (сотрудник). Классы сущности обычно можно обнаружить в потоке событий и на диаграммах взаимодействия. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области. Часто для каждого класса сущности создают таблицу в базе данных. В этом заключается еще одно отличие от типичного подхода к конструированию системы. Вместо того, чтобы с самого начала задать структуру базы данных, у нас теперь есть возможность разрабатывать ее на основе информации, получаемой из объектной модели. Это позволяет отслеживать соответствие всех полей базы данных и требований системы. Требования определяют поток событий. Поток событий определяет объекты, классы и атрибуты классов. Каждый атрибут класса сущности становится полем в базе данных. Применяя такой подход, можно легко отслеживать соответствие между полями базы данных и требованиями к системе, что уменьшает вероятность сбора ненужной информации.
УПРАВЛЯЮЩИЕ КЛАССЫ Рассмотрим теперь управляющие классы (control classes). Это классы, отвечающие за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. Управляющий класс отвечает за координацию, но сам не несет в себе никакой функциональности остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответственность другим классам. По этой причине управляющий класс часто называют классом менеджером. В системе могут быть и другие управляющие классы, общие для нескольких вариантов использования. Например, может быть класс Security. Manager (менеджер безопасности), отвечающий за контроль событий, связанных с безопасностью. Класс Transaction. Manager (менеджер транзакций) занимается координацией сообщений, относящихся к транзакциям с базой данных. Могут быть и другие менеджеры для работы с другими элементами функционирования системы, такими как разделение ресурсов, распределенная обработка данных или обработка ошибок. С помощью этих типов управляющих классов можно легко изолировать функциональность системы. Инкапсуляция в один класс, например, координации безопасности, может минимизировать последствия вносимых изменений. Любые изменения отвечающей за безопасность логики системы затронут только менеджера безопасности. Помимо упомянутых выше стереотипов можно создавать и свои собственные.
Пример (система регистрации курсов) Student Register for Courses Course Catalog <<control>> Registration. Controller 61
Методология RUP
ОСНОВНЫЕ ПРИНЦИПЫ RUP Итеративный 63 и наращиваемый подход к созданию ПО Планирование и управление проектом на основе функциональных требований к системе вариантов использования (Use case) Построение системы на базе архитектуры ПО
Общее представление RUP Стадии Начальная Уточнение Основные процессы стадия Конструирование Ввод в действие Построение бизнес-моделей Определение требований Анализ и проектирование Реализация Тестирование Развертывание Поддерживающие процессы Управление конфигурацией Управление проектом Создание инфраструктуры Предварит. итерация Итер. #1 #2 #n #n+1 #n+2 Итерации Итер. #m+1 64
ИТЕРАЦИИ 65 Итерация последовательность работ в рамках утвержденного плана, приводящая к созданию работоспособного варианта ПО (релиза) Итерация реализация одного или нескольких функциональных требований (вариантов использования)
ИТЕРАЦИИ: КОЛИЧЕСТВО И ПРОДОЛЖИТЕЛЬНОСТЬ Продолжительность зависит от: Количество итераций - 6 ± 3 Начальная стадия: Уточнение: 1. . 3 Конструирование : Ввод в действие: 0. . 1 1. . 3 1. . 2 66 + масштаба организации + размера проекта + технической сложности системы - технологического опыта и зрелости
“ 4+1” ПРЕДСТАВЛЕНИЕ АРХИТЕКТУРЫ зрения вариантов использования(Us e Case) Взгляд с точки зрения System integrators Performance процессов Scalability Throughput Концептуальный слой Programmers Software management Взгляд с точки зрения System engineering размещения ПОSystem topology Delivery, installation Communication Физический слой 67 End-user Functionality Взгляд с Точка зрения точки разработчиков ПО зрения проекта ПОВзгляд с точки
ИСТОРИЯ СОЗДАНИ Я RUP Rational Unified Process 2000 Rational Unified Process 5. 5 Realtime ROOM 1999 UML 1. 3 Project management Configuration & change Mgmt Requirements College Objectory UI design 1998 68 Rational Unified Process 5. 0 Performance testing Business Engineering OMT Booch 2000 Data Engineering Rational Objectory Process 4. 1 Rational Objectory Process 4. 0 Rational Approach UML 0. 8 10/1997 UML 1. 1 SQA Process 12/1996 Objectory Process 3. 8 1995
АРХИТЕКТУРА ТЕХНОЛОГИИ Два ортогональных измерения Горизонтальное измерение: динамическая структура Вертикальное измерение: статическая структура Исполнители (Workers), результаты (artifacts), действия (activities), рабочие процессы (workflows) 69 Жизненный цикл: стадии (phases), итерации, контрольные точки (milestones) Процессы: планирование, выполнение
Динамическая структура Стадии Начальная Уточнение Основные процессы стадия Конструирование Ввод в действие Построение бизнес-моделей 70 Определение требований Анализ и проектирование Реализация Тестирование Развертывание Поддерживающие процессы Управление конфигурацией Управление проектом Создание инфраструктуры Предварит. Итер. #1 #2 #n #n+1 #n+2 #m #m+1 итерация Итерации
СТАДИИ ЖИЗНЕННОГО ЦИКЛА ПО Начальная стадия Уточнение Конструирование Ввод в действие time Уточнение Планирование проекта, уточнение требований к ПО, определение архитектуры ПО Конструирование Реализация проекта Ввод в действие Поставка и развертывание ПО у Заказчика 71 Начальная стадия Определение масштаба и границ проекта
РАСПРЕДЕЛЕНИЕ РЕСУРСОВ Время 72 Объем работы Время Объем работы Месяцы Люди Конструирование Начальная стадия 10% 5% Уточнение 30% 20% Ввод в действие 50% 65% 10% Пример проекта: 2 года, 200 чел. -месяцев 2. 5 4 7 6 12 11 2. 5 8
НАЧАЛЬНАЯ СТАДИЯ На входе начальная концепция, финансы, существующая система, потребности, заявочные предложения На выходе начальный бизнес-план: концепция продукта критерии успешного завершения (например, ROI) начальная оценка риска оценка ресурсов для стадии уточнения начальные модели требований (10 -20% ): 20% ключевых вариантов использования начальный архитектурный прототип Контрольная точка: цели и требования 73
УТОЧНЕНИЕ На выходе: риски, управление разработкой и персоналом планирование итераций цели и измеримые критерии оценки результатов для последующих итераций Контрольная точка: базовая архитектура системы 74 базовая концепция системы модели требований (80% завершенности) базовая архитектура системы основные технические риски детальный план разработки
КОНСТРУИРОВАНИЕ Для каждой итерации: На входе план итерации реализуемые функциональные возможности: варианты использования, сценарии перечень возможных рисков зафиксированные дефекты измеримые критерии оценки результатов На выходе: обновленный продукт описание релиза тесты и результаты тестирования план следующей итерации 75
КОНСТРУИРОВАНИЕ (ПРОДОЛЖЕНИЕ) Для последней итерации: План развертывания (Deployment plan) разделение на пакеты расчет стоимости поддержка обучение выпуск продукта стратегия внедрения Пользовательская документация Контрольная точка: начальная эксплуатационная версия (бета-версия) 76
ВВОД В ДЕЙСТВИЕ На выходе: Обновленный (при необходимости) программный продукт Заключительный анализ производительности; дополнительные инвестиции; возможные направления развития Контрольная точка: Окончательная версия продукта 77
Статическая структура Стадии Начальная Уточнение Основные процессы стадия Конструирование Ввод в действие Построение бизнес-моделей 78 Определение требований Анализ и проектирование Реализация Тестирование Развертывание Поддерживающие процессы Управление конфигурацией Управление проектом Создание инфраструктуры Предварит. Итер. #1 #2 #n #n+1 #n+2 #m #m+1 итерация Итерации
РОЛИ, ДЕЙСТВИЯ, РАБОЧИЕ ПРОДУКТЫ Activities R ole 79 Use-Case Designer Artifact Find Design Classes responsible for Use Case in Design Distribute Behavior
РОЛЬ Роль определяет поведение и ответственность любого конкретного исполнителя или команды Поведение: набор взаимосвязанных действий Ответственность: определяется по отношению к конкретным рабочим продуктам 80
ПРИМЕРЫ РОЛЕЙ Системный аналитик Менеджер проекта Разработчик вариантов использования (Usecase designer) Разработчик тестов Разработчик учебных курсов 81
РОЛИ И КОНКРЕТНЫЕ СОТРУДНИКИ Worker Activities Paul Designer Define Operations. . . Mary Use-Case Specifier Describe a Use Case. . . Joe Use-Case Designer Distribute Behavior. . . Sylvia Design. Reviewer Review. Use-Case Model. . . Stefan Architect Define Use-Case View Define Logical Viiew. . . Каждый сотрудник в проекте выполняет одну или несколько ролей 82 Resource
ДЕЙСТВИЕ (ACTIVITY) Часть работы исполнителя Степень детализации: от нескольких часов до нескольких дней Единица планирования Повторяется, при необходимости, в каждой итерации 83
ПРИМЕРЫ ДЕЙСТВИЙ Планирование итерации Определение вариантов использования и действующих лиц (Find use cases and actors) Оценка проектных решений (Review the design) Выполнение нагрузочного теста (Execute performance test) 84
ШАГИ (STEPS) Действия разбиваются на шаги Виды шагов 85 Обдумывание (Thinking) Выполнение (Performing) Оценка результатов (Reviewing)
ПРИМЕР ДЕЙСТВИЯ И ШАГОВ 86 Действие: Определение вариантов использования и действующих лиц Шаг: Определение вариантов использования Шаг: Описание взаимодействия вариантов использования и действующих лиц Шаг: Объединение вариантов использования и действующих лиц в пакеты Шаг: Построение диаграммы вариантов использования Шаг: Обзор модели вариантов использования Шаг: Оценка полученных результатов
РАБОЧИЙ ПРОЦЕСС (WORKFLOW) Последовательность действий, направленных на получение значимого результата Основные процессы: Построение бизнес-моделей Определение требований Анализ и проектирование Реализация Тестирование Развертывание Поддерживающие процессы: Управление конфигурацией и изменениями Управление проектом Создание инфраструктуры 87
Пример: анализ и проектирование 88
РАБОЧИЙ ПРОДУКТ (ARTIFACT) Единица информации, создаваемая, модифицируемая или используемая в некотором процессе Определяет область ответственности Может выступать в качестве объекта управления конфигурацией Виды рабочих продуктов: Модели Документация Планы Рабочие продукты могут содержать другие рабочие продукты 89
ПРИМЕРЫ РАБОЧИХ ПРОДУКТОВ Проектная модель (Design model) Класс Вариант использования Тест План разработки ПО Релиз Оценка состояния проекта Перечень рисков 90
ДОПОЛНИТЕЛЬНЫЕ РЕСУРСЫ RUP Основные понятия (Concepts) Руководящие указания (Guidelines) Методики, правила, эвристики, контрольные таблицы …. Руководства по использованию инструментальных средств (Tool mentors) Шаблоны (Templates) для основных рабочих продуктов 91 Вводят основные определения, ключевые идеи
РУКОВОДЯЩИЕ УКАЗАНИЯ Представляют краткое, сжатое описание действий и шагов правила качественного оформления результатов конкретные методики трансформация одного рабочего продукта в другой использование UML Используются для оценки качества рабочих продуктов Адаптированы к условиям объекта внедрения технологии 92 собой правила, рекомендации, эвристики, поддерживающие действия и отдельные шаги
ПРИМЕРЫ РУКОВОДЯЩИХ УКАЗАНИЙ Руководства по моделированию: классы, варианты использования, пакеты, модели Руководства по программированию Руководства по проектированию пользовательского интерфейса Контрольные точки для оценки результатов 93
ИСПОЛЬЗОВАНИЮ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ Аналогичны Requisite. Pro Rational Rose So. DA Clear. Quest …. 94 руководящим указаниям Описывают использование конкретного инструментального средства для выполнения некоторых действий или их шагов Связаны со средствами Rational:
ШАБЛОНЫ Предопределенные рабочие продукты, прототипы: шаблоны Rational So. DA шаблоны документов MS Word планы MS Project шаблоны страниц MS Front. Page с конкретными действиями, порождающими соответствующие рабочие продукты Адаптированы к условиям объекта внедрения технологии 95 Связаны
РУКОВОДЯЩИЕ УКАЗАНИЯ, РУКОВОДСТВА, ШАБЛОНЫ Design Guideline 96 Activities Worker Designer Artifact Rose Tool Mentor Find Design Classes Distribute Behavior responsible for Use Case Realization Use Case Template
ИНСТРУМЕНТАЛЬНАЯ ПОДДЕРЖКА ПРОЦЕССОВ RUP Основные процессы Inception Elaboration Rose Transition So. DA Анализ и проектирование Реализация Rose Test. Studio So. DA Quantify So. DA 97 Requisite. Pro Требования Тестирование Construction Purify Performance. Studio Поддерживающие процессы Управление конфигурацией Управление проектом Clear. Case Clear. Quest Rational Unified Process
98 CASE-средство RATIONAL ROSE
CASE СРЕДСТВА, ПОДДЕРЖИВАЮЩИЕ UML Rational Rose (Rational Software) Paradigm Plus (Computer Associates) System Architect (Popkin Software) Microsoft Visual Studio Microsoft Visio ARIS Toolset Oracle Designer Silverrun …. 99
ОСНОВНЫЕ СВОЙСТВА RATIONAL ROSE l l l 100 l Построение моделей в нотациях UML, Booch, OMT с возможностью автоматического преобразования между ними Возможность описания системы на разных уровнях для различных категорий пользователей Генерация кодов на языках С++, Java, Visual. Basic, Power. Builder, CORBA IDL Генерация описаний баз данных на SQL (Data Modeler) Возможность восстановления моделей готовых приложений путем реверс-инжиниринга Возможность повторного использования проектных решений Поддержка групповой разработки
НАБОР ПОДДЕРЖИВАЕМЫХ МОДЕЛЕЙ State Diagrams Class Diagrams Use Case Diagrams 101 State Diagrams Scenario Diagrams Sequence Diagrams Model Scenario Diagrams Collaboration Diagrams Component Diagrams Activity Diagrams Deployment Diagram
ГЛАВНЫЙ ЭКРАН RATIONAL ROSE 102
ОСНОВНЫЕ РАЗДЕЛЫ МОДЕЛИ (ПРЕДСТАВЛЕНИЯ) Для группировки элементов представлений служат пакеты (packeges). Пакет может включать элементы модели и вложенные пакеты. 103 Use Case View Use Case Diagram (диаграмма вариантов использования) Activity Diagram (диаграмма деятельности) Logical View Class Diagram (диаграмма классов) Sequence Diagram (диаграмма последовательности) Collaboration Diagram (кооперативная диаграмма) Statechart Diagram (диаграмма состояний) Component View Component Diagram (диаграмма компонентов) Deployment View Deployment Diagram (диаграмма размещения)
Специальные шаблоны группировки элементов представлений (RUP) 104
СПОСОБЫ СОЗДАНИЯ ЭЛЕМЕНТОВ МОДЕЛИ В браузере с помощью ускоренного меню, вызываемого правой кнопкой мыши; Используя панель инструментов модели; Перетаскивая на модель существующие элементы из браузера или из другой модели. 105
ПОДДЕРЖКА КОЛЛЕКТИВНОЙ РАБОТЫ С МОДЕЛЬЮ Декомпозиция модели на управляемые единицы (controlled units) Возможность перемещать файлы модели и управляемых единиц в рабочие пространства разных пользователей, используя механизм виртуальных путей (virtual path) Возможность помещать файлы модели и управляемых единиц под конфигурационное управление. Встроенная поддержка Clear. Case и Visual Source. Safe Сравнение и интеграция моделей с помощью утилит Synchronizer и Model Integrator 106
ПОЛУЧЕНИЕ ОТЧЕТОВ Система отчетов (пункт меню "Reports") позволяет получить: Наиболее типичные отчеты об элементах модели (использование классов на диаграммах, нарушение правил доступа при вызове операций классов, не отнесенные к классам объекты, не привязанные к операциям класса сообщения, …) - в режиме просмотра; Документирование логического или компонентного представлений ("Reports / Documentation Report") - в формате Word; Получение типичных проектных документов ("Reports / So. DA Report") - в формате Word. 107 При необходимости получения отчетов произвольного содержания и формата следует использовать продукт Rational So. DA. Имеется возможность создать гипертекстовое
ИНТЕГРИРОВАННЫЙ КОМПЛЕКС RATIONAL SUITE 108 Rational Unified Process - технология Rational Rose - анализ и проектирование ПО Rational Requisite Pro - управление требованиями Rational Clear. Case - управление конфигурацией Rational Clear. Quest - управление изменениями Rational So. DA - документирование Отладка и тестирование Rational Purify - локализация ошибок времени выполнения Rational Pure. Coverage - идентификация участков кода, пропущенных при тестировании Rational Quantify - выявление «узких мест» , влияющих на производительность Rational Robot - разработка тестовых процедур (скриптов) Rational Team. Test - функциональное тестирование Rational Suite Performance. Studio - нагрузочное тестирование
RATIONAL SUITE - МНОГОПЛАТФОРМЕННАЯ АРХИТЕКТУРА UNIX-платформа Web Browser Моделирование Тестирование* Clear. Case 109 Разработчик Windows-платформа Web Server Аналитик Управление изменениями Управление требованиями Моделирование Clear. Case Разработчик Тестировщик Тестирование
Скачать презентацию ОБЪЕКТНООРИЕНТИРОВАННЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ Сущность объектно-ориентированного подхода
Раздел_2.2_ Объектно-ориентированный подход.ppt