МОСКОВСКИЙ ГОРОДСКОЙ ПЕДАГОГИЧЕСКИЙ УНИВЕРСТИТЕТ ПРОЕКТИРОВАНИЕ

МОСКОВСКИЙ ГОРОДСКОЙ ПЕДАГОГИЧЕСКИЙ УНИВЕРСТИТЕТ ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ © доцент Чискидов С. В. , 2009

Тема 5. Проектирование ИС на основе объектно-ориентированного подхода Учебные вопросы: 1. Сущность объектного подхода. 2. Унифицированный язык моделирования UML. 3. Диаграммы вариантов использования, классов, взаимодей- ствия, состояний, деятельностей, компонентов, размещения. 4. Пример использования объектно-ориентированного подхода. 5. Сравнение структурного и объектного подходов. 6. Лабораторная работа № 4. CASE RATIONAL ROSE (10 ч). Учебная цель: Изучить особенности методов и средств, применяемых при объектно-ориентированном подходе к проектированию ИС Литература: Вендров. А. М. Проектирование программного обеспечения 2 экономических информационных систем, М. : Фи. С, 2005, стр. 187 -251.

1. Сущность объектно- ориентированного подхода Структурный подход - в основе принцип функциональной декомпозиции , при которой структура ИС описывается в терминах иерархии функций и передачи информации между отдельными функциональными элементами. Недостатки: 1. Процессы и данные существуют отдельно друг от друга. 2. Структурные модели ИС более закрыты и труднее поддаются внесению изменений. 3. Невозможность использовать ОО ЯП в качестве средства реализации ИС. 4. Ориентирован на компьютерную реализацию. 5. Проектные решения не унифицированы. 3

1. Сущность объектно- ориентированного подхода Объектно-ориентированный подход - в основе принцип объектной декомпозиции, при которой статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы – в терминах обмена сообщениями между объектами. Достоинства: 1. Базируется на более устойчивых формах: данные стабильнее процессов. 2. Объектные модели ИС открыты и легче поддаются внесению изменений. 3. Возможность использовать ОО ЯП в качестве средства реализации ИС. 4. Ориентирован на человеческое восприятие мира. 5. Проектные решения унифицированы и пригодны для повторного использования. 4

1. Сущность объектно- ориентированного подхода (OOP) OOP=OOA + OOD + OOPr OOA – object-oriented analysis – объектно- ориентированный анализ (С. Шлеер, С. Меллор; 1979); OOD – object-oriented design – объектно-ориентиро- ванное проектирование (Г. Буч, Дж. Рамбо; 1986); OOPr – object-oriented programming – объектно- ориентированное программирование (Simula, Smaltalk, Ada, C++, Object Pascal, . . . 1960 – 1990). Концептуальная основа ООП – объектная модель (начало 70 -х г. ) 5

Принципы построения объектной модели: Абстрагирование (abstraction): выделяем наиболее важные, существенные характеристики объектов; Инкапсуляция (encapsulation): скрываем детали реализации; Модульность (modularity): декомпозируем на ряд слабо связанных подсистем; Иерархия (hierarchy): располагаем элементы системы по уровням. 6

Основные элементы объектной модели • объект; • класс; • атрибут; • операция; • полиморфизм; • наследование. Объект — предмет или явление (процесс), имеющие четко определяемое поведение. Представляет собой абстракцию некоторой сущности предметной области (объект реального мира) или программной системы (архитектурный объект). Характеризуется: Состоянием — свойства объекта и их значения; Поведением — действия объекта и его реакцию на запросы от других объектов; Индивидуальностью — отличие объекта от всех других объектов. 7

Характеристики объекта 8

