Информационные технологии и ПО

1. Цель и содержание курса

Цель – разработка качественного ПО :
надежного, эффективного, практичного,
мобильного.
Теоретическая часть курса – модели оценки
качества ПО, технологии разработки, описание
методов анализа требований, проектирования и
тестирования. В качестве инструмента в процессе
разработки используется язык UML.
Практическая часть курса – использование CASEсредства Rational Software Architect Designer
компании IBM для разработки качественного ПО.

2. Литература

1. Л. Мацяшек
Анализ и проектирование информационных систем с
помощью UML 2.0
Вильямс, 2016 год.
2. Д. Фарли
Современная программная инженерия. ПО в эпоху
эджайла и непрерывного развертывания
Питер, 2023 год.
3. I. Sommerville
Software Engineering
Tenth Edition, Pearson Education Limited, 2016
4. Г. Буч, А. Якобсон, Дж. Рамбо
Введение в UML.
ДМК Пресс, 2015 год.

3. Литература (продолжение)

5. Г. Буч
UML.
Питер, 2006 год.
6. К. Вигерс
Разработка требований к программному обеспечению.
Русская Редакция, 2016 год.
7. Cайт университета информационных технологий.
www.intuit.ru

4. Информационные технологии и ПО

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

5. Российские производители ПО

Типы программных продуктов
• Рroprietary
проприетарное
• Shareware
условно-бесплатное
• Freeware
свободное
• Commercial
коммерческое
• Open source
с открытым кодом
Производители:
СбербанкТехнологии – ПО для финансовой отрасли, ИИ
Yandex – поиск, карты, такси, торговля, ИИ
РусБИТех – ОС Astra Linux, ПО для ВС
VK– почта, социальные сети, игры, торговля
ABBYY – распознавание текстов, ИРД, словари
Лаборатория Касперского – антивирусные программы
1С – автоматизация работы предприятий, бухгалтерия,
игры

6. Необходимость технологий разработки

ПО – сложная интеллектуальная продукция.
ПО должно быть:
- надежным
- эффективным
- удобным в эксплуатации
- защищенным

7. Модель оценки качества ПО

• Обобщенные критерии качества
• Элементарные критерии качества
Каждый элементарный критерий может влиять на
несколько обобщенных критериев
• Показатели качества или метрики
Каждый показатель качества характеризует чаще
всего только один элементарный критерий
ГОСТ Р ИСО/МЭК 9126
ISO 9126 Standard

8. Стандарты документирования ПС

• Стандарты Institute of Electrical and Electronics
Engineers
IEEE 830-1993, IEEE 1016-1998
• Международные стандарты
ISO/IEC 12207:2008
• Государственные стандарты России
ГОСТ Р ИСО/МЭК 12207-2010

9. Обобщенные критерии качества

1. Функциональность
Functionality
2. Мобильность
Mobility
3. Надежность
Reliability
4. Эффективность
Performance
5. Сопровождаемость
(модифицируемость)
Serviceability
6. Практичность
(понятность и простота
использования)
Usability

10. Обобщенные критерии качества

• Функциональность - соответствие
функциональных возможностей ПО набору
требуемой пользователем
функциональности.
• Надёжность - способность выполнять свои
функции без ошибок в течение
определенного периода времени
• Эффективность - оптимизация объемов
используемых ресурсов
• Сопровождаемость - удобство проведения
изменений (модификаций) кода
• Практичность – легкость эксплуатации ПО

11. Мобильность

• Мобильность - способность ПО быть
перенесенным из одной среды в другую
• Портируемость - возможность один раз
откомпилировав код, обычно в
некоторый промежуточный код, который
интерпретируется во время исполнения
(Just-In-Time), затем запускать его на
множестве платформ без каких-либо
изменений.

12. Элементарные критерии качества

1. Точность
2. Согласованность
3. Структурированность
4. Отсутствие избыточности
5. Универсальность
6. Защищенность
7. Адаптируемость
…

13. Метрики

