3.14M

Category:

software

Введение в программную инженерию. ЖЦПО. Лекция 4

1.

Введение в программную
инженерию
Лекция 4
ЖЦПО.
Стандарт 12207.
Классические модели ЖЦПО.

2.

Жизненный цикл (life cycle)
Развитие системы, продукта, услуги,
проекта или других изготовленных
человеком объектов, начиная со
стадии разработки концепции и
заканчивая прекращением
применения

Модель жизненного цикла
ПО (life cycle model)
Структура процессов и действий,
связанных с жизненным циклом,
организуемых в стадии, которые
также служат в качестве общей
ссылки для установления связей и
взаимопонимания сторон.

4.

Модель жизненного цикла
программного обеспечения
структура, определяющая
последовательность выполнения и
взаимосвязи процессов, действий и задач
на протяжении всего жизненного цикла
программного обеспечения
зависит от специфики, масштаба и
сложности проекта и специфики условий, в
которых система создается и
функционирует

5.

Модель ЖЦ конкретного ПО
определяет характер процесса его
создания, который представляет собой
совокупность упорядоченных во времени,
взаимосвязанных и объединенных в
стадии работ, выполнение которых
необходимо и достаточно для создания
ПО, соответствующего заданным
требованиям.

6.

Типовые стадии ЖЦ ПО
Анализ (формирование требований)
Планирование
Проектирование
Разработка (Кодирование)
Тестирование
Документирование
Эксплуатация:
Ввод в эксплуатацию
Эксплуатация и сопровождение
Снятие с эксплуатации

7.

Стадия формирования
требований к ПО (анализ)
планирование работ
проведение обследования деятельности
автоматизируемого объекта (организации)
построение моделей деятельности
организации:
модели "AS-IS" («как есть») - позволяют
выявлять узкие места в существующих
технологиях
модели "ТО-ВЕ" («как должно быть»)

8.

Стадия проектирования (1)
Разработка системного проекта: Что должна делать система?
Строятся на основе модели "ТО-ВЕ"
Определяются:
архитектура системы,
ее функции,
внешние условия функционирования,
интерфейсы и распределение функций между
пользователями и системой,
требования к программным и информационным
компонентам,
состав исполнителей и сроки разработки
Документальным результатом является техническое
задание

9.

Стадия проектирования (2)
Разработка технического проекта: Как построить
систему, чтобы она удовлетворяла
предъявленным к ней требованиям?
На основе системного проекта осуществляется
собственно проектирование системы,
включающее проектирование архитектуры
системы и детальное проектирование
Модели проектируемой системы при этом
уточняются и детализируются до необходимого
уровня

10.

Модель
«Делай, пока не будет сделано»
Вход
Кодирование и
тестирование
Выход
Делай, пока не
будет сделано
была широко распространена до 1970 гг
была заменена на каскадную модель
Обычно используют студенты

11.

Стратегии конструирования
программного обеспечения
однократный проход (водопадная стратегия)
– линейная последовательность этапов
конструирования;
инкрементная стратегия – начале процесса
определяются все пользовательские и системные
требования, оставшаяся часть конструирования
выполняется в виде последовательности версий;
эволюционная стратегия – система также
строится в виде последовательности версий, но в
начале процесса определены не все требования.

12.

Характеристики стратегий
конструирования ПО

13.

Каскадная модель
(водопад) (1)
старейшая парадигма процесса разработки ПО
автор Уинстон Ройс
разработана в 1970 г.
разработка рассматривается как
последовательность этапов
переход на следующий, иерархически нижний
этап происходит только после полного
завершения работ на текущем этапе
возвратов на пройденные стадии не
предусматривается

14.

Каскадная модель
(водопад) (2)
Системный анализ
Анализ требований
Проектирование
Кодирование
Тестирование
Эксплуатация и
сопровождение

15.

Каскадная модель
(водопад) (2)
каждая стадия заканчивается получением некоторых
результатов, которые служат в качестве исходных
данных для следующей стадии
каждая стадия завершается выпуском полного
комплекта документации, достаточной для того,
чтобы разработка могла быть продолжена другой
командой разработчиков
критерием качества разработки является точность
выполнения спецификаций технического задания
основное внимание разработчиков
сосредоточивается на достижении оптимальных
значений технических характеристик разрабатываемого ПО: производительности, объема памяти и др.