Основные элементы объектной модели Класс — это множество объектов, связанных общностью свойств, поведения, СОТРУДНИК связей и семантики — ID cотрудника Объект = экземпляр класса + ФИО cотрудника Атрибут — поименованное свойство класса # ИНН cотрудника Виды атрибутов: + Адрес Общий (public)+ + Должность Закрытый (private) — # Зарплата Защищенный (protected)# ~ Отдел Реализация (implementation) ~ + Оплатить() Операция (метод) — это реализация + Продвинуть() услуги, которую можно запросить у + Переместить() любого объекта данного класса + Уволить() Имя Операции (аргумент1: тип данных аргумента 1, аргумент2: тип данных аргумента 2, . . . ): тип возвращаемого значения Полиморфизм — действия, выполняемые одноименными методами, могут различаться в зависимости от того, к какому из классов относится тот или иной метод. 9 Наследование — построение новых классов на основе существующих.

2. Унифицированный язык моделирования UML Unified Modeling Language – язык визуального моделирования, разработанный для спецификации, визуализации, проектирования, документирования компонентов программного обеспечения, бизнес-процессов и других элементов ИС Язык UML предлагает набор инструментальных средств, позволяющих проводить всесторонний анализ сложных ИС как с технической точки зрения, так и с точки зрения потребностей бизнеса. UML упрощает процесс проектирования ИС, снижает его стоимость и повышает эффективность. 10

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

2. Унифицированный язык моделирования UML август 2011 г. UML 2. 4. 1 UML – это стандартная нотация визуального моделирования программных систем, принятая организацией по стандартизации в области ООП Object Managing Group (OMG) Создатели языка: Гради Буч (BOOCH), Джеймс Рамбо (OMT), Ивар Якобсон (OOSE) 12

2. Унифицированный язык моделирования UML 13

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

Диаграммы в UML 15

3. 1. Диаграммы вариантов использования (use case diagrams) • Позволяет создать список операций, который выполняет система. • Создается список требований к системе и определяется множество выполняемых системой функций. Достоинства: определяет пользователей и границы системы; определяет системный интерфейс; удобна для общения пользователей с разработчиками; используется для написания тестов; является основой для написания пользовательской документации. 16

Элементы диаграммы вариантов использования Вариант использования (use cases) — последовательность действий (транзакций), выполняемых системой в ответ на событие, Оформление заказа инициируемое некоторым внешним объектом (действующим лицом). Действующее лицо (actor) — роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Клиент Отношения (association relationship) — взаимодействие между действующими лицами и вариантами использования. Связь коммуникации (unidirectional association) Зависимая связь (dependency) Связь обобщения (generalization) 17

Порядок выделения вариантов использования и действующих лиц Клиент, решивший оформить заказ на поставку товара, обраща- ется в офис фирмы. Менеджер согласовывает с клиентом все условия по оформлению заказа. При этом менеджер обязан проверить наличие на складе каждого из заявленных товаров. В случае если все затребованные клиентом позиции продуктов есть в наличии, либо клиентом приняты альтернативные варианты, заказ передается в бухгалтерию, бухгалтер выписывает счет и предлагается клиенту его оплатить. Если клиент оплачивает заказ по счету, то после оплаты бухгалтер выписывает две товарные накладные, которые передаются клиенту. После получения накладной клиент прибывает на склад за своим товаром. Кладовщик выдает необходимый товар и делает отметку в обоих экземплярах накладной о том, что заказ выдан. Далее, клиент расписывается в двух экземплярах накладной и отбывает с полученным товаром и одним экземпляром накладной. Второй экземпляр накладной остается у кладовщика. Менеджер — действующие лица 18 оформить заказ — варианты использования

Пример диаграммы вариантов использования Связь коммуникации (unidirectional association) Замечание (Note) Зависимая связь (dependency) Действующее лицо (actor) Связь обобщение (generalization) Вариант использования (use case) 19