Метрика - это мера, позволяющая получить
численное значение некоторого свойства
программного обеспечения или процесса его
разработки.
Метрики делятся на два вида:
• характеризующие свойства самого продукта,
то есть разработанного кода
• характеризующие процесс создания и
эксплуатации ПО
Системы метрик:
Холстед
Йордан
Лоренц
Абреу (набор метрик для ООП)

14. Метрики

Число строк кода – Lines Of Code (LOC)
Число строк документации
Число различных операндов
Наличие средств проверки входных данных
Число внешних вводов
Среднее число строк для функций (методов).
Число классов
Глубина иерархии классов
Степень взаимосвязанности классов
Число переопределяемых методов
Плотность покрытия программного кода тестами
Число обнаруженных ошибок за месяц работы ПО
(характеризует процесс эксплуатации)
13. Время разработки в человеко-месяцах (характеризует
процесс разработки)
14. Стоимость разработки (характеризует процесс разработки)
15. Относительные характеристики: KLOC, число ошибок / KLOC,
стоимость / LOC, число строк документации / KLOC
.......
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

15. Для чего нужны критерии?

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

16. Риски при разработке ПО

1. Дефицит необходимых специалистов.
2. Нереалистичные сроки
3. Недостаточный бюджет.
4. Реализация несоответствующей требованиям
функциональности.
5. Разработка неудачного пользовательского
интерфейса.
6. “Золотая сервировка”, то есть чрезмерная
оптимизация и оттачивание деталей проекта.
7. Непрекращающийся поток изменения
требований со стороны заказчика.
8. Недостаточная производительность
разрабатываемой системы.
9. Несоблюдение требований безопасности.

17. Для чего нужны технологии?

1. Повысить качество ПО.
2. Снизить сроки разработки.
3. Уменьшить стоимость.
4. Обеспечить контроль над ходом
разработки.
5. Уменьшить риски.

18. Жизненный цикл ПС

1. Технико-экономическое обоснование
разработки
2. Анализ требований (анализ предметной
области)
3. Проектирование
4. Программирование
5. Тестирование и отладка
6. Развертывание и эксплуатация

19. Сравнение

20. Технологии разработки ПО

• Водопадная (waterfall)
• Расширения ядра
• Спиральная
• Эволюционного прототипирования
• RUP (Rational Unified Process)
• Гибкие (agile software development)
- OpenUp
- Scrum
- XP

21. Водопадная технология

22. Водопадная технология

23. Этапы водопадной разработки

Техникоэкономическое
обоснование
Анализ
требований
Проектирование
Программирование
Тестирование
и отладка
Возвраты на
предыдущие
этапы
нежелательны

24. Достоинства водопадной разработки

• Возможность планирования хода
процесса разработки
• Богатый опыт использования

25. Недостатки водопадной технологии

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

26. Итерационные технологии: этапы разработки

Техникоэкономическое
обоснование
Анализ
требований
Проектирование
Программирование
…
Тестирование
и отладка
Эволюция начинается
со второй итерации

27. Спиральная модель Боэма

Анализ
требований
Стоимость
Анализ рисков
Готовый
прототип
Программирование,
тестирование и
отладка
Проектирование

28. Итерационная разработка ПО

29. Гибкие технологии

• Постоянное сотрудничество с заказчиком, часто
представитель заказчика – член команды
разработчиков
• Быстрая реакция на меняющиеся требования, а
не следование четкому плану – адаптивность
• Планирование осуществляется на краткосрочную
перспективу – на одну итерацию
• Упор на программы, а не на документацию
• Тесные контакты между разработчиками
• Приоритет отдается простым решениям
• Упрощенный рефакторинг
• Продолжительность итерации (времени создания
прототипа системы) не более 2 месяцев

30. Agile-манифест разработки ПО

• Люди и взаимодействие важнее
процессов и инструментов
• Работающий продукт важнее
исчерпывающей документации
• Сотрудничество с заказчиком важнее
согласования условий контракта
• Готовность к изменениям важнее
следования первоначальному плану

31. Достоинства итерационных технологий разработки ПО