16.

Каскадная модель
(водопад) (4)

17.

Достоинства классического
жизненного цикла
На каждой стадии формируется законченный
набор проектной документации, отвечающий
критериям полноты и согласованности
Выполняемые в логичной последовательности
стадии работ позволяют планировать сроки
завершения всех работ и соответствующие
затраты
Простота и понятность
Удобство в применении (поэтапный процесс
разработки)
Обеспечивает строгий контроль
Позволяет контролировать качество

18.

Каскадная модель
(водопад) (5)

19.

Недостатки классического
жизненного цикла
Реальные проекты часто требуют отклонения
от стандартной последовательности шагов
Цикл основан на точной формулировке
исходных требований к ПО (реально в начале
проекта требования заказчика определены
лишь частично)
Результаты проекта доступны заказчику только
в конце работы
Сложность возврата к предшествующим фазам
Неприменима в случае изменяющихся
требований
Очень высокие затраты на документирование

20.

Модель с промежуточным
контролем (1)
Системный анализ
Анализ требований
Проектирование
Кодирование
Тестирование
Эксплуатация и
сопровождение

21.

Модель с промежуточным
контролем (2)
Требования фиксируются в виде технического задания
на все время создания ПО.
Согласование получаемых результатов с пользователями
производится только в точках, планируемых после
завершения каждой стадии (возможна корректировка
результатов, если они не затрагивают требования,
изложенные в техническом задании).
Пользователи могут внести существенные замечания
только после того, как работа над системой будет
полностью завершена.
В случае неточного изложения требований или их
изменения в течение длительного периода создания ПО
пользователи получают систему, не удовлетворяющую
их потребностям.

22.

23.

Достоинства и недостатки
Минусы:
Сложно планировать возвраты.
Высокие риски срыва сроков и перерасхода
бюджета.
Плюсы:
Возможен возврат назад.
Учет изменения во внешнем мире (в ТЗ).
Повышается удовлетворенность заказчика.

24.

Инкрементная модель

25.

Инкрементная модель (1)
является классическим примером
инкрементной стратегии конструирования
объединяет элементы последовательной
водопадной модели с итерационной
философией макетирования
каждая линейная последовательность
вырабатывает поставляемый инкремент
программного обеспечения

26.

Инкрементная модель (2)
Оценка
осуществимости
проекта
Инкремент 1
Инкремент 2
Анализ
требований
Анализ
требований
Разработка
Разработка
Внедрение
Внедрение

27.

Инкрементная модель (3)

28.

Инкрементная модель (4)
Первый инкремент приводит к получению
базового продукта, реализующего базовые
требования.
План следующего инкремента предусматривает
модификацию базового продукта,
обеспечивающую дополнительные
характеристики и функциональность.
По своей природе инкрементный процесс
итеративен, но, в отличие от макетирования,
инкрементная модель обеспечивает на каждом
инкременте работающий продукт.

29.

Достоинства
инкрементной модели
Декомпозиция проекта на более мелкие
законченные части
Результат инкремента – функциональный
продукт
Снижение затрат на проектирование
Более точное планирование
Возможность использования с другими
моделями
Современная реализация – экстремальное
программирование

30.

Недостатки
инкрементной модели
Необходимость
приоритезации требований
Отсутствие четких
требований для всей системы
в целом на ранней стадии
проекта

31.

Стоимость ошибок

32.

Макетирование
(прототипирование)
Это процесс создания модели требуемого
программного продукта.
Основная цель – снять неопределенности в
требованиях заказчика.
Модель может принимать одну из трех форм:
бумажный макет или макет на основе ПК (изображает
или рисует человеко-машинный диалог);
работающий макет (выполняет некоторую часть
требуемых функций);
существующая программа (характеристики которой
затем должны быть улучшены).

33.

