Слайды и текст доклада
Pic.1
Проектирование программных средств Лекция 3
Pic.3
Спецификация требований Итогом системного анализа является выработка требований к программному продукту Спецификация требований служит исходным документом при проектировании программного средства
Pic.4
Проектирование Целью этапа проектирования является построение модели разрабатываемого программного продукта, удовлетворяющей спецификации требований В процессе проектирования разрабатывается логика …
Pic.5
Проектирование Результатом этапа проектирования является проект – набор документов, описывающих модель программного средства, а также ряд сопутствующих документов (детальные планы работ, …
Pic.6
Проектирование Для представления модели программного средства используются различные нотации: блок-схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы, макеты
Pic.7
Стадии проектирования В зависимости от класса создаваемого ПО, проектирование может выполняться как «вручную», так и с использованием различных средствами автоматизации Обычно выделяют три стадии …
Pic.8
ЭСКИЗНОЕ ПРОЕКТИРОВАНИЕ Имеет своей целью структурирование разрабатываемого ПС, выделение отдельных относительно независимых подсистем, связанных с решением отдельных подзадач. Завершается созданием …
Pic.9
Эскизное проектирование Разрабатываемый программный продукт рассматривается как часть системы обработки информации, включающей аппаратную и программную составляющие набор взаимодействующих подсистем …
Pic.10
Понятие архитектуры ПС Под архитектурой ПС понимают набор ее внутренних структур, которые видны с различных точек зрения и состоят из архитектурных компонентов, связей и возможных взаимодействий …
Pic.11
Понятие компонента Под архитектурным компонентом в этом определении понимается достаточно произвольно выделенный структурный элемент ПС, который решает некоторые подзадачи в рамках общих задач …
Pic.12
Роль архитектуры Выбор архитектуры ПС задает способ реализации требований на высоком уровне абстракции Архитектура ПС почти полностью определяет ее: надежность, переносимость, удобство сопровождения
Pic.13
Роль архитектуры Архитектура значительно влияет на эргономику и эффективность ПО, которые, однако, сильно зависят и от реализации отдельных компонентов Значительно меньше влияние архитектуры на …
Pic.14
Примеры архитектур Клиент-серверная архитектура (Client-server) Архитектура распределенных вычислений (Distributed Computing) Одноранговая архитектура (Peer-to-peer) Архитектура каналов и фильтров …
Pic.15
Клиент-серверная архитектура Архитектура приложения, в котором задания распределены между поставщиками услуг (серверами) заказчиками услуг (клиентами) Клиенты и серверы могут взаимодействовать через …
Pic.16
Клиент-серверная архитектура
Pic.17
Многоуровневая архитектура Разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов Обеспечивается естественное расслоение задач …
Pic.18
Трехуровневая архитектура
Pic.19
Многоуровневая архитектура
Pic.20
Сервис-ориентированная архитектура Такой подход к разработке приложений для управления предприятием, которой предусматривает разложение программных процессов на отдельные услуги, с которыми далее …
Pic.21
Сервис-ориентированная архитектура SOA "подталкивает" к использованию для построения приложений подхода основанного на связывании уже существующих сервисов, а не на написании нового …
Pic.23
Компонентная архитектура Разрабатываемое приложение строится из набора готовых компонентов развертывания со строго определенным интерфейсом В данном случае под компонентом развертывания …
Pic.24
Компонентная архитектура Наиболее распространенными платформами для построения компонентной архитектуры являются: Microsoft СОМ, Sun Enterprise Java Beans, CORBA, Microsoft . Net
Pic.25
Архитектура хранилища данных Подсистемы разделяют данные, находящиеся в общей памяти и, как правило, представляющие собой базу данных Применима, если основные функции системы связаны с хранением, …
Pic.26
Проблемы выбора Выбор между той или иной архитектурой определяется в основном нефункциональными требованиями и необходимыми свойствами ПО с точки зрения удобства сопровождения и переносимости Для …
Pic.27
Эффективность Так, для повышения эффективности в общем случае выгоднее использовать монолитные архитектуры, в которых выделено небольшое число архитектурных компонентов (в пределе — единственный …
Pic.28
Удобство сопровождения С другой стороны, для повышения удобства сопровождения, наоборот, лучше разбить систему на большое число отдельных небольших архитектурных компонентов, с тем чтобы каждый из …
Pic.29
Надежность С третьей стороны, для повышения надежности лучше использовать либо небольшой набор простых архитектурных компонентов, либо дублирование функций, сделав несколько компонентов …
Pic.30
Эскизный проект Результаты эскизного проектирования представляются в виде эскизного проекта – описания ее архитектурных составляющих и способов взаимодействия между ними Стадия эскизного …
Pic.31
ДЕТАЛЬНОЕ ПРОЕКТИРОВАНИЕ Целью детального проектирования является полная спецификация архитектурных составляющих программного средства. Выполняется параллельно с проектированием пользовательского …
Pic.32
Детальное проектирование На стадии детального проектирования конкретизируются решения архитектурного уровня и производится: разработка иерархии классов и структуры базы данных, детализация структуры …
Pic.33
Программные модули Программный модуль это любой фрагмент ПС, который программируется, компилируется и отлаживается отдельно от других частей программы, и тем самым, физически разделен с ними …
Pic.34
Взаимодействие модулей Объединение многих модулей в единую систему достигается через интерфейсы модулей Интерфейс модуля – это описание тех средств (структур данных и структур управления), которые …
Pic.35
Принцип инкапсуляции Таким образом, модуль делится на две части: внешнюю – интерфейс, внутреннюю – реализацию Интерфейс модуля – это его представление как "чёрного ящика" с известными …
Pic.36
Скрытие информации Модуль, подобен айсбергу; лишь его верхушка - интерфейс - видна клиентам
Pic.37
Характеристики модуля Для оценки качества программного модуля обычно используют следующие его характеристики: размер модуля, связность (прочность) модуля, сцепление с другими модулями, рутинность …
Pic.38
Размер модуля Размер модуля измеряется числом содержащихся в нем операторов или строк Модуль не должен быть слишком маленьким или слишком большим Обычно рекомендуются программные модули размером …
Pic.39
Прочность модуля Прочность (cohesion) модуля это мера его внутренних связей Чем выше прочность модуля, тем больший вклад в упрощение программы он может внести По степени прочности модули делятся …
Pic.40
Прочность по совпадению Прочным по совпадению называется такой модуль, между элементами которого нет осмысленных связей (повторяющийся фрагмент кода) Подобный класс программных модулей не …
Pic.41
Функциональная прочность Функционально прочный модуль это модуль, выполняющий (реализующий) одну какую-либо определенную функцию При реализации этой функции такой модуль может использовать и другие …
Pic.42
Информационная прочность Информационно прочный модуль это модуль, реализующий несколько операций над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне …
Pic.43
Сцепление модуля Сцепление (coupling) модуля это мера его зависимости по данным от других модулей Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем …
Pic.44
Виды сцепления модулей Сцепление по содержимому. Таким является сцепление двух модулей, когда один из них имеет прямые ссылки на содержимое другого модуля (например, на константу, содержащуюся в …
Pic.45
Виды сцепления модулей Сцепление по общей области это такое сцепление модулей, когда несколько модулей используют одну и ту же область памяти Не рекомендуется использовать
Pic.46
Виды сцепления Параметрическое сцепление это случай, когда данные передаются модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю для …
Pic.47
Рутинность модуля Рутинность модуля это его независимость от предыстории обращений к нему Модуль будем называть рутинным, если результат обращения к нему зависит только от значений его параметров и …
Pic.48
Модульность В результате модульной декомпозиции разрабатываемое программное средство должно быть представлено в виде системы, разбитой на множество модулей с и низкой степенью зацепления и сильной …
Pic.49
Спецификация модуля Модульная структура программы должна включать и совокупность спецификаций модулей, образующих эту программу Спецификация программного модуля содержит синтаксическую спецификацию …
Pic.50
ПРОЕКТИРОВАНИЕ ИНТЕРФЕЙСА Имеет целью разработку пользовательского интерфейса, обеспечивающего эргономичность разрабатываемого программного средства. Выполняется совместно с детальным …
Pic.51
Пользовательский интерфейс Пользовательский интерфейс представляет собой совокупность программных и аппаратных средств, обеспечивающих взаимодействие пользователя с компьютером Основу такого …
Pic.52
Диалоги Каждый диалог состоит из отдельных процессов ввода-вывода, которые физически обеспечивают связь пользователя и компьютера Обмен информацией осуществляется передачей сообщений и управляющих …
Pic.54
Элементы интерфейса Пользовательский интерфейс объединяет в себе все элементы и компоненты программы, которые способны оказывать влияние на его взаимодействие с программным обеспечением К этим …
Pic.55
Элементы интерфейса навигация между блоками системы; визуальный дизайн экранов программы; отображаемая информация и ее форматы; устройства и технологии ввода данных; поддержка принятия решений в …
Pic.56
Технический проект Результаты детального и интерфейсного проектирования представляются в техническом проекте (Software Design Document) Технический проект должен также содержать оценку экономической …
Pic.57
Процесс проектирования
Pic.58
ШАБЛОНЫ ПРОЕКТИРОВАНИЯ
Pic.59
Шаблоны проектирования Шаблоны проектирования (паттерн, англ. design pattern) — это многократно применяемая конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного …
Pic.60
Преимущества шаблонов Каждый отдельный шаблон описывает решение целого класса абстрактных проблем Шаблоны позволяют унифицировать терминологию, названия модулей и элементов проекта. Шаблон …
Pic.61
Критика шаблонов Слепое применение шаблонов, без осмысления причин и предпосылок выделения каждого отдельного шаблона, замедляет профессиональный рост программиста Знакомиться со списками шаблонов …
Pic.62
Классификация шаблонов Шаблоны анализа (analysis patterns) –представляют собой типовые решения при моделировании сложных взаимоотношений между понятиями некоторой предметной области Делятся на …
Pic.63
Классификация шаблонов Архитектурные шаблоны (architectural styles, architectural patterns) Такие образцы представляют собой типовые способы организации системы в целом или крупных подсистем; задают …
Pic.64
Архитектурные шаблоны Конвейер обработки данных (data flow). Пакетная обработка (batch sequential) Каналы и фильтры (pipe-and-filter) – утилиты UNIX Вызов-возврат (call-return) Процедурная …
Pic.65
Архитектурные шаблоны Интерактивные системы Данные–представление–обработка (model-view-controller, MVC) Представление–абстракция–управление (presentation-abstraction-control) – интерактивная система …
Pic.66
Классификация шаблонов Шаблоны проектирования (design patterns) Определяют типовые проектные решения для часто встречающихся задач среднего уровня, касающиеся структуры одной подсистемы или …
Pic.67
Классификация шаблонов Идиомы (idioms, programming patterns) Идиомы являются специфическими для некоторого языка программирования способами организации элементов программного кода, позволяющими …
Pic.68
Классификация шаблонов Образцы организации (organizational patterns) и образцы процессов (process patterns) Образцы этого типа описывают успешные практики организации разработки ПО или другой сложной …
Pic.69
Описание шаблонов Таким образом, шаблоны, понимаемые как образцы решения неких типовых задач могут применяться на всех стадиях разработки программных систем, способствуя сокращению этих сроков При …
Pic.70
Имя шаблона Сославшись на имя, можно сразу описать проблему, ее решения и последствия Присваивание шаблонам имен позволяет проектировать на более высоком уровне абстракции С помощью словаря шаблонов …
Pic.71
Задача Описание того, когда следует применять шаблон Формулируется задача и ее контекст (например, представить алгоритм в виде объектов) Иногда в описание задачи входит перечень условий, при …
Pic.72
Решение Описание элементов решения, отношений между ними, функций каждого элемента При этом решение – не конкретный дизайн или реализация, а абстрактное описание задачи и того, как она может быть …
Pic.73
Результаты Результаты - это следствия применения шаблона и разного рода компромиссы Иногда в результатах может быть описан выбор языка и реализации В случае проектирования к результатам относят …
Pic.74
Пример архитектурного шаблона Рассмотрим сравнительный анализ двух архитектур на примере индексатора — программы для построения индекса некоторого текста, т. е. упорядоченного по алфавиту списка его …
Pic.75
Сценарии работы Выделим следующие сценарии работы или модификации программы: Надо сделать так, чтобы индексатор мог работать в инкрементальном режиме, читая на входе одну фразу за другой и пополняя …
Pic.76
Архитектура «каналы-фильтры» Определим две возможных архитектуры индексатора для сравнительного анализа В качестве первой архитектуры рассмотрим разбиение индексатора на два компонента: Один …
Pic.77
Архитектура «каналы-фильтры»
Pic.78
Архитектура «репозиторий» Другой вариант архитектуры индексатора устроен следующим образом Имеется упорядоченный список без повторений всех слов, прочитанных до настоящего момента Имеются две …
Pic.79
Архитектура «репозиторий» В дополнение к этим данным имеются следующие компоненты: Первый читает очередной символ на входе и передает его на обработку одному из остальных. Если это разделитель слов …
Pic.80
Архитектура «репозиторий» Третий компонент добавляет прочитанную букву в конец последнего слова, после чего, быть может, перемещает ссылку на следующее за полученным слово в списке Четвертый …
Pic.81
Сценарий a Этот сценарий прямо поддерживается второй архитектурой. Чтобы поддержать его в первой архитектуре, необходимо внести изменения в оба компонента так, чтобы первый компонент мог бы пополнять …
Pic.82
Сценарий b Обе архитектуры не поддерживают этот сценарий В первой архитектуре необходимо изменить первый компонент или, лучше, вставить после него дополнительный фильтр, отбрасывающий вспомогательные …
Pic.83
Сценарий c Этот сценарий также требует изменений в обеих архитектурах В обоих случаях эти изменения одинаковы — достаточно добавить дополнительный компонент, декодирующий архивы, если они подаются на …
Pic.84
Сценарий d Этот сценарий также не поддерживается обеими архитектурами Требуемые им изменения аналогичны требованиям второго сценария, только в этом случае дополнительный компонент-фильтр должен еще и …
Pic.85
Сравнение двух архитектур + обозначает возможность не изменять компонент, - — необходимость изменения компонента, * — необходимость добавления одного компонента
Pic.86
Сравнение двух архитектур В целом первая архитектура на предложенных сценариях выглядит лучше второй. Единственный ее недостаток — отсутствие возможности инкрементально поставлять данные на вход …
Pic.87
Сравнение двух архитектур Вторая архитектура, несмотря на выигрыш в инкрементальности, проигрывает в целом Основная ее проблема — слишком специфически построенный компонент-обработчик букв …
Pic.88
Примеры шаблонов Abstract Factory - паттерн, позволяющий изменять поведение системы, варьируя создаваемые объекты, при этом сохраняя интерфейсы Adapter - паттерн, позволяющий преобразовать интерфейс …
Pic.89
Примеры шаблонов Builder - паттерн, позволяющий абстрагировать процесс создания комплексных систем, путем выделения и обобщения классов, отвечающих за создание частей Bridge - паттерн, позволяющий …
Pic.90
Примеры шаблонов Command - паттерн, инкапсулирующий запрос как объект, позволяя более гибко работать с запросами (параметризовать, архивировать, наделять поведением) Decorator - паттерн, позволяющий …
Pic.91
Примеры шаблонов Facade - паттерн, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы Другие …
Pic.92
Отношения между шаблонами проектирования
Скачать презентацию
Если вам понравился сайт и размещенные на нем материалы, пожалуйста, не забывайте поделиться этой страничкой в социальных сетях и с друзьями! Спасибо!