1. Обратная связь с заказчиком в процессе
разработки.
2. Возможность изменения требований к ПО.
3. Получение работающих версий до завершения
разработки.
4. Возможность принятия альтернативных решений.
5. Детальная отработка элементов интерфейса.
6. Равномерное распределение разных видов работ
в процессе создания программной системы.

32. Технико-экономическое обоснование разработки

- постановка задачи (определение основных функций
системы);
- определение экономических возможностей заказчика;
- определение технической базы;
- определение сроков разработки;
- определение требований к безопасности.
В результате должно быть сформировано обобщенное
техническое задание (ТЗ) на разработку системы.
Разработка ТЗ осуществляется заказчиком.
ТЗ может быть скорректировано заказчиком после
консультаций с исполнителем.

33. Анализ требований

• Словарь терминов
• Список функциональных требований на
естественном языке
• Список нефункциональных требований на
естественном языке
• Диаграммы прецедентов
• Сценарии
Диаграммы прецедентов используются для того,
чтобы более удобно и формализовано
представлять функциональные требования.
Диаграммы прецедентов – это один из видов
диаграмм UML.

34. Анализ требований

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

35. Типы отношений

Исполнитель и прецедент связываются
отношением ассоциации, если, либо исполнитель
инициирует выполнение прецедента, либо
исполнитель анализирует и/или использует
результаты работы прецедента.
Два прецедента могут связывать отношения
обобщения и зависимости.
Обобщение – это отношение наследования. В
отношении наследования участвуют семантически
подобные прецеденты.
Зависимость определяет условные и безусловные
отношения расширения и включения между
прецедентами.

36. Зависимость

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

37. Диаграммы прецедентов

ИПС
Ввод запроса
Анализ запроса
Поиск
Пользователь
Выдача результата

38. Диаграммы прецедентов

ИПС
Проверка
полномочий
Ввод запроса
Анализ запроса
Администратор
Добавление
записи

39. Отношения между прецедентами

расширение
предоставление
льгот
<< extend >>
предоставление
кредита
<< include >>
проверка
платежеспособности
включение
предоставление
кредита
обобщение
оформление
кредита физическим лицом
оформление
кредита

40. Диаграммы прецедентов

Банкомат
Выдача наличных денег
<<include>>
<<extend>>
Сообщение о
неверном
PIN-коде
Проверка
PIN-кода
<<include>>
Клиент
Банк
Выдача справки
о состоянии счета

41. Диаграмма прецедентов

Система
Покупка онлайн
<<include>>
Платеж кредиткой
Покупка
<<extend>>
<<include>>
Покупатель
Выбор места
Банк
Поиск рейса

42. Правила построения

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

43. Описание сценария

Исполнители
Банкомат
1. Клиент помещает карту в банкомат
2. Проверяет карту
Исключение1. Карта недействительна
4. Клиент вводит PIN-код
3. Просит ввести PIN-код
5. Проверяет PIN-код
Исключение 2. PIN-код неверен
7. Клиент выбирает снятие денег
6. Отображает на экране меню
9. Банк выясняет состояние счета
8. Делает запрос в банк
Исключение 3. Счет пуст
11. Клиент вводит сумму
10. Предлагает клиенту ввести сумму
12. Банк проверяет сумму
Исключение 4. Запрашиваемая сумма больше допустимой
13. Банк изменяет состояние счета
14. Возвращает кредитную карту,
выдает деньги и чек
15. Клиент получает деньги, чек и
кредитную карту

44. Задания для Л/Р

• Построить диаграмму прецедентов
работы информационной системы
университета (с точки зрения студента
и преподавателя).
• Построить диаграмму прецедентов
работы программной системы онлайн
бронирования и покупки авиабилетов.

45. Функциональные и нефункциональные требования

Программная система – online калькулятор
Функциональные:
• Выполнение арифметических операций
• Реализация более сложных функций
• Система помощи
• Реализация памяти
• Поддержка скобочной структуры
Нефункциональные:
• Работа под Windows
• Время выполнения операции меньше 2 сек.
• Формат справки такой-то.
• Объем памяти меньше 1 Гбайт.
• Формат представления чисел такой-то.