Макетирование
Ожидание заказчика
Построение/уточненение
макета
Оценка макета
заказчиком
Итерации повторяются до тех пор, пока макет не
выявит все требования заказчика и, тем самым,
не даст возможность разработчику понять, что
должно быть сделано.

34.

Макетирование
Достоинство:
обеспечивает
определение полных
требований к ПО.
Недостатки:
заказчик может принять
макет за продукт;
разработчик может
принять макет за
продукт.

35.

Спиральная модель
автор Барри Боэм
предложена в 1988 г.
классический пример применения
эволюционной стратегии конструирования
базируется на лучших свойствах
классического жизненного цикла и
макетирования, к которым добавляется
новый элемент – анализ риска,
отсутствующий в этих парадигмах.

36.

Особенность
спиральной модели
прикладное ПО создается не сразу, как в
случае каскадного подхода, а по частям с
использованием метода
прототипирования
под прототипом понимается
действующий программный компонент,
реализующий отдельные функции и
внешние интерфейсы
разрабатываемого ПО

37.

Спиральная
модель
Анализ текущей ситуации,
выработка единого понимания
контекста среди проектной команды
1. Понимание
контекста
Принятие решения о
переходе на
следующую фазу
2. Анализ
рисков
3. Разработка
плана
5. Управление и
планирование
Контроль и
управление
изменениями
4. Разработка
продукта
Концептуальное проектирование, физическое
проектирование, прототипирование,
кодирование, подготовка тестовой спецификации
и т.п.

38.

Этапы
в спиральной модели
Планирование – определение целей,
вариантов и ограничений.
Анализ риска – анализ вариантов и
распознавание/выбор риска.
Конструирование – разработка
продукта следующего уровня.
Оценивание – оценка заказчиком
текущих результатов конструирования.

39.

Действия
в спиральной модели
1. Начальный сбор требований и планирование
проекта
2. То же, но на основе рекомендаций заказчика
3. Анализ риска на основе начальных требований
4. Анализ риска на основе реакции заказчика
5. Переход к комплексной системе
6. Начальный макет системы
7. Следующий уровень макета
8. Сконструированная система
9. Оценивание заказчиком

40.

Спиральная модель

41.

Основная проблема
спирального цикла
определение момента перехода на следующую
стадию
для решения необходимо ввести временные
ограничения на каждую из стадий жизненного
цикла
переход осуществляется в соответствии с планом,
даже если не вся запланированная работа
закончена
план составляется на основе статистических
данных, полученных в предыдущих проектах, и
личного опыта разработчиков

42.

Достоинства
спиральной модели (1)
Наиболее реально (в виде эволюции)
отображает разработку программного
обеспечения
Позволяет явно учитывать риск на каждом
витке эволюции разработки
Включает шаг системного подхода в
итерационную структуру разработки
Использует моделирование для уменьшения
риска и совершенствования программного
изделия

43.

Достоинства
спиральной модели (2)
Позволяет использовать каскадный подход на
завершающих стадиях проекта в тех случаях,
когда требования к системе оказываются
полностью определенными
Сохраняет преимущества каскадной модели
Позволяет увидеть систему на ранних этапах
Заложен механизм управления рисками
Сочетает итеративный и инкрементальный
подход
Позволяет учитывать обратную связь от
заказчика

44.

Недостатки
спиральной модели
Повышенные требования к заказчику
Трудности контроля и управления
временем разработки
Сложность использования
Может оказаться дорогой для маленьких
проектов

45.

Выводы
Разработка ПО с использованием формальной
модели повышает вероятность успешного
завершения проекта
Идеальных моделей не существует
Любая модель должна быть адаптирована для
использования в компании
В компании могут использоваться разные модели
для проектов разных типов
На основе классических моделей можно создавать
новые гибридные модели

46.

Введение в программную
инженерию
Лекция 5
Техническое задание.

47.

Правильное конструирование –
залог качества ПО
Конструирование — крупная часть процесса
разработки ПО.
Конструирование занимает центральное место в
процессе разработки ПО.
Повышенное внимание к конструированию может
намного повысить производительность труда
программистов.
Результат конструирования — исходный код —
часто является единственным верным описанием
программы.
Конструирование — единственный процесс,
который выполняется во всех случаях