Сценарий варианта использования Вариант использования "Вход в систему" (Login) Краткое описание. Данный вариант использова- ния описывает вход пользователя в ИС фирмы. Основной поток событий. Данный вариант использования начинает выполняться, когда пользователь хочет войти в ИС фирмы 1. Система запрашивает данные пользователя 2. Пользователь вводит имя и пароль. 3. Система проверяет имя и пароль, после чего открывает доступ в систему. Альтернативные потоки. Неправильное имя / пароль. Если во время выполнения Основного потока обнаружится, что пользователь ввел неправильное имя и/или пароль, ИС выводит сообщение об ошибке. Пользователь может вернуться к началу Основного потока или отказаться от входа в ИС, при этом выполнения варианта использования завершается. Предусловия. Отсутствуют. Постусловия. Если вариант использования выполнен успешно, пользователь входит в ИС. В противном случае состояние ИС не изменяется. 20 Расширения. Отсутствуют.

3. 2. Диаграммы классов (Class diagrams) Эти типы совсем не „абстрактные”, они настолько же реальны, как int и float. – Дуг Мак. Илрой (о классах) Диаграмма классов определяет типы классов системы и различ- ного рода статические связи, которые существуют между ними. Классы могут представлять: • сущности предметной области (в процессе анализа); • элементы программной системы (в процессах проектиро- вания и реализации). Основные элементы диаграммы: Имя класса: существительное в ед. числе, соответствующее понятиям Пр. О Атрибут: описывает свойство объектов Атрибуты класса; имя должно быть уникально в класса пределах класса, содержать тип; бывает: Общий (public) Операции класса Защищенный (protected) Закрытый (private) Операция: функция или преобразование объектов класса; 21 может содержать параметры и возвращать значения.

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

3. 2. 1. Виды связей между классами Агрегация (aggregation) – это ассоциация типа «целое- часть» . Агрегация в UML представляется виде прямой с ромбом на конце. Ромб на связи указывает, какой класс является агрегирующим (т. е. «состоящим из» ), — класс с противоположного конца — агрегированным (т. е. те самые «части» ). Композиция (composition) – это такая агрегация, где объекты-части не могут существовать сами по себе и уничтожаются при уничтожении объекта агрегирующего класса. Композиция изображается так же как ассоциация, только ромбик закрашен. Важно понимать разницу между агрегацией и композицией: при агрегации объекты-части могут существовать сами по себе, а при композиции — нет. Пример агрегации: автомобиль—колесо, пример композиции: дом—комната. 23

3. 2. 1. Виды связей между классами Наследование (inheritance) – это отношение типа «общее- частное» . Позволяет определить такое отношение между классами, когда один класс обладает поведением и структурой ряда других классов. При создании производного класса на основе базового (одного или нескольких) возникает иерархия наследования. Реализация принципов наследования является ключевой предпосылкой возможности повторного использования кода, поскольку это основной инструмент достижения полиморфизма. 24

3. 2. 2. Пример диаграммы классов 25

3. 2. 3. Диаграммы пакетов (Package Diagrams) • содержат группы классов, обладающих некоторой общностью, и зависимости между ними; • основное средство управления общей структурой системы. Пакет Граничные классы (Boundaries) - посредники при взаимодействии внешних объектов с системой (интерфейс); Классы-сущности (Entities) -ключевые абстракции; Управляющие классы (Control) - координация поведения объектов 26

3. 3. Диаграммы взаимодействия (Interaction diagrams) • описывают поведение взаимодействующих групп объектов; • охватывают поведение объектов в рамках только одного потока событий варианта использования; • изображаются объекты и те сообщения, которыми они обмениваются между собой. Сообщение (message) — средство, с помощью которого объект- отправитель запрашивает у объекта-получателя выполнение одной из его операций. Информационное (informative) сообщение — сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния. Сообщение-запрос (interrogative) — сообщение, запрашивающее выдачу некоторой информации об объекте-получателе. Императивное (imperative) сообщение — сообщение, запрашивающее у объекта-получателя выполнение некоторых действий. Виды: • диаграммы последовательности (sequence diagrams); • диаграммы кооперации (кооперативные) (collaboration diagrams). 27

3. 3. 1 Диаграммы последовательности (Sequence diagrams) Сообщение Объект (экземпляр класса) Линия жизни объекта Самоделегирование Замечание (Note) Отражают временную последовательность событий, происходящих в рамках варианта использования Возврат 28