46. Бизнес-требования и требования пользователей

Программная система – текстовый редактор
Бизнес-требования:
Эффективное исправление орфографических ошибок
Хранение нескольких поколений одного и того же
текста
Возможность обмена документами, подготовленными в
других редакторах
Требования пользователей:
– Поиск и выделение слов с ошибками
– Подсказка, как правильно написать слово
– Замена неправильного слова на правильное слово
по всему тексту
– Добавление нового слова в словарь редактора

47. Шаблоны классов

кратность
Имя класса
- <атрибут-1>
+ <атрибут-2>
…
# <атрибут-n>
*
область
атрибутов
видимость
- <операция-1>
# <операция-2>
…
+ <операция-m>
область
сигнатуры

48. Отношения между классами

Обобщение
простое
множественное
Ассоциация
простая
агрегирование
композитное агрегирование
классы-ассоциации
Зависимость
Реализация

49. Отношение обобщения

Человек
Студент
Млекопитающее
Рыба
Кит

50. Обобщение

Disjoint - Overlapping
Complete - Incomplete
Человек
Врач
Мужчина

51. Отношение ассоциации

Отношение
ассоциация
возникает
тогда, когда объекты одного класса
устойчиво связаны с объектами того же
самого, другого или других классов.
Если
в
отношении
ассоциации
участвует два объекта, то такая
ассоциация называется бинарной.

52. Отношение ассоциации

Компания
работа
работодатель
работник
Человек
Человек
Сотрудник
потомок
предок
Родство
Прямое родство

53. Кратность ассоциаций

1
A
B
1..*
B
A
0..1
A
A
B
*
B
n..m
A
B
4, 7,11
A
B

54. Кратность ассоциаций

родство
1..*
1..*
Человек
*
ребенок
родитель 2
родитель-ребенок

55. Навигация

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

56. N-арнарные ассоциации

Ассоциации, описывающие отношения
между N объектами, называются Nарнарными. Типичный пример такого
отношения: мать – отец – ребенок. В
данном случае все объекты принадлежат
одному классу.
Некоторые N-арнарные (N>3) отношения
ассоциации могут быть выражены через
бинарные, но в общем случае это не так.

57. Тернарные ассоциации

*
*
Команда
Игрок
*
Год
Выступление игрока за команду в
течение года

58. Агрегирование

Агрегирование (aggregation) — это ассоциация между
классом A (часть) и классом B (целое), которая означает,
что объекты (один или чаще несколько) класса A входят
в состав объектов класса B.
Композитное агрегирование (сomposition) — это
агрегирование между классом A (часть) и классом B
(целое), которое дополнительно накладывает
следующее ограничение:
часть А существует, только пока существует целое В, и
прекращает свое существование вместе с целым.

59. Агрегирование

Окно
Факультет
1
является частью
1
входит в состав
*
2..*
Кнопка
Кафедра

60. Классы-ассоциации

Компания
1..*
*
Сотрудник
Работа
Должность
Зарплата
Дата начала работы
Атрибуты относятся не к конкретному классу – компании или
работе, а в целом к ассоциации

61. Ассоциация “один-ко-многим”

Компания
Сотрудник
1
1
Работа
*
Должность
Зарплата
Дата начала работы
1..*

62. Отношение зависимости

Type
A = Class
procedure l;
…
end;
B = Class
procedure n;
…
end;
…
procedure B.n;
Var
Object-a:A;
begin
…
Object-a.l;
end;
Type
A = Class
…
end;
B = Class
procedure m(p:A);
…
end;

63. Отношение реализации

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

64. Задания для Л/Р

1. Построить диаграмму классов: библиотека – книга –
автор – читатель – человек.
2. Построить диаграмму классов: предмет – студент –
преподаватель – ВУЗ.
3. Предметная область включает данные о домах,
квартирах и комнатах, а также людях, в них проживающих.
Представить эту информацию в виде диаграммы классов,
считая, что человек может владеть сразу несколькими
квартирами, а жить только в одной.
4. Построить диаграмму классов для предметной области
Расписание занятий. Предусмотреть наличие следующих
классов: предмет – группа – преподаватель – занятие –
аудитория.