48.

Зачем нужны официальные
требования?
Явные требования помогают гарантировать, что
функциональность системы определяется
пользователем, а не программистом.
Если требования сформулированы явно,
пользователь может проанализировать и
утвердить их.
Явные требования позволяют не гадать, чего
хочет пользователь. Кроме того, наличие явных
требований помогает избегать споров.
Требования позволяют определить
функциональность системы до начала
программирования.

49.

Зачем нужны официальные
требования?
Внимание к требованиям помогает свести к
минимуму изменения системы после начала
разработки.
Не имея грамотно определенных
требований, вы можете правильно
представлять общую проблему, но упустить
из виду ее специфические аспекты
Требования подобны воде. Опираться на них
легче если они заморожены. Аноним.

50.

Специфические
функциональные требования
Определены ли все способы ввода данных в
систему с указанием источника, точности,
диапазона значений и частоты ввода?
Определены ли все способы вывода данных
системой с указанием назначения, точности,
диапазона значений, частоты и формата?
Определены ли все форматы вывода для
отчетов и т. д.?

51.

Специфические
функциональные требования
Определены ли все внешние аппаратные и
программные интерфейсы?
Определены ли все внешние
коммуникационные интерфейсы с указанием
протоколов установления соединения,
проверки ошибок и коммуникации?
Определены ли все задачи, в выполнении
которых нуждается пользователь?
Определены ли данные, используемые в
каждой задаче, и данные, являющиеся
результатом выполнения каждой задачи?

52.

Специфические
нефункциональные требования
Требования к качеству.
Определено ли ожидаемое пользователем
время реакции для всех необходимых
операций?
Определены ли другие временные
параметры, такие как время обработки
данных, скорость их передачи и пропускная
способность системы?
Определен ли уровень защищенности
системы?

53.

Специфические
нефункциональные требования
Определена ли надежность системы, в том числе такие
аспекты, как следствия сбоев в ее работе,
информация, которая должна быть защищена от
сбоев, и стратегия обнаружения и исправления
ошибок?
Определены ли минимальные требования программы к
объему памяти и свободного дискового пространства?
Определены ли аспекты удобства сопровождения
системы, в том числе способность системы
адаптироваться к изменениям специфических
функций, ОС и интерфейсов с другими приложениями?
Включено ли в требования определение успеха? Или
неудачи?

54.

Качество требований
Написаны ли требования на языке, понятном
пользователям? Согласны ли с этим пользователи?
Нет ли конфликтов между требованиями?
Определено ли приемлемое равновесие между
параметрами-антагонистами, такими как
устойчивость к нарушению исходных предпосылок
и корректность?
Не присутствуют ли в требованиях элементы
проектирования?
Согласован ли уровень детальности требований?
Следует ли какое-нибудь требование определить
подробнее? Менее подробно?

55.

Качество требований
Достаточно ли ясны и понятны требования, чтобы их
можно было передать независимой группе
конструирования?
Согласны ли с этим разработчики?
Каждое ли требование уместно для проблемы и ее
решения?
Можно ли проследить каждое требование до его
источника в проблемной среде?
Можно ли протестировать каждое требование? Можно
ли будет провести независимое тестирование, которое
позволит сказать, выполнены ли все требования?
Определены ли все возможные изменения требований
и вероятность каждого изменения?

56.

Полнота требований
Указаны ли недостающие требования, которые
невозможно определить до начала разработки?
Полны ли требования в том смысле, что если
приложение будет удовлетворять всем
требованиям, то оно будет приемлемо?
Не вызывают ли какие-нибудь требования у вас
дискомфорта?
Исключили ли вы требования, которые не
поддаются реализации и были включены лишь для
успокоения клиента или начальника?

57.

Техническое задание (ТЗ)
Исходный документ на проектирование
технического объекта.
Устанавливает основное назначение
разрабатываемого объекта, его технические и
тактико-технические характеристики,
показатели качества и технико-экономические
требования, предписание по выполнению
необходимых стадий создания документации
(конструкторской, технологической,
программной и т. д.) и её состав, а также
специальные требования.

