Проектирование программных средств Системный анализ 2 Системный анализ Проводится с целью: выяснения потребностей заказчика оценки реализуемости системы распределения функций по элементам системы (аппаратура, программы, базы данных, люди) определения стоимости и ограничений планирования 3 Системная спецификация Результаты системного анализа представляются в виде системной спецификации, в которой должны быть описаны: функции разрабатываемой системы, ее характеристики, ограничения разработки, состав входной и выходной информации. 4 Системная спецификация Системная спецификация служит исходным документом при проведении анализа требований 5 Анализ требований Имеет своей целью: определить функции и характеристики программного продукта обозначить его интерфейс с другими системными элементами определить проектные ограничения программного продукта построить модели режимов функционирования продукта выбрать формы представления информации в ходе проектирования 6 Спецификация требований Результаты анализа требований сводятся в спецификацию требований к программному продукту Спецификация требований служит исходным документом при проектировании программного средства 7 Проектирование Цель этапа проектирования: построение модели разрабатываемого программного продукта, удовлетворяющей спецификации требований В процессе проектирования разрабатывается логика решения проблем, выявленных на этапе системного анализа 8 Проект Результатом этапа проектирования является проект – набор документов, описывающих модель, а также ряд сопутствующих документов (детальные планы работ, экономические расчеты и т.д.) 9 Модель Для описания модели программного средства используются различные нотации: блок-схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы, макеты 10 Стадии проектирования Проектирование может выполняться как «вручную», так и с использованием различных средствами автоматизации Обычно выделяют три стадии проектирования: эскизное проектирование детальное проектирование интерфейсное проектирование 11 Эскизное проектирование Разрабатываемый программный продукт рассматривается как часть системы обработки информации, включающей аппаратную и программную составляющие набор взаимодействующих подсистем На этой стадии определяется архитектура системы 12 Понятие архитектуры ПС Под архитектурой ПС понимают набор ее внутренних структур, которые видны с различных точек зрения и состоят из компонентов, связей и возможных взаимодействий между компонентами, доступных извне свойств этих компонентов 13 Понятие компонента Под компонентом в этом определении понимается достаточно произвольный структурный элемент ПС, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает 14 Роль архитектуры Выбор архитектуры ПС задает способ реализации требований на высоком уровне абстракции Архитектура ПС почти полностью определяет его: надежность, переносимость, удобство сопровождения 15 Роль архитектуры Архитектура ПС значительно влияет на удобство использования (эргономичность), эффективность Эти характеристики, однако, сильно зависят и от реализации отдельных компонентов 16 Роль архитектуры Значительно меньшее влияние архитектура оказывает на функциональность – заданную функциональность можно реализовать, использовав совершенно различные архитектуры Выбор архитектурного решения основан на компромиссе между требованиями к различным характеристикам ПС Разбиение на компоненты Основные вопросы: число компонентов свойства компонентов Как провести разбиение на компоненты? Эффективность Для повышения эффективности выгоднее использовать небольшое число компонентов, в пределе – единственный компонент (монолитные архитектуры) Обеспечивается экономия как памяти, так и времени работы, т.к.имеется возможность оптимизировать работу алгоритмов в рамках одного компонента 19 Удобство сопровождения Для повышения удобства сопровождения, наоборот, лучше разбить систему на большое число относительно небольших компонентов Каждый из них будет решать свою четко определенную часть общей задачи 20 Надежность Для повышения надежности лучше использовать либо небольшой набор простых компонентов, либо дублирование функций, сделав несколько компонентов ответственными за решение одной подзадачи Желательно использовать достаточно сильно отличающиеся способы решения одной и той же задачи в разных компонентах 21 Эскизное проектирование Обеспечивает идентификацию подсистем определение характера взаимодействия подсистем и принципов управления ими Включает три типа деятельности структурирование системы моделирование управления декомпозиция подсистем на модули 22 Структурирование системы Система структурируется на несколько подсистем, являющихся относительно независимыми программными компонентами 23 Модели структурирования Наиболее часто используются 3 модели системного структурирования (архитектуры): модель хранилища данных модель клиент-сервер многоуровневая модель Модель хранилища данных Подсистемы разделяют данные, находящиеся в общей памяти и, как правило, представляющие собой базу данных Модель применима, если основные функции системы связаны с хранением, обработкой и представлением больших объемов данных 25 Модель клиент-сервер Решаемые задачи естественно распределяются между инициаторами и обработчиками запросов; возможно изменение внешнего представления данных и способов их обработки Используется для распределенных систем и в большинстве бизнес-приложений 26 Многоуровневая модель Имеется естественное расслоение задач системы на наборы подзадач, которые можно решать последовательно Компоненты разделяются на несколько уровней таким образом, что компоненты данного уровня могут использовать для своей работы только соседей или компоненты предыдущего уровня 27 Моделирование управления Различают два типа моделей управления модель централизованного управления модель событийного управления В модели централизованного управления выделяется компонент-контроллер, управляющий работой других подсистем В модели событийного управления системой управляют внешние события 28 Модульные компоненты Одним из основных способов разбиения системы на компоненты является модульная декомпозиция Программное средство представляется как набор программных модулей Программные модули модуль это любой функционально законченный фрагмент ПС, оформленный в виде отдельного файла с исходным кодом или поименованной непрерывной его части (например, класс в ООП), предназначенный для использования в других программах Программный 30 Программные модули Обычно модули проектируются таким образом, чтобы предоставлять программистам удобную для многократного использования функциональность (интерфейс) в виде набора функций, классов, констант Модули могут объединяться в пакеты и, далее, в библиотеки Модульная декомпозиция Модульная декомпозиция может осуществляться на основе: модели потока данных модели объектов В основе модели потока данных лежит разбиение по функциям Модель объектов основана на сущностях, имеющих собственные наборы данных, состояния и наборы операций 32 Эскизное проектирование Результаты эскизного проектирования представляются в виде эскизного проекта (Software Architecture Document) Стадия эскизного проектирования не является строго обязательной и может быть исключена, если основные проектные решения определены ранее или достаточно очевидны 33 Детальное проектирование На стадии детального проектирования конкретизируются решения архитектурного уровня и производится: разработка иерархии классов и структуры базы данных, построение алгоритмов для отдельных подзадач, поиск и подбор готовых компонентов для реализации некоторых функций системы 34 Проектирование интерфейса Целью интерфейсного проектирование является формирование интерфейса пользователя Пользовательский интерфейс объединяет в себе все элементы и компоненты программы, которые способны оказывать влияние на его взаимодействие с программным обеспечением 35 Элементы интерфейса К этим элементам относятся: набор задач пользователя, которые он решает при помощи системы; используемая системой метафора (например, Рабочий стол в MS Windows®); элементы управления системой; навигация между блоками системы; визуальный дизайн экранов программы; отображаемая информация и ее форматы; 36 Элементы интерфейса устройства и технологии ввода данных; диалоги, взаимодействие и транзакции между пользователем и компьютером; обратная связь с пользователем; поддержка принятия решений в конкретной предметной области; порядок использования программы и документация на нее. 37 Технический проект Результаты детального и интерфейсного проектирования представляются в техническом проекте (Software Design Document) Технический проект должен также содержать оценку экономической эффективности системы и перечень мероприятий по подготовке к ее внедрению 38 Процесс проектирования Требования Архитектура программ и данных Эскизное проектирование Структура данных и алгоритмы программ Детальное проектирование Интерфейсное проектирование Характеристики интерфейса 39 Архитектура ПО Архитектура программного обеспечения — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними. Структуры и точки зрения Любая система может рассматриваться с разных точек зрения – например, поведенческой (динамической), структурной (статической), логической (удовлетворение функциональным требованиям), физической (распределенность), реализации (как детали архитектуры представляются в коде) и т.п. В результате, мы получаем различные архитектурные представления (view). Архитектурные стили Архитектурный стиль, по своей сути, шаблон проектирования макроархитектуры - на уровне модулей, "крупноблочного" взгляда. Архитектурный стиль – набор ограничений, определяющих семейство архитектур, которые удовлетворяют этим ограничениям. Стили и модели Blackboard Клиент-серверная модель (client-server) Архитектуры, построенные вокруг базы данных (database-centric architecture) Распределенные вычисления (distributed computing) Событийная архитектура (event-driven architecture) Front end and back end Неявные вызовы (implicit invocations) Монолитное приложение (monolithic application) Peer-to-peer Пайпы и фильтры (pipes and filters) Plugin Representational State Transfer Rule evaluation Поиск-ориентированная архитектуры Сервис-ориентированная архитектура Shared nothing architecture Software componentry Space based architecture Структурированная Трех-уровневая Шаблоны проектирования Шаблоны проектирования (паттерн, англ. design pattern) — это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста 44 Шаблоны проектирования Паттерн не является законченным образцом проекта, который может быть прямо преобразован в код Это описание или образец для того, как решить задачу, таким образом, чтобы это можно было использовать в различных ситуациях 45 История В 70-х годах двадцатого века архитектор Кристофер Александер (Christopher Alexander) составил набор шаблонов проектирования Эта идея получила свое развитие в области программной инженерии, когда в 1987 году Кент Бэк и Вард Каннигем разработали шаблоны применительно к задаче создания графических оболочек 46 Преимущества шаблонов Шаблоны описывают решения целых классов абстрактных проблем; позволяют унифицировать терминологию, названия модулей и элементов проекта; позволяют повторно использовать удачное решение; независимы от применяемого языка программирования 47 Критика шаблонов Слепое применение шаблонов, без осмысления причин и предпосылок выделения каждого отдельного шаблона, замедляет профессиональный рост программиста Поэтому знакомиться со списками шаблонов надо только после достижения определенного уровня профессионализма 48 Шаблоны анализа Шаблоны анализа (analysis patterns) – представляют собой типовые решения при моделировании сложных взаимоотношений между понятиями некоторой предметной области Делятся на шаблоны функционального и объектно-ориентированного анализа Используются на этапе анализа (предметной области, системного, требований) 49 Архитектурные шаблоны Архитектурные шаблоны (architectural styles, architectural patterns) представляют собой типовые способы организации системы в целом или крупных подсистем; задают некоторые правила выделения компонентов и реализации взаимодействий между ними Используются на стадии эскизного проектирования 50 Архитектурные шаблоны Конвейер обработки данных (data flow). Пакетная обработка (batch sequential) Каналы и фильтры (pipe-and-filter) – утилиты UNIX Архитектурные шаблоны Вызов-возврат (call-return) Процедурная декомпозиция – основная схема построения программ для языков C, Pascal, Ada Абстрактные типы данных (abstract data types) – библиотеки классов и компонентов Многоуровневая система (layers) – протоколы сетей передачи данных Клиент-сервер – основная модель бизнесприложений Архитектурные шаблоны Интерактивные системы Данные–представление–обработка (modelview-controller, MVC) Представление–абстракция–управление (presentation-abstraction-control) – интерактивная система на основе агентов, имеющих собственные состояния и пользовательский интерфейс Архитектурные шаблоны Системы на основе хранилища данных Репозиторий (repository) – выделяется общее хранилище данных - репозиторий Классная доска (blackboard) – системы распознавания текста Шаблоны проектирования Шаблоны проектирования (design patterns) определяют типовые проектные решения для часто встречающихся задач среднего уровня, касающиеся структуры одной подсистемы или организации взаимодействия двух-трех компонентов Применяются на стадии детального проектирования 55 Идиомы Идиомы (idioms, programming patterns) являются специфическими для некоторого языка программирования способами организации элементов программного кода, позволяющими решить некоторую часто встречающуюся задачу Используются на этапе реализации (кодирования) 56 Образцы организации и процессов Образцы организации (organizational patterns) и образцы процессов (process patterns) описывают успешные практики организации разработки ПО или другой сложной деятельности Позволяют решать определенные задачи в рамках некоторого контекста, включающего ограничения на возможные решения 57 Вывод Шаблоны могут применяться на всех стадиях разработки программных систем, способствуя существенному сокращению этих сроков Описание шаблонов При описании шаблона выделяют четыре его составляющих: имя, задача, решение, результаты Имя шаблона Позволяет сразу обозначить проблему, пути ее решения и последствия Присваивание шаблонам имен позволяет проектировать на более высоком уровне абстракции С помощью словаря шаблонов можно вести обсуждение с коллегами, упоминать шаблоны в документации, представлять тонкости системы Задача Описание того, когда следует применять шаблон Формулируется задача и ее контекст (например, представить алгоритм в виде объектов) Иногда в описание задачи входит перечень условий, при выполнении которых имеет смысл применять шаблон Решение Описание элементов решения, отношений между ними, функций каждого элемента При этом решение – не конкретный дизайн или реализация, а абстрактное описание задачи и того, как она может быть решена с помощью некоего весьма общего сочетания элементов Результаты Результаты - это следствия применения шаблона и разного рода компромиссы Иногда в результатах может быть описан выбор языка и реализации В случае проектирования к результатам относят влияние на степень гибкости, расширяемости и переносимости системы Примеры шаблонов и их описаний Шаблон функциональной модели анализа Строится на основе следующей классификации функций: Основные функции, непосредственно связанные с типом предприятия (производственное, торговое, сервисное и т.п.) Общие функции, не связанные непосредственно с типом предприятия Специфические функции, определяемые спецификой применяемых на конкретном предприятии технологий и процедур 65 Основные функции Для предприятия производственного типа выделено пять основных функций: планирование производства, подготовка производства, обеспечение производства , выпуск продукции, сбыт продукции 66 Основные функции Для предприятий и организаций непроизводственных типов (торговые компании, банки, институты и пр.) можно выделить свой перечень характерных для них основных функций 67 Общие функции В качестве общих можно назвать следующие функции: руководство предприятием, финансовая деятельность, функции поддержки (работа с кадрами, информационное и техническое обеспечение, охрана и т.д.), взаимодействие с дочерними предприятиями, филиалами, представительствами 68 Описание шаблона Модель <номер; имя модели, выражающее цель моделирования в виде короткой фразы> Характерная информация Категория предприятия: < промышленное предприятие, торговая компания, банк, государственное учреждение и т.д. > Цель: <детальное выражение цели моделирования> 69 Описание шаблона Точка зрения: <точка зрения, принятая при моделировании> Область (контекст): <какая система рассматривается в качестве черного ящика (в соответствии с целью)> Уровень модели: <общая модель, подмодель> 70 Описание шаблона Структура предприятия Руководство: < ФИО, должность > Подразделение: < № подразделения. Наименование подразделения, ФИО руководителя > Перечень основных функций для предприятия Функция: < Функция №. Наименование функции, описание функции > 71 Описание шаблона Описание специфических для предприятия подфункций, раскрывающих технологии выполнения каждой из основных функций: Функция: < Функция №№. Наименование функции, описание функции > Описание общих, не зависящих от категории предприятия, функций: Функция: < Функция №. Наименование функции, описание функции > 72 Описание шаблона Документация Перечень документов, используемых в модели: Документ: < Условный № документа. Точное название документа > < Условный № документа>: < Код ответственного подразделения + Порядковый номер > 73 Архитектурный шаблон Рассмотрим сравнительный анализ двух архитектур на примере индексатора — программы для построения индекса некоторого текста, т.е. упорядоченного по алфавиту списка его слов без повторений Сценарии работы Выделим следующие сценарии работы программы: a) b) Надо сделать так, чтобы индексатор мог работать в инкрементальном режиме, читая на входе одну фразу за другой и пополняя получаемый в процессе работы индекс Надо сделать так, чтобы индексатор мог игнорировать предлоги, союзы, местоимения, междометия, частицы и другие служебные слова Сценарии работы c) d) Надо сделать так, чтобы индексатор мог обрабатывать тексты, подаваемые ему на вход в виде архивов Надо сделать так, чтобы в индексе оставались только слова в основной грамматической форме — существительные в единственном числе и именительном падеже, глаголы в неопределенной форме и пр. Варианты архитектуры Определим две возможных архитектуры индексатора для сравнительного анализа: архитектуру конвейерного типа («каналыфильтры»), архитектуру типа хранилища данных (репозиторий) Компоненты Индексатор разбивается на два компонента: один компонент принимает на свой вход входной текст, полностью прочитывает его и выдает на выходе список слов, из которых он состоит второй компонент принимает на вход список слов, а на выходе выдает его упорядоченный вариант без повторений Архитектура «каналы-фильтры» Архитектура «репозиторий» Имеется упорядоченный список без повторений всех слов, прочитанных до настоящего момента Имеются две переменные: строка, хранящая последнее (быть может, не до конца) прочитанное слово ссылка на то слово в подготовленном списке, которое лексикографически следует за последним словом Компоненты Имеются четыре компонента: Первый читает очередной символ на входе и передает его на обработку второму компоненту, если это символразделитель слов (пробел, табуляция, перевод строки), третьему компоненту, если этот символ буква четвертому компоненту, если входной текст завершается Компоненты Второй компонент закачивает ввод последнего слова и оно помещается в список перед тем местом, на которое указывает ссылка; после чего последнее слово становится пустым, а ссылка начинает указывать на первое слово в списке Третий компонент добавляет прочитанную букву в конец последнего слова, после чего, быть может, перемещает ссылку на слово следующее в списке за полученным Архитектура «репозиторий» Четвертый компонент выдает полученный индекс на выход. Сценарий a) Этот сценарий прямо поддерживается второй архитектурой. Чтобы поддержать его в первой, необходимо внести изменения в оба компонента: первый компонент должен пополнять промежуточный список, читая входной текст фраза за фразой Сценарий a) второй компонент должен аналогичным способом пополнять результирующий упорядоченный список, вставляя туда поступающие ему на вход слова. Сценарий b) Обе архитектуры не поддерживают этот сценарий В первой архитектуре необходимо изменить первый компонент или, лучше, вставить после него дополнительный фильтр, отбрасывающий вспомогательные части речи Сценарий b) Во второй архитектурой нужно ввести дополнительный компонент, который перехватывает буквы, выдаваемые модулем их обработки и сигналы о конце слова от первого компонента, после чего он должен отсеивать служебные слова Сценарий c) Этот сценарий также требует изменений в обеих архитектурах В обоих случаях эти изменения одинаковы — достаточно добавить дополнительный компонент, декодирующий архивы, если они подаются на вход Сценарий d) Этот сценарий также не поддерживается обеими архитектурами Требуемые им изменения аналогичны требованиям второго сценария, только в этом случае дополнительный компонентфильтр должен еще и преобразовывать слова в их основную форму и только после этого пытаться добавить результат к итоговому индексу Сравнение двух архитектур + обозначает возможность не изменять компонент, - — необходимость изменения компонента, * — необходимость добавления одного компонента Сравнение двух архитектур В целом первая (конвейерная) архитектура на предложенных сценариях выглядит лучше второй Единственный ее недостаток — отсутствие возможности инкрементально поставлять данные на вход компонентам Сравнение двух архитектур Если его устранить, сделав компоненты способными потреблять данные постепенно, эта архитектура станет почти идеальным вариантом, поскольку она легко расширяется — для решения многих дополнительных задач потребуется только добавлять компоненты в общий конвейер. Сравнение двух архитектур Вторая архитектура, несмотря на выигрыш в инкрементальности, проигрывает в целом Основная ее проблема — слишком специфически построенный компонентобработчик букв Сравнение двух архитектур Необходимость изменить его в нескольких сценариях показывает, что нужно объединить обработчик букв и обработчик конца слов в единый компонент, выдающий слова целиком, после чего полученная архитектура не будет ничем уступать исправленной первой Шаблоны проектирования Factory - шаблон, позволяющий изменять поведение системы, варьируя создаваемые объекты, при этом сохраняя интерфейсы Adapter - шаблон, позволяющий преобразовать интерфейс объекта к тому, который требует клиент. Abstract 95 Шаблоны проектирования - шаблон, позволяющий абстрагировать процесс создания комплексных систем, путем выделения и обобщения классов, отвечающих за создание частей Bridge - шаблон, позволяющий отделить интерфейс от реализации и изменять их независимо Builder 96 Шаблоны проектирования - шаблон, инкапсулирующий запрос как объект, позволяя более гибко работать с запросами (параметризовать, архивировать, наделять поведением) Decorator - шаблон, позволяющий динамически добавлять обязанности объекту, путем включения его в "конверт", обладающий совместимым интерфейсом Command 97 Шаблоны проектирования - паттерн, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы Другие примеры шаблонов приведены в документе «Каталог шаблонов» А также на ресурсе dotSite по адресу http://www.dotsite.ru/solutions/patterns/ Facade 98 Конец лекции 99