65. Задания для Л/Р

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

66. Диаграмма классов

обучается на
1..2
50..*
Факультет
1..*
входит
Студент
1
Кафедра
*
1..*
посещает
5..*
Предмет
7..*
читает

67. Диаграмма классов

обучается на
1..2
ВУЗ
работает
1..4
10..*
1..*
50..*
Студент
*
Преподаватель
1
руководит
*
имеет в
программе
посещает
20..*
5..*
Предмет
1..*
читает
1..*

68. CASE-средства

CASE (Computer Aided Software Engineering)-средства
ориентированы на постоянное использование компьютера в
процессе разработки ПО.
Во многих CASE-средствах применяются UML-диаграммы.
Наиболее известные CASE-средства – Rational Software
Architect Designer (IBM), Together (OpenText), StarUML
(MKLab).
Поддержка UML-диаграмм встроена во многие среды
программирования, например, IntelliJ IDEA, Visual Studio
Code.
https://en.m.wikipedia.org/wiki/List_of_Unified_Modeling_
Language_tools
Цели использования CASE-средств:
- построение UML-диаграмм;
- генерация кода по UML-диаграммам;
- генерация UML-диаграмм на основе кода.

69. Объектно-ориентированное проектирование

1. Выявление классов определенного уровня
абстракции, соответствующего данной итерации.
2. Определение атрибутов и операций классов
(шаблоны классов).
3. Определение отношений между классами
(диаграммы классов).
4. Распределение классов по пакетам или
модулям (диаграммы пакетов).
5. Планирование реализации базовых методов
(диаграммы последовательностей).
Уровень абстракции – совокупность знаний о
предметной области, используемых на данной
стадии разработки, т.е. на данной итерации

70. Определение классов

1. Формулирование предназначения класса в
системе.
2. Класс чаще всего - это шаблон описания
множества однотипных объектов. Классы,
предусматривающие существование одного
объекта, встречаются редко. Это, как правило,
управляющие вспомогательные классы.
3. Класс должен содержать набор атрибутов.
Часто существуют один или несколько атрибутов,
идентифицирующих объекты класса.
4. Атрибут может впоследствии трансформироваться в класс.
5. Класс должен содержать набор операций.

71. Спецификация обобщения

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

72. Спецификация ассоциаций

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

73. Избыточные ассоциации

Покупатель
Платеж
1
*
Осуществление-платежа
Заказ-товара
*
1
Заказ

74. Спецификация агрегирования

Агрегирование – это отношение «часть - целое».
Агрегирование – это особый случай ассоциации,
обладающий дополнительной семантикой.
Так агрегирование обладает свойствами транзитивности и
асимметричности.
Транзитивность: если объект класса А является частью
объекта класса В, а объект класса В - частью объекта
класса С, то объект класса А является частью объекта
класса С.
Асимметричность: если объект класса А является частью
объекта класса В, то объект класса В не является частью
объекта класса А.
Композитное агрегирование обладает дополнительным
свойством – зависимостью по существованию.
Агрегирование степени выше 2 бессмысленно.

75. Эволюция системы

• добавление новых классов
• введение абстрактных классов
• разделение одного класса на ряд других
• добавление и изменение атрибутов и/или
операций классов
• введение новых отношений между
классами
• корректировка отношений между классами
• изменение логики работы базовых
методов классов

76. Представление объектов

[Имя объекта]: Имя класса
<атрибут-1>=значение-1
<атрибут-2>=значение-2
…
<атрибут-n>=значение-n
область
атрибутов

77. Ассоциация “один-ко-многим”

Компания
Сотрудник
1
1
Работа
*
Должность
Зарплата
Дата начала работы
1..*

78. Диаграмма объектов