58.

Техническое задание (ТЗ)
Документ на разработку, содержащее
описание целей выполнения работы, сроков
выполнения, требований к результатам
работы, форм отчетности.
Основное назначение ТЗ это выработка
единого взаимопонимания между
постановщиком задачи, лидером и
разработчиками проекта поставленной цели.
Кроме того, техническое задание является
основополагающим документом для
определения временных и материальных
затрат на разработку.

59.

Советы по разработке ТЗ
Прежде, чем составлять техническое
задание, пользователь должен понять, что
именно он хочет получить. Следует
определить цель задания, ключевые
особенности желаемого результата,
нарисовать (написать, создать таблицу) для
себя желаемый выход работы.
Собрать документацию, согласно которой вы
выполняете работу, для которой необходимо
приложение (программа). Прочитать ее
внимательно, с карандашом, отмечая
особенности и тонкости.

60.

Трудности и как их избежать
Срыв сроков.
Цена-сроки-объем работ.
Обратная связь.
Старайтесь фиксировать все, о чем
договариваетесь.
Презентуйте результат.
Старайтесь не делать только как пожелает
заказчик. Как правило, худший вариант в
данном случае и будет принят. Думайте.

61.

Маленькие хитрости
Ментальные карты.
Версии и названия файлов.
Структура.
Форматирование.
Цените себя и свое время, ведь готовый
продукт — результат ваших усилий.

62.

Советы по разработке ТЗ
Следует понять, какие параметры следует задавать на
входе, какова периодичность работы с желаемой
программой (отчетом, приложением, утилитой), сколько
данных примерно будет получаться на выходе и все ли
они нужны (к примеру, если вам нужна сумма выручки от
продаж пяти категорий изделий по категориям без
наименований, не стоит требовать создания отчета в
миллион строк с указанием каждой продажи с
детальными характеристиками). Далеко не каждому
специалисту необходима максимально детализированная
информация, обработка которой создает значительную
нагрузку для вычислительных систем.
Подробно описать необходимую информацию, указать ее
особенности, исключения, необходимый уровень
детализации. Следует продумать все мелочи: формат
чисел, округление, доли, ставки и проч.

63.

Советы по разработке ТЗ
Избавиться в техническом задании от расплывчатых
описаний, лишних слов, слов-паразитов. Проверить
пунктуацию – зачастую ошибки в ней искажают смысл
задания. Задание на проект – это документ и
лексика в нем должна быть соответствующая.
Однако не следует стараться написать все на
техническом языке, если вы не владеете терминологией
на должном уровне.
Обсудить написанное задание с непосредственным
исполнителем, попытаться разрешить все вопросы,
внимательно прислушиваясь к мнению собеседника. Не
стоит забывать, что вы свою сферу деятельности знаете
лучше и только вы можете точно объяснить, какой
инструмент вам необходим для эффективно работы. ITспециалист знает свое дело и не обязан знать нюансы
работы каждого отдела в организации.

64.

Советы по разработке ТЗ
Передать задание в работу за разумный срок до
окончательной реализации, чтобы была
возможность протестировать результат и
исправить возможные ошибки.
Если ваши подчиненные также будут пользоваться
созданным приложением, постарайтесь им
самостоятельно объяснить особенности работы с
приложением – это избавит IT-специалиста от
необходимости сто раз объяснять одно и то же.
Помните, что ваше задание будет служить
справочником для вас — в нем всегда можно
посмотреть описание информации, вспомнить
забытое требование.

65.

Техническое задание
Какие элементы должны быть
прописаны, а какие – в уме?
Все элементы и документы
должны быть прописаны и
никаких моментов не должно
быть в уме!
Правило работы с клиентом:
Больше бумаги – чище *опа!

66.

Техническое задание
Обычно то, что вы держите в уме,
никогда не совпадает с тем, что держит в
уме заказчик.
Проект – «вещь» живая и, само собой, во
время его выполнения, возникнут новые
веяния и цели/задачи, которые клиент
захочет сразу же реализовать.

67.

Введение в программную
инженерию
Лекция 8
Архитектура ПО

68.

Определения понятия
«Архитектура ПО» (1)
Архитектура
ПО
–
это
структура
программного обеспечения, т.е. изложение
его программных элементов,
их внешних
свойств и установленных между ними
отношений
Архитектура
ПО
–
это
структура
компонентов
программы
или
системы,
взаимосвязи, а также принципы и нормы их
проектирования и развития во времени
Л. Басс

69.

Определения понятия
«Архитектура ПО» (2)
Архитектура ПО – набор систем, состоящий
из всех проектных решений по поводу
структур программы и взаимодействий между
этими структурами, которые составляют
системы
Л.Г. Гагарина
Архитектура ПО – это структура программы
или
вычислительной
системы,
которая
включает программные компоненты, видимые
снаружи свойства этих компонентов, а также
отношение между ними
Wikipedia

70.

Архитектура ПО. Начало
Научно-исследовательская работа
Эдсгера Дейкстры в 1968 году
Исследовательская работа Дэвида
Парнаса в начале 1970-х
Применение принципов архитектуры
программного обеспечения с середины
1980-х

71.

Первый этап – «Стихийное»
программирование
Структура
первых
программ
Период: 60-е года XX века
Языки программирования: Ассемблер, FORTRAN, ALGOL
Возможность использования подпрограмм
Сложность программ = возможности программиста
Подход в разработке: «снизу-вверх»
Тестирование и отладка 80% времени разработки

72.

Архитектура программы с
глобальной областью данных
Типичная программа состояла
из основной программы,
области глобальных данных и
набора подпрограмм.
Слабым местом такой
архитектуры было то, что при
увеличении количества
подпрограмм возрастала
вероятность искажения части
глобальных данных какойлибо подпрограммой.
Архитектура
программ с
глобальной
областью
данных

73.

Архитектура программы с
локальными данными
Чтобы сократить количество таких ошибок в подпрограммах,
было предложено размещать локальные данные.
Сложность разрабатываемого программного обеспечения при
использовании подпрограмм с локальными данными по-прежнему
ограничивалась возможностью программиста отслеживать
процессы обработки данных, но уже на новом уровне.
Архитектура
программы,
использующей
подпрограммы
с локальными
данными

74.

Архитектура программы,
состоящей из модулей

75.

Особенности структурного
подхода
Период: 70-80-е года XX века
Языки программирования: ALGOL-68, Pascal,
C, Ада, Modula
Использование принципа «декомпозиции» разбиение на части
Подход в разработке: «сверху-вниз»
Развитие подхода в виде концепции
«модульного программирования»
Появление межмодульных интерфейсов

76.

Третий этап – Объектный
подход к программированию
Архитектура
программы при
объектноориентированном
подходе

77.

Особенности
объектного подхода
Период: 80-90-е года XX века.
Языки программирования: С++, Pascal, Java
Появление классов.
Использование механизмов: наследование,
полиморфизм, композиция.
Развитие визуального
программирования:Borland Delphi, Borland
C++Builder, MS Visual C++.
Недостатки: отсутствие стандартов при
работе компиляторов, изменение объекта
требует перекомпиляции проекта.

78.

Четвертый этап – компонентный
подход и CASE-технологии
Взаимодействие программных компонентов различных типов

79.

Особенности
компонентного подхода
Период: 90-00-е года XX века.
Языки программирования: С++, Java,
Delphi, Visual Basic.
Технологии COM и CORBA.
Технологии OLE и ActiveX.
CASE-технологии.
Совмещение структурного, объектного и
компонентного подхода при разработке.

80.

Пятый этап – итеративный
подход и гибкие методологии

81.

Особенности
итеративного подхода
Период: 00-е-настоящее время XXI века
Языки программирования: современное
множество языков
Использование гибких методологий
Разработка маленькими командами за
короткий промежуток времени
Сложность разрабатываемого
программного обеспечения возрастает с
каждой следующей итерацией

82.