3. 3. 2 Диаграммы кооперативные (Collaboration diagrams) (F 5) Последовательный номер Самоделегирование Объект (экземпляр класса) Сообщение Отображают поток событий варианта использования и 29 концентрируют внимание на связях между объектами

Когда применять диаграммы последовательности ? + Диаграммы взаимодействия отображают простое поведение; + Для описания поведения нескольких объектов в рамках одного варианта использования; — Диаграммы взаимодействия при сложном поведении теряют наглядность => Диаграмма деятельностей; — Описание поведения ! объекта во многих ВИ => Диаграмма состояний; 30

3. 4. Диаграммы состояний (Statechart diagrams) • используются для описания поведения объекта во многих вариантах использования; • определяют все возможное состояния конкретного объекта; • определяют процесс смены состояний объекта в результате наступления некоторых событий; • изображаются состояния, поведение, переходы и события. Не обязательно создавать для каждого класса! Элементы диаграммы: Проверка позиции заказа Состояние do/ проверить позицию Поведение: деятельность v действие Получить первую позицию заказа Метка перехода Переход Спецификация метки перехода: <Событие>[<Условие>]/<Действие> 31

Описание элементов диаграммы состояний Деятельность (activity) — это поведение, реализуемое объектом, пока он находится в данном состоянии. Может выполняться до своего завершения, пока объект находится в данном состоянии, или может быть прервано переходом объекта в другое состояние. Изображают внутри самого состояния, ей должно предшествовать слово do (выполнять) и двоеточие. Входное действие (entry action) — это поведение, которое выполняется, когда объект переходит в данное состояние. Является непрерываемым. Изображают внутри состояния, ему предшествует слово entry (вход) и двоеточие. Выходное действие (exit action) — это поведение, которое выполняется, когда объект выходит из данного состояния. Является непрерываемым. Изображают внутри состояния, ему предшествует слово exit (выход) и двоеточие. Переход (transition) — перемещение объекта из одного состояния в другое. Изображают в виде стрелки, начинающейся на первоначальном состоянии и заканчивающейся на последующем. Могут быть рефлексивными. У перехода существует несколько спецификаций, основными из которых являются события, ограждающие условия и действия. Событие (event) вызывает переход из одного состояния в другое. Изображают на диаграмме вдоль линии перехода. Ограничивающие условия (guard conditions) определяют, когда [переход может, а когда не может осуществиться]. 32 /Действие (для перехода).

Пример диаграммы состояний Событие Начальное состояние Конечное состояние Входное действие Действие Условие Деятельность Переход в то же состояние Переход Состояние 33

Когда применять диаграммы состояний? + Только для тех классов, поведение которых действительно интересует: пользовательский интерфейс, управляющие объекты; — Несколько объектов и несколько ВИ => Диаграмма деятельностей. 34

3. 5. Диаграммы деятельностей (Activity diagrams) • для описании поведения, включающего большое количество параллельных процессов; • при параллельном программировании; • анализ потоков событий в конкретном варианте использования; • анализ потоков событий в различных вариантах Элементы диаграммы: использования. Получить заказ Деятельность Условие Линейки синхронизации Получить первую позицию заказа Метка перехода Переход Спецификация метки перехода: 35 <Событие>[<Условие>]/<Действие>

Описание элементов диаграммы деятельностей Деятельность (activity) — некоторая задача, которую необходимо выполнить вручную или автоматизированным способом, или операция класса; Объект и поток объектов (object flow); Переход (state transition) — стрелка перехода от одной деятельности к другой; Линейка синхронизации (horizontal/vertical synchronization) — параллельное выполнение двух и более ветвей потока; Условие (decision) — деятельность, связанная с принятием решения; "Плавательная дорожка" (swimlane) — для анализа потоков события в разных вариантах использования. Один ВИ — одна "дорожка". 36

Пример диаграммы деятельностей Событие перехода Переход Деятельность Условие перехода Линейка синхронизации 37

Пример диаграммы деятельностей Плавательная дорожка 38

