- •5. Понятие и предметы url.
- •13. Объекты.
- •14. Классы.
- •15. Диаграммы классов.
- •16. Отношения в диаграммах классов
- •17. Деревья наследования
- •18. Автоматы.
- •19. Диаграммы взаимодействия.
- •20. Диаграммы use case
- •21. Компоненты диаграммы.
- •22. Диаграммы размещения.
- •23. Принципы и особенности проектирования интегрированных ис
- •24. Системы управления информационными потоками как средство интеграции приложений
- •25. Организация взаимодействия прикладных программ на основе интерфейсов corba и com
- •26. Организация связи с разнородными базами данных на основе драйверов odbc
- •27. Открытые ис: основные свойства и межсистемные интерфейсы
Технология конструирования программного обеспечения (ТКПО) – это система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах.
Методы ТКПО обеспечивают решение следующих задач:
планирование и оценка проекта;
анализ системных и программных требований;
проектирование алгоритмов, структур данных и программных структур;
кодирование;
тестирование;
сопровождение.
Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).
Процедуры ТКПО соединяют методы и утилиты так, что они обеспечивают непрерывную технологическую цепочку разработки.
Процедуры определяют:
порядок применения методов и утилит;
формирование отчетов, форм по соответствующим требованиям;
контроль, который помогает обеспечивать качество и координировать изменения;
формирование «вех», по которым руководители оценивают процесс.
Стратегии конструирования:
однократный проход (водопадная стратегия) – линейная последовательность этапов конструирования с определением всех требований в начале процесса;
инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система (запланированное улучшение продукта);
эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий.
Классический жизненный цикл ПО:
Макетирование:
Инкрементная модель:
Быстрая разработка приложений (RAD - Rapid Application Development):
Спиральная модель:
где:
1 – начальный сбор требований и планирование проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальный требований;
4 – анализ риска на основе реакции заказчика; 5 – переход к комплексной системе;
6 – начальный макет системы; 7 – следующий уровень макета;
8 – сконструированная система; 9 – оценивание заказчиком.
Компонентно-ориентированная модель:
ХР-процесс Экстремальное программирование:
Модели качества процессов конструирования.
Процесс руководства проектом.
Время
Работы, выполняемые в процессе руководства проектом:
Начало проекта
Измерения, меры и метрики
Процесс оценки
Анализ риска
Планирование
Трассировка и контроль
Планирование проектных задач.
WBS – Work Breakdown Structure (структуры распределения работ)
Системный анализ:
Системный анализ проводится с целью:
выяснения потребностей заказчика;
оценки выполнимости системы;
выполнения экономического и технического анализа;
распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.);
определения стоимости и ограничений планирования;
создания системной спецификации.
В системной спецификации описываются функции, характеристики системы, ограничения разработки, входная и выходная информация.
Анализ требований:
Анализ требований дает возможность:
определить функции и характеристики программного продукта;
обозначить интерфейс продукта с другими системными элементами;
определить проектные ограничения программного продукта;
построить модели: процесса, данных, режимов функционирования продукта;
создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.
Результаты анализа сводятся в спецификацию требований к программному продукту.
Правило распределения затрат проекта
Рекомендуемое правило распределения затрат проекта – 40-20-40:
на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ – 5%);
на кодирование – 20%;
на тестирование и отладку – 40%.
5. Понятие и предметы url.
UML – это язык для определения, визуализации, конструирования и документирования артефактов программных систем, а также для моделирования экономических процессов и других не программных систем.
UML обладает следующими основными характеристиками:
является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков;
содержит механизмы расширения и специализации базовых концепций языка.
Структурные предметы:
Класс реализует один или несколько интерфейсов
Графически класс отображается в виде прямоугольника, обычно включающего секции с именем, свойствами (атрибутами) и операциями.
Интерфейс описывает поведение элемента, видимое извне
Интерфейс может представлять полные услуги класса или компонента или часть таких услуг
Графически интерфейс изображается в виде кружка с именем
Имя интерфейса обычно начинается с буквы «I».
Кооперации имеют как структурное, так и поведенческое измерения
Конкретный класс может участвовать в нескольких кооперациях
Графически кооперация изображается как пунктирный эллипс, в который вписывается ее имя.
Актер. Каждая роль требует от системы определенного поведения
Изображается как проволочный человечек с именем.
В модели элемент Use Case применяется для структурирования предметов поведения.
Элемент Use Case реализуется кооперацией.
Изображается как эллипс, в который вписывается его имя.
Активный класс. Похож на обычный класс за исключением того, что его объекты действуют одновременно с объектами других классов
Изображается как активный прямоугольник, обычно включающий имя, свойства (атрибуты) и операции.
Обычно компонент – это физическая упаковка различных логических элементов (классов, интерфейсов и сотрудничеств)
Изображается как прямоугольник с вкладками, обычно включающий имя.
Узел. В узле размещается набор компонентов, который может перемещаться от узла к узлу. Изображается как куб с именем.
Предметы поведения:
Взаимодействие может определять динамику как совокупности объектов, так и отдельной операции
Элементами взаимодействия являются сообщения, последовательность действий (поведение, вызываемое сообщением) и связи (соединения между объектами)
Сообщение изображается в виде направленной линии с именем ее операции.
С помощью конечного автомата может определяться поведение индивидуального класса или кооперации классов
Элементами конечного автомата являются состояния, переходы (от состояния к состоянию), события (предметы, вызывающие переходы) и действия (реакции на переход)
Изображается как закругленный прямоугольник, обычно включающий его имя и его подсостояния (если они есть).
Группирующие предметы:
В пакет могут помещаться структурные предметы, предметы поведения и даже другие группировки предметов
Пакет – это чисто концептуальное понятие и существует только в период разработки
Изображается как папка с закладкой, на которой обозначено его имя и, иногда, его содержание.
Поясняющие предметы:
Изображается в виде прямоугольника с загнутым углом, в который вписывается текстовый или графический комментарий.
Отношения UML
Зависимость. Изображается в виде пунктирной линии, возможно направленной на независимый предмет и иногда имеющей метку.
Агрегация – это специальная разновидность ассоциации, представляющая структурное отношение между целым и его частями
Изображается в виде сплошной линии, возможно направленной, иногда имеющей метку и часто включающей другие «украшения», такие как мощность и имена ролей.
Обобщение. Потомок разделяет структуру и поведение родителя
Изображается в виде сплошной стрелки с полым наконечником, указывающим на родителя.
Отношения реализации применяют в двух случаях: между интерфейсами и классами (или компонентами), реализующими их; между элементами Use Case и кооперациями, которые реализуют их
Изображается как нечто среднее между обобщением и зависимостью.
Диаграммы UML
диаграммы классов
диаграммы объектов
диаграммы Use Case (диаграммы прецедентов)
диаграммы последовательности
диаграммы сотрудничества (кооперации)
диаграммы схем состояний
диаграммы деятельности
компонентные диаграммы
диаграммы размещения (развертывания).
Взаимосвязи между диаграммами UML
Механизмы расширения UML
Ограничение показывают как текстовую строку, заключенную в фигурные скобки { }.
Теговую величину показывают как строку в фигурных скобках { }
Строка имеет вид:
имя теговой величины = значение
Элемент со стереотипом является вариацией существующего элемента, имеющей такую же форму, но отличающуюся по сути
У него могут быть дополнительные ограничения и теговые величины, а также другое визуальное представление
Отображают стереотип как имя, указываемое в двойных угловых скобках (или в угловых кавычках).
Архитектура программной системы – это набор внутренних структур ПС, которые видны с различных точек зрения и состоят из компонентов, их связей и возможных взаимодействий между компонентами, а также доступных извне свойств этих компонентов.
Компонент – это достаточно произвольный структурный элемент ПС, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает.
Архитектура ПС охватывает не только ее структурные и поведенческие аспекты, но и использование, функциональность, производительность, гибкость, возможности повторного применения, полноту, экономические и технологические ограничения и компромиссы, а также эстетические вопросы.
Представления (виды) архитектуры ПС:
Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестировщиками. Статические аспекты этого вида передаются диаграммами прецедентов, а динамические – диаграммами взаимодействия, состоянии и действий.
Вид с точки зрения проектирования (Design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Статические аспекты этого вида передаются диаграммами классов и объектов, а динамические – диаграммами взаимодействия, состояний и действий.
Вид с точки зрения реализации (Implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Статические аспекты этого вида передаются диаграммами компонентов, а динамические – с помощью диаграмм взаимодействия, состояний и действий.
Вид с точки зрения процессов (Process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Статические аспекты этого вида передают с помощью диаграмм компонентов, а динамические – с помощью диаграмм взаимодействия, состояний и действий.
Вид с точки зрения развертывания (Deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. Статические аспекты вида описываются диаграммами развертывания, а динамические – диаграммами взаимодействия, состояний и действий.
Унифицированный процесс разработки программных систем.
Ключевые идеи RUP:
Управление прецедентами использования. Весь ход работ направляется итоговыми целями проекта, выраженными в виде прецедентов использования (use cases) – сценариев взаимодействия результирующей ПС с пользователями или другими системами, при выполнении которых пользователи получают значимые для них результаты и услуги. Разработка начинается с выделения прецедентов использования и на каждом шаге контролируется степенью приближения к их реализации.
Прецеденты должны быть основным артефактом, на основании которого устанавливается желаемое поведение системы, проверяется и подтверждается правильность выбранной системной архитектуры, производится тестирование.
Основан на архитектуре. Основным решением, принимаемым в ходе проекта, является архитектура ПС. Она устанавливает набор компонентов, из которых будет построено ПС, ответственность каждого из компонентов, четко определяет интерфейсы, через которые они могут взаимодействовать, а также способы взаимодействия компонентов друг с другом.
Архитектура является одновременно основой для получения качественного ПС и базой для планирования работ и оценок проекта в терминах времени и ресурсов, необходимых для достижения определенных результатов. Она оформляется в виде набора графических моделей на языке UML.
Является итеративным и инкрементным.
Итеративным называется процесс, который предполагает управление потоком исполняемых версий системы.
Инкрементный процесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий, причем каждая следующая версия усовершенствована в сравнении с предыдущей.
Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками.
Фазы RUP:
Фаза начала проекта. Основная цель этой фазы – достичь компромисса между всеми заинтересованными лицами относительно задач проекта и выделяемых на него ресурсов. На этой стадии определяются основные цели проекта, руководитель и бюджет, основные средства выполнения – технологии, инструменты, ключевые исполнители. Также, возможно, происходит апробация выбранных технологий, чтобы убедиться в возможности достичь целей с их помощью, и составляются предварительные планы проекта. На эту фазу может уходить около 10% времени и 5% трудоемкости одного цикла.
Фаза проектирования. Основная цель этой фазы – на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы. На эту фазу может уходить около 30% времени и 20% трудоемкости одного цикла.
Фаза построения. Основная цель этой фазы – детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры. В результате должна получиться система, реализующая все выделенные варианты использования. На эту фазу уходит около 50% времени и 65% трудоемкости одного цикла.
Фаза внедрения. Цель этой фазы – сделать систему полностью доступной конечным пользователям. На этой стадии происходит развертывание системы в ее рабочей среде, бета-тестирование, подгонка мелких деталей под нужды пользователей. На эту фазу может уходить около 10% времени и 10% трудоемкости одного цикла.
Дисциплины RUP:
Моделирование предметной области (бизнес-моделирование). Задачи этой деятельности – понять предметную область или бизнес-контекст, в которых должна будет работать система, и убедиться, что все заинтересованные лица понимают его одинаково, осознать имеющиеся проблемы, оценить их возможные решения и их последствия для бизнеса организации, в которой будет работать система. В результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющих бизнес-операции и бизнес-процессы). Эта модель служит основой модели анализа. описывается структура и динамика организации
Определение требований. Задачи – понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок затрат ресурсов в нем. Требования принято фиксировать в виде модели вариантов использования. описывается основанный на прецедентах метод постановки требований
Анализ и проектирование. Задачи – выработать архитектуру системы на основе требований, убедиться, что данная архитектура может быть основой работающей системы в контексте ее будущего использования. В результате проектирования должна появиться модель проектирования, включающая диаграммы классов системы, диаграммы ее компонентов, диаграммы взаимодействий между объектами в ходе реализации вариантов использования, диаграммы состояний для отдельных объектов и диаграммы развертывания. описываются различные виды архитектуры системы
Реализация. Задачи – определить структуру исходного кода системы, разработать код ее компонентов и протестировать их, интегрировать систему в работающее целое. собственно разработка программ, автономное тестирование и интеграция
Тестирование. Задачи – найти и описать дефекты системы (проявления недостатков ее качества), оценить ее качество в целом, оценить выполнены или нет гипотезы, лежащие в основе проектирования, оценить степень соответствия системы требованиям. описываются тестовые сценарии, процедуры и метрики для измерения числа ошибок
Развертывание. Задачи – установить систему в ее рабочем окружении и оценить ее работоспособность на том месте, где она должна будет работать. охватывает конфигурирование поставляемой системы
Управление конфигурациями и изменениями. Задачи – определение элементов, подлежащих хранению в репозитории проекта и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений. управление изменениями и поддержание целостности артефактов проекта
Управление проектом. Задачи – планирование, управление персоналом, обеспечение взаимодействия на благо проекта между всеми заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта. описывает разные стратегии работы с итеративным процессом
Управление средой проекта. Задачи – подстройка процесса под конкретный проект, выбор и замена технологий и инструментов, используемых в проекте. рассматриваются вопросы инфраструктуры, необходимой для разработки системы
Модели RUP:
модель бизнес-процессов – формализует абстракцию организации;
модель предметной области – формализует контекст системы;
модель вариантов использования – формализует функциональные требования к системе;
модель анализа – формализует идею проекта;
модель проектирования – формализует словарь предметной области и области решения;
модель процессов (необязательная) – формализует механизмы параллелизма и синхронизации в системе;
модель развертывания – формализует топологию аппаратных средств, на которых выполняется система;
модель реализации – описывает части, из которых собирается физическая система;
модель тестирования – формализует способы проверки и приемки системы.
Технические артефакты:
группа требований – описывает, что система должна делать. В составе этих артефактов могут быть модели прецедентов, нефункциональных требований, предметной области и иные формы выражения потребностей пользователя, в том числе макеты, прототипы интерфейсов, юридические ограничения и т.д.
группа проектирования – описывает, как система должна быть построена с учетом ограничений по времени и бюджету, наличия унаследованных систем, повторного использования, требований к качеству и т.д. Сюда относятся проектная модель, модель тестирования и иные формы выражения потребностей пользователя, в том числе прототипы и исполняемые архитектуры.
группа реализации – описывает сборку разработанных программных компонентов. К группе реализации относится вся информация о программных элементах, из которых состоит система, в том числе исходный код на различных языках программирования, конфигурационные файлы, файлы данных, программные компоненты и т.д., а также информация о том, как собирать систему.
группа развертывания – содержит все данные, необходимые для конфигурирования предоставленной системы. Группа развертывания сообщает о том, как программный комплекс разбит на пакеты, в каком виде он поставляется, как устанавливается и запускается на площадке заказчика.
Управление риском
Влияние риска вычисляют по выражению: RE = P(UO) x L(UO), где:
RE – показатель риска (Risk Exposure – подверженность риску);
P (UO) – вероятность неудовлетворительного результата (Unsatisfactory Outcome);
L (UO – потеря при неудовлетворительном результате.
Управление риском включает шесть действий:
Идентификация риска – выявление элементов риска в проекте.
Анализ риска – оценка вероятности и величины потери по каждому элементу риска.
Ранжирование риска – упорядочение элементов риска по степени их влияния.
Планирование управления риском – подготовка к работе с каждым элементом риска.
Разрешение риска – устранение или разрешение элементов риска.
Наблюдение риска – отслеживание динамики элементов риска, выполнение корректирующих действий.
Принципы объектно-ориентированного представления программных систем.
Декомпозиция программных систем:
В основе алгоритмической декомпозиции лежит разбиение по действиям – алгоритмам. Эта схема представления применяется в обычных ПС.
Объектно-ориентированная декомпозиция обеспечивает разбиение по автономным лицам – объектам реального (или виртуального) мира. Эти лица (объекты) – более «крупные» элементы, каждый из них несет в себе и описания действий, и описания данных.
Абстрагирование:
Абстрагирование сводится к формированию абстракций.
Каждая абстракция фиксирует основные характеристики объекта, которые отличают его от других видов объектов и обеспечивают ясные понятийные границы.
Абстракция концентрирует внимание на внешнем представлении объекта, позволяет отделить основное в поведении объекта от его реализации.
Инкапсуляция:
Инкапсуляция и абстракция – взаимодополняющие понятия: абстракция выделяет внешнее поведение объекта, а инкапсуляция содержит и скрывает реализацию, которая обеспечивает это поведение.
Инкапсуляция достигается с помощью информационной закрытости. Обычно скрываются структура объектов и реализация их методов.
Инкапсуляция является процессом разделения элементов абстракции на секции с различной видимостью.
Инкапсуляция служит для отделения интерфейса абстракции от ее реализации. Модульность:
Модульность – это свойство системы, которая может подвергаться декомпозиции на ряд внутренне связанных и слабо зависящих друг от друга модулей.
Модуль – это фрагмент программного текста, являющийся строительным блоком для физической структуры системы.
Как правило, модуль состоит из интерфейсной части и части-реализации.
Общая цель декомпозиции на модули – уменьшение сроков разработки и стоимости ПС за счет выделения модулей, которые проектируются и изменяются независимо.
Каждая модульная структура должна быть достаточно простой, чтобы быть полностью понятой.
Изменение реализации модулей должно проводиться без знания реализации других модулей и без влияния на их поведение.
Свойства модулей:
Информационная закрытость утверждает (автор – Д. Парнас, 1972): содержание модулей должно быть скрыто друг от друга.
Модуль должен определяться и проектироваться так, чтобы его содержимое (процедуры и данные) было недоступно тем модулям, которые не нуждаются в такой информации (клиентам).
Информационная закрытость означает следующее:
все модули независимы, обмениваются только информацией, необходимой для работы;
доступ к операциям и структурам данных модуля ограничен.
Связность модуля – это мера зависимости его частей.
Связность – внутренняя характеристика модуля.
Чем выше связность модуля, тем лучше результат проектирования.
Измерение связности – сила связности (СС):
Связность по совпадению (СС=0)
Логическая связность (СС=1)
Временная связность (СС=3)
Процедурная связность (СС=5)
Коммуникативная связность (СС=7)
Информационная (последовательная) связность (СС=9)
Функциональная связность (СС=10)
Сцепление – это мера взаимозависимости модулей по данным.
Сцепление – это внешняя характеристика модуля, которую желательно уменьшать.
Сцепление по данным (СЦ=1)
Сцепление по образцу (СЦ=3)
Сцепление по управлению (СЦ=4)
Сцепление по внешним ссылкам (СЦ=5)
Сцепление по общей области (СЦ=7)
Сцепление по содержанию (СЦ=9)
Иерархическая организация:
Иерархическая организация – это формирование из абстракций иерархической структуры.
Иерархическая организация задает размещение абстракций на различных уровнях описания системы.
Двумя важными инструментами иерархической организации в объектно-ориентированных системах являются: