Объектноориентированный подход к созданию ИС Сравнение структурного и объектноориентированного подходов автоматическое кодирование «+» проверенность временем простота масштабирования большое количество CASE-средств «открытость» UML для дополнения «наглядность» и однозначность объектно- структурный ориентированный подход подход возможность неоднозначной трактовки диаграмм сложность исправления ошибок проектирования сложность моделирования высокие требования к квалификации трудности для экспертов динамики процесса «-» жесткий регламент методологии Жизненный цикл ИС модели ЖЦ каскадная поэтапная спиральная По мнению ведущих «+»: 1. на каждой стадии «+»: межэтапные специалистов в формируется законченный корректировки набор проектной обеспечивают большую области создания ИС, «+»: возможность realдокументации, достаточной гибкость и меньшую спиральная модель в time работы с для того, чтобы разработка трудоемкость по заказчиком; наибольшей мере могла быть продолжена другой сравнению с каскадной отсутствие запаздывания обеспечивает группой разработчиков; моделью результатов. 2. возможность планирования повышается решение «-»: сложность сроков завершения работ и надежность. возникающих в определения момента затрат на их выполнение «-»: время жизни процессе перехода на работы следующий «-»: сложно уложить реальный каждого из этапов может этап проблем процесс создания растянуться на весь программного обеспечения в период создания такую жесткую схему системы Стандарты ЖЦ ИС краткий обзор стандартов ЖЦ ИС; подход Уайта; ISO/IEC 12207:1995; ГОСТ 34.601 -90; корпоративные стандарты ЖЦ ИС. Основные положения Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки. Существующие стандарты ЖЦ ИС ГОСТ 34.601 90 ISO/IEC 12207: 1995 Oracle CDM RUP … MSF XP подход Уайта Вопрос: Перечислите известные Вам стандарты ЖЦИС Вопросы: Какие из перечисленных стандартов регламентируют модель ЖЦИС? Какие из перечисленных стандартов описывают структуру ЖЦИС? Какие из перечисленных стандартов описывают и модель и структуру ЖЦИС??? Существующие стандарты ЖЦ ИС ГОСТ 34.601 90 ISO/IEC 12207: 1995 Oracle CDM RUP … MSF XP подход Уайта Вопрос: Перечислите известные Вам стандарты ЖЦИС Вопросы: Какие из перечисленных стандартов регламентируют модель ЖЦИС? Какие из перечисленных стандартов описывают структуру ЖЦИС? Какие из перечисленных стандартов описывают и модель и структуру ЖЦИС??? Предпосылки появления объектноориентированного подхода к созданию ИС Технологии программирования; OOP; OOA; OOD; Язык UML Развитие технологий программирования Машинные коды Языки высокого уровня Потерянное поколение (1970-198?) 3-е поколение (1962-1970) 2-е поколение (1959-1961) 1-е поколение (1954-1958) 40-е – 50-е 50-е – 80-е 90-е – настоящее время Развитие технологий программирования Машинные коды Языки высокого уровня алгоритмические процедурные Объектноориентированные функциональные … 40-е – 50-е 50-е – 80-е 90-е – настоящее время Понятие ООР ООР (object-oriented programming) – это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования Понятие ООD ООD (object-oriented design) – это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы. Понятие ООА ООD (object-oriented analysis) – это методология, при использовании которой требования к проектируемой системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области. Соотношение OOA, OOD и ООР ООР ООАП ООD ООА Методы ООАП и ООР базируются на стандартном (унифицированном) языке моделирования UML Язык UML История UML; Назначение UML; Структура UML; UML диаграммы; ПО поддерживающее UML Основные понятия Унифицированный язык моделирования (Unified Modelling Language, UML) является графическим языком для визуального представления, составления спецификаций, проектирования и документирования систем, в которых большая роль принадлежит программному обеспечению. Гради БУЧ. История UML RSC Джеймс Рамбо, Метод Рамбо ГардиДжекобсон, Буч, Метод Буча Айвар Метод (ОМТ-2), ориентированный (Booch'93), Джекобсона (метод OOSE), на анализ процессов ориентированный, в первую ориентированный на анализ обработки данных в очередь, на моделирование требований к бизнесинформационных системах программного обеспечения приложениям сложных систем Требования к UML Позволяет моделировать как программное обеспечение сложных систем, так и широкие классы самих систем и бизнесприложений, с использованием объектно-ориентированных понятий и методов Обеспечивает взаимосвязь между базовыми понятиями моделей концептуального, программного и физического уровней Понятен системным аналитикам и программистам Поддерживается специальными инструментальными программными средствами, реализованными на различных компьютерных платформах Назначение UML ВОПРОСЫ Зачем нужно моделирование при создании ИС? В каком случае можно обойтись без моделирования? Что такое view point модели? Назначение UML Воображаемая модель компьютерной программы Объект автоматизации программист Исходный код программы Без UML Исполнимый код Назначение UML Воображаемая модель компьютерной программы Объект автоматизации программист UML диаграммы и спецификации Исходный код программы С UML Теория графов и теория множеств Исполнимый код Модель с позиций ООАП С точки зрения методологии ООАП достаточно полная модель сложной системы представляет собой определенное число взаимосвязанных представлений (views), каждое из которых адекватно отражает аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое, которые в свою очередь могут подразделяться на другие более частные. Структура UML Сущности 1. 2. 3. 4. 1. 2. 3. 4. 5. 6. 7. Структурные Поведенческие Группирующие Аннотационные Отношения Диаграммы 1. Классов 2. Объектов 3. Прецендентов 4. Последовательностей 5. Коопераций 6. Состояний 7. Действий 8. Компонентов 9. Развертывания Структурные Сущности являются основными объектноориентированными элементами языка. С их Классы помощью можно создавать корректные Интерфейсы модели. Структурные сущности - это имена Кооперации существительные в моделях на языке UML. Как Преценденты Поведенческие правило, они представляют собой статические Активные классы Группирующие Аннотационные части модели, соответствующие Компоненты 1. Взаимодействия концептуальным или физическим Узлы 2. Автоматы 1. Пакет 1. элементам Примечания системы 1. 2. 3. 4. Включения Ассоциаций Обобщений Расширения Класс (class) Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой Интерфейс (interface) Интерфейс (interface) - это совокупность операций, которые определяют определенную службу (сервис, набор услуг), которые предоставляет класс или компонент. На диаграммах интерфейс изображается в виде круга, под которым указывается его имя, как это показано на рис. Интерфейс очень редко, практически никогда, существует сам по себе обычно он присоединяется к реализующему его классу или компоненту. Кооперация (collaboration) Кооперация (collaboration) определяет взаимодействие, она представляет собой совокупность ролей и других элементов, которые, работая вместе, производят некоторый кооперативный эффект, не сводящийся к обычно сумме слагаемых. Прецедент (use case) Use Case (Прецедент/Вариант использования) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (actor). Активный классом (active class) Активным классом (active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие. ClassName -PrivateAttribute : char #ProtectedAttribute +PublicAttribute +Operation1(in S : String) +Operation2() Компонент (component) Компонент (component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. Узел (node) Узел (node) - это элемент реальной (физической) системы, который существует во время функционирования программного продукта и представляет собой некоторый вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и возможностью обработки. Перечисленные семь базовых элементов: классы, интерфейсы, кооперации, прецеденты, активные классы, компоненты и узлы - являются основными структурными сущностями, которые могут быть использованы в модели UML. Существуют и другие разновидности сущностей: актеры, сигналы, утилиты (виды классов), процессы и нити (виды активных классов), приложения, документы, файлы, библиотеки, страницы и таблицы (виды компонентов). UML диаграммы Общие положения Совокупность диаграмм UML позволяет получить интегрированную модель сложной системы Общие положения Диаграмма вариантов использования Диаграмма кооперации Диаграмма компонентов Диаграмма классов Интегрированная модель системы Диаграмма последовательности Диаграмма состояний Диаграмма деятельности Диаграмма развертывания Отношения диаграмм ООАП ориентирован на итеративную разработку UML диаграмм. Порядок и составВОПРОС: разработки диаграмм ВОПРОС: определяет: В каком порядке рисовать диаграммы??? Какие модели ЖЦ ориентированы на 1. выбранная итеративную методология (RUP, MSF, OrCDM…); разработку??? Все ли виды диаграмм рисовать??? 2. специфика конкретного проекта. UML НИКАК НЕ РЕГЛАМЕНТИРУЕТ ПОРЯДОК И СОСТАВ РАЗРАБОТКИ ДИАГРАММ. Отношения диаграмм (вариант 1) Component diagram Use Case diagram Class diagram Statechart diagram Use Case Deployment diagram Sequence diagram Colloboration diagram Отношения диаграмм (вариант 2) потребности пользователей выявление анализ Use Case diagram Component diagram Use Case Colloboration diagram Sequence diagram дизайн программная реализация кодирование Class diagram Statechart diagram Deployment diagram Отношения диаграмм (вариант 3) Отношения диаграмм (вариант 4) Отношения диаграмм (вариант 5) … Отношения диаграмм (вариант N) UseCase диаграмма Понятие Use Case диаграмма; Назначение; Элементы UseCase диаграммы UseCASE диаграмма UseCase диаграмма (диаграмма вариантов использования / диаграмма прецедентов) – это графическое представление всех или ВОПРОСЫ: части актеров, прецедентов и взаимодействий между ними. В каждой 1.Перечислите лиц системе обычно всех есть актеров главная (действующих диаграмма прецедентов, которая взаимодействующих с банковским в процессе его описывает внешнюю границу системы иавтоматом основные внешние функции работы). (внешнее поведение) системы. 2.Перечислите все отображает прецеденты сферу банковского автомата, UseCase диаграмма применения создаваемой инициируемые актерами. системы. Для каждого UseCase должно быть проведено документирование потока событий (краткое описание; предусловия; основной поток событий; альтернативные потоки событий; потоки ошибок; Отобразите актеров и прецеденты на схеме и проставьте стрелки, постусловия) Пример диаграммы UseCase показывающие направление потоков информации. для банковского автомата (ATM) UseCASE диаграмма Use Case диаграммы описывает общую функциональность системы. ПОЛЬЗОВАТЕЛИ (для кого полезна Use Case диаграмма) Менеджеры проекта Аналитики Разработчики Менеджеры по качеству ВСЕ, кого интересует система «в целом», изучая UseCase диаграммы могут получить представление о том, что система должна делать Диаграмма прецедентов (use case diagram) Диаграмма прецедентов (use case diagram) Поскольку в общем случае актер – это графическое представление всех или части всегда находится вне системы, актеров, прецедентов и взаимодействий между егоВвнутренняя структура никак ними. каждой системе обычно есть главная диаграмма прецедентов, которая описывает не определяется. Для актера внешнюю границу системы и основные внешние имеет значение только его функции (внешнее поведение) системы. внешнее представление, т.е. то, Актер (actor) — согласованное как ролей, он воспринимается со множество которые играют внешние сущности по стороны системы. отношению к вариантам использования при взаимодействии с ними Типы связей UseCase диаграмм коммуникации использования (communication) (uses) UseCase Actor расширения (extends) UseCase UseCase Обобщения действующего лица (actor generalization) Actor Actor <<uses>> Стрелки, используемые для обозначения Uses relationship позволяет одному клиент UseCase <<extends>> снятьне деньгипоказывают связей направления задействовать функциональность другого. relationship позволяет одному UseCase только С Extends помощью actor generalization relationship показывают, <<uses>> информационных потоков. Стрелка при необходимости задействовать функциональность что у нескольких лиц имеются общие Аутеннтифицировать клиента моделируют снятьдействующих деньги С помощью Uses relationship обычно клиент снять деньги другого. черты. показывает только кто/что инициирует произвести ускоренную выплату многократно применяемую функциональность, Положить деньги на счет встречающуюся в двух Корпоративный или более UseCase. Индивидуальный коммуникацию клиент клиент Пакеты UML позволяет сгруппировать в пакеты такие действующие лица как: UseCase; Class; NewPackage Components. Отношения диаграмм (повторение) потребности пользователей выявление анализ Use Case diagram Component diagram Use Case Colloboration diagram Sequence diagram дизайн программная реализация кодирование Class diagram Statechart diagram Deployment diagram Диаграммы взаимодействия Виды диаграмм взаимодействия; Диаграмма Последовательности (Sequence); Назначение диаграммы последовательности; Элементы диаграмм последовательности; Кооперативная диаграмма (Collaboration) Назначение кооперативной диаграммы; Элементы кооперативной диаграммы; Отношение диаграммы последовательности и кооперативной диаграммы; Отношение диаграмм взаимодействия и UseCase диаграмм Диаграммы взаимодействия На диаграмме взаимодействия (Interaction) отображают один из процессов обработки информации в UseCase. Виды диаграмм взаимодействия Диаграмма Последовательности (Sequence) Кооперативная диаграмма (Collaboration) Диаграммы Последовательности Диаграммы Последовательности (Sequence) отражают поток событий, происходящих в рамках UseCase. Разработка диаграмм последовательности проводится на основе документации по UseCase. Понятие объект Объектом называют нечто, заключающее (инкапсулирующее) в себе некоторые данные и поведение. Это термин, описывающий реальные, конкретные предметы. Класс (class) - это некая сущность, представляющая собой как бы схему объекта. Класс определяет данные и поведение, которыми должен обладать объект Понятие класс Диаграммы Последовательности Диаграммы Последовательности (Sequence) отражают поток событий, происходящих в рамках UseCase. Разработка диаграмм последовательности проводится на основе документации по UseCase. ВОПРОСЫ: Перечислите все действующие лица и объекты, необходимые системе для выполнения прецедента снять деньги со счета. Пример диаграммы последовательности снятия денег со счета через банковский автомат Диаграмма последовательности диаграмма Последовательности иллюстрирует последовательность действий, реализующих вариант использования Аналитики видят последовательность (поток) действий, разработчики — объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы Последовательности полезны всем участникам проекта. Кооперативная диаграмма (Collaboration) Подобно диаграммам Последовательности, Диаграммы Последовательности и Кооперативные диаграммы отображают поток событий в конкретном сценарии прецедента. В отличие от диаграмм Кооперативные диаграммы Последовательности, Кооперативные диаграммы больше содержат одну ту объектами же внимания заостряют на связях и между информацию, но используются для разных ЦЕЛЕЙ. ВОПРОС: Зачем нужно создавать 2 разные диаграммы, содержащие одну и ту же информацию? Задание Построить кооперативную диаграмму на основе диаграммы Последовательности А алгоритм-то тривиальный Отношение диаграммы последовательности и кооперативной диаграммы Существует тривиальный алгоритм преобразования диаграмм последовательности в кооперативные диаграммы и обратно. Rational Rose обеспечивает автоматическое преобразование диаграммы последовательности в кооперативную диаграмму. Задание Создайте диаграмму Последовательности и Кооперативную диаграмму, отражающую ввод нового заказа в систему обработки заказов Продавец Форма выбора варианта заказа: ВыборЗаказа Форма Детали заказа: ДеталиЗаказа Менеджер заказов: МенеджерЗаказов Заказ №1234: Заказ Компект мебели: ПозицияЗаказа Менеджер транзакций: Менеджер транзакций 1: Cre ate () 2: Ope n() 3: Subm itInfo() 4: Save () 5: Save Orde r() 6: Cre ate () 7: Se tInfo() 8: Cre ate () 9: Se tInfo() 10: SaveOrde r() 11: Ge tInfo() 12: Ge tInfo() 13: Com m it() <<Граница>> ВыборЗаказа <<Управление>> МенеджерЗаказов 0..1 Create() 0..1 SaveOrder() 0..1 1 0..1 0..1 <<Граница>> ДеталиЗаказа <<Управление>> МенеджерТранзакций 0..1 0..1 Open() SubmitInfo() Save() 0..* <<Сущность>> Заказ 0..1 0..* OrderNumber: Integer CustomerName: String OrderDate: Date OrderFillDate: Date Сreate(): Boolean SetInfo(): Boolean GetInfo(): String 1 1..* <<Сущность>> ПозицияЗаказа ItemId: Integer ItemDescription: String Сreate() SetInfo() GetInfo() SaveOrder() Commit() 0..*