:Сотрудник
Петров
:Сотрудник
Сидоров
Иванов
:Сотрудник
Юрина
Юрина
:Работа
Инженер
15000
:Работа
Вед. инженер
Вед.инженер
20000
20000
:Работа
Аспирант
Аспирант
7000
7000
:Работа
Инженер
12000
:Работа
Программист
25000
:Работа
Инженер
15000
:Компания
Газпром
Газпром
:Компания
Газпром
МИФИ
МИФИ
:Компания
Росатом
Роснефть
:Компания
Роснефть
Газпром
Росатом

79. Шаблоны проектирования

В объектно-ориентированном
проектировании шаблоном называется
именованное описание проблемы и ее
решения, которое можно применять в
разных ситуациях. То есть шаблоны
описывают общие принципы проектирования и стандартные архитектурные
решения.
Шаблон – это пара «проблема решение».

80. Шаблон проектирования Creator

Проблема - Какой класс отвечает за
создание объекта класса А?
Решение - Класс В будет отвечать за
создание объектов класса А, если:
•Класс В агрегирует объекты класса А.
•Класс В обладает данными для
инициализации объектов класса А.
•Класс В активно использует объекты
класса А.

81. Шаблон проектирования Information Expert

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

82. Шаблон проектирования Controller

Проблема – Кто должен отвечать за
получение и координацию операций,
поступающих на уровне интерфейса
пользователя?
Решение – Специальный класс, имеющий
информацию о работе всей системы в
целом или части системы (Controller).
Важно – Это не класс, реализующий
форму или окно. Последние делегируют
получаемые сообщения классу Controller.

83. Характеристики классов

• Связность класса
• функционально-логическая
- временная
- информационная
• Сцепление классов
- по данным
- по управлению
Вывод: внутри класса число связей должно
быть максимально возможным, а между
классами – минимальное число отношений
зависимости.

84. Шаблон проектирования Low Coupling

Проблема – Как снизить влияние изменений
в одних классах на функционирование
других классов?
Решение – Минимизировать степень
сцепления классов в процессе
распределения обязанностей между ними.

85. Шаблон проектирования High Cohesion

Проблема – Как обеспечить
сфокусированность обязанностей классов?
Решение – Максимизировать степень
связности класса (то есть, его методов) в
процессе распределения обязанностей
между классами.

86. Метрика связности

Есть даже специальная метрика
Lack of Cohesion in Methods
А-B
А - количество пар методов, использующих
хотя бы одно общее поле
B - количество пар методов, не использующих общие поля.

87. Шаблон проектирования Pure Fabrication

Проблема – Повышение связности и снижение сцепления
классов.
Решение – Чаще всего каждой сущности из предметной
области соответствует один или более классов
программной системы. При этом, обязанности по
взаимодействию классов, как правило, накладываются на
них самих. Такой подход имеет недостаток — высокое
сцепление классов системы.
Шаблон Pure Fabrication позволяет решить данную
проблему путем введения в программную систему
дополнительного не отражающего реальной сущности из
предметной области класса и наделение его требуемыми
обязанностями.

88. Архитектура ПС

Пять типов архитектуры ПС :
o монолитная
o клиент-серверная (2-уровневая)
o 3-уровневая
o сервисо-ориентированная
o микросервисная

89. Архитектура ПС

В любом случае выделяются две компоненты ПС:
Frontend и Backend.
Причем Frontend может частично выполняться даже на
клиенте (основная часть Frontend выполняется на
сервере).
Хорошо известная модель ПС
Model – View – Controller
ориентирована на разбиение системы на Frontend
(View), Backend (Model) и ПО, организующее
взаимодействие между пользователем и системой
(Controller). Бизнес-логика приложения реализуется
компонентой Backend.

90. Архитектура ПС

91. Корпоративная сервисная шина

92. Архитектура ПС

Для реализации Frontend и Backend часто
используются фреймворки и библиотеки.
Поскольку алгоритмическая сложность Frontend
и Backend несопоставима, то и библиотеки
чаще всего используются разные. Да и функции
Frontend и Backend принципиально
различаются.
На Backend кроме реализации бизнес-логики
возлагается и взаимодействие с БД.

93. Языки для Frontend

HTML
JavaScript
TypeScript
CSS

94. Языки для Backend

Python
Java
C++
C#
Scala
PHP