Гибкие методологии
и их особенности
Динамические формирование требования
Результатом каждой итерации является
рабочий программный продукт
Противоречивость требования заказчика
по окончанию итерации выбранной
архитектуре
Быстрейший и простейший метод решения
задачи

83.

Архитектурные стили
Клиентсерверная
архитектура
Монолитное
приложение
Архитектура
вокруг БД
Peer-to-Peer
Распределенные
вычисления
Трех-уровневая
архитектура
Plug-In
Front-end and
back-end

84.

Монолитное приложение
Одноуровневое программное обеспечение,
в котором интерфейс пользователя и
логика работы с данными объединены в
единственное приложение без
дополнительных модулей.
Является автономным.
Независимость от других приложений.

85.

Клиент-серверная
архитектура
Вычислительная или сетевая архитектура, в
которой задания или сетевая нагрузка
распределены между поставщиками услуг
(сервисов), называемыми серверами, и
заказчиками услуг, называемыми клиентами.
Нередко клиенты и серверы
взаимодействуют через компьютерную сеть и
могут быть как различными физическими
устройствами, так и программным
обеспечением.

86.

Пример клиент-серверной
архитектуры

87.

Основные элементы клиентсерверной архитектуры
Набор серверов.
Набор клиентов.
Сеть для взаимодействия клиентов и
серверов.

88.

Плюсы и минусы
архитектуры
Неработоспособнос
+ Минимальные требования к
ть сервера
оборудованию на котором
останавливает всю
работает клиент.
работу клиентов
+ Надежность и защищенность
сервера на котором хранятся
- Наличие
данные.
системного
+ Использование ресурсов сервера администратора
клиентами на различных
- Дороговизна
платформах
оборудования для
+ разгрузка сети за счет передачи
сервера.
небольших объемов данных
между клиентов и сервером

89.

Трех-уровневая архитектура
Архитектурная модель программного
комплекса, предполагающая наличие в нём
трёх компонентов:
1. клиентского приложения (обычно
называемого «тонким клиентом» или
терминалом);
2. сервера приложений, к которому
подключено клиентское приложение;
3. сервера базы данных, с которым работает
сервер приложений.

90.

Пример трех-уровневой
архитектуры

91.

Плюсы и минусы трехуровневой архитектуры
+ масштабируемость - сложность создания
приложений
+ конфигурируемость
- сложность
+ безопасность
развертывания и
администрирования
+ надежность
высокие
требования
к
+ низкие требования
производительности
к сети
серверов
+ низкие требования - высокие требования к
к терминалам
сети между серверами

92.

Архитектура вокруг БД
Ключевую роль играет база данных
Бизнес-логика хранится в БД.
Сервер приложений управляет лишь
обращениями пользователей к БД.
Приложение отвечает только за
интерфейс пользователя.
Использование стандартных инструментов
СУБД.

93.

Пример архитектуры
вокруг БД

94.

Распределенные вычисления
Способ решения трудоёмких
вычислительных задач с использованием
нескольких компьютеров, чаще всего
объединённых в параллельную
вычислительную систему.
Распределённые вычисления применимы
также в распределенных системах
управления.
Неограниченный рост производительности
за счет масштабирования

95.

Пример архитектуры
распределенных вычислений

96.

Пример архитектуры на основе
облачных
вычислений

97.

Архитектура
Front-End и Back-End
Front-End – публичная часть проекта,
обеспечивающая прием запросов от
пользователей, трансляцию запросов к
Back-End и выдачу непосредственного
содержимого пользователю.
Back-End – исполнительная часть системы,
которая обеспечивает выполнение скриптов,
формирование контентных страниц и работу
бизнес-логики приложений.

98.

Пример
Front-End
архитектуры
и Back-End

99.

Архитектура Peer-to-peer
Оверлейная компьютерная сеть, основанная
на равноправии участников.
В такой сети отсутствуют выделенные
серверы, а каждый узел (peer) является как
клиентом, так и сервером.
В отличие от архитектуры клиент-сервера,
такая организация позволяет сохранять
работоспособность сети при любом
количестве и любом сочетании доступных
узлов.
Участниками сети являются пиры.