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