Когда применять диаграммы деятельностей? + Поддержка параллелизма; — Связи между действиями и объектами просматриваются не совсем четко. + анализ варианта использования: какие действия должны иметь место и каковы зависимости в поведении системы; + анализ потоков работ в различных вариантах использования. — анализ взаимодействия объектов => Диаграмма взаимодействия; — анализ поведения объекта в течении его ЖЦ => Диаграмма состояний. 39

3. 6. Диаграммы компонентов (Component diagrams) • моделируют физический уровень системы; • изображаются компоненты ПО и связи между ними; • выделяют два типа компонентов: исполняемые компоненты и библиотеки кода; • каждый класс модели (или подсистема) преобразуется в компонент исходного кода; • между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы; • применяются теми участниками проекта, кто отвечает за компиляцию и сборку системы. Они нужны там, где начинается генерация кода. 40

Пример диаграммы компонентов #ifndef НАКЛАДНАЯ_H_HEADER_INCLUDED_B 61 C 3 D 6 E #define Зависимость НАКЛАДНАЯ_H_HEADER_INCLUDED_B 61 C 3 D 6 E class Накладная { public: Показать. Статус(); Изменить Статус(); private: String Статус; Date Дата. Время. Отгрузки; Currency Сумма; Double Вес; String Примечание; String ФИОПолучателя; }; #endif /* НАКЛАДНАЯ_H_HEADER_INCLUDED_B 61 C 3 D 6 E */ Спецификация пакета (. H) Тело пакета (. CPP) 41

3. 7. Диаграммы размещения (Deployment diagrams) • отражает физические взаимосвязи между программными и аппаратными компонентами системы; • является хорошим средством для того, чтобы показать размещение объектов и компонентов в распределенной системе; • используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом, чтобы понять физическое размещение системы и расположение ее отдельных подсистем Элементы диаграммы: узел (node) — вычислительный ресурс — процессор или другое устройство (дисковая память, контроллеры различных устройств и т. д. ). Для узла можно задать выполняющиеся на нем процессы; соединение (connection) — канал взаимодействия узлов (сеть). 42

Пример диаграммы размещения Узлы Соединение Компонент ПО 43

Достоинства UML 1. UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках. 2. UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы. 3. Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом. 4. UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии. 5. UML получил широкое распространение и динамично развивается. 44

Недостатки UML 1. Избыточность языка. UML включает много избыточных или практически неиспользуемых диаграмм и конструкций. 2. Неточная семантика. Это отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций. 3. Проблемы при изучении и внедрении. 4. «Только код отражает код» . Ещё одно мнение — что важны рабочие системы, а не красивые модели. 5. Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа одной системы воспринять выход другой. 6. Пытается быть всем для всех. UML — это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. 45

CASE-средства, поддерживающие UML IBM Rational Rose ; Paradigm Plus -> All. Fusion Component Modeler; System Architec; MS Visual Modeler for Visual Basic; Delphi; Power. Builder; CASEBarry; Borland Together, Poseidon, Star. UML и Dia – free; Microsoft Visio; Telelogic TAU G 2; http: //www. gskinner. com/gmodeler/app/run. html онлайновое средство UML-проектирования (Flash). 46

CASE-средства, поддерживающие UML 47

CASE-средства, поддерживающие UML 48

Выводы • Идентификация классов и объектов – одна из важных задач объектно-ориентированного подхода; • Инкапсуляция, наследование и полиморфизм – три кита, на которых держится ООП; • UML – еще один формальный язык, который необходи- мо освоить каждому, кто собирается заниматься проект- ированием ИС; • Знание UML не гарантирует построения разумных и понятных моделей, хотя и является для этого необходимым; • Проектирование – не рисование диаграмм: диаграммы описывают существенные детали проекта; • Диаграммы разных видов позволяют взглянуть на систему с разных точек зрения; • Использование CASE-средств – условие успешного применения ООП для проектирования ИС; • Недостаточно читать об UML – им надо пользоваться! 49