1 of 31

SWEBOK. Область знаний «Проектирование ПО»

МСПИСТ

19.05.2016 г.

Лекция 9

2 of 31

Источники литературы

  • http://www.computer.org/portal/web/swebok
  • Орлик С. Программная инженерия. Проектирование программного обеспечения (на базе SWEBOK – 2004). http://www.sorlik.ru
  • Орлов С. Технологии разработки программного обеспечения: Учебник/ — СПб.: Питер, 2002. — 464 с.: ил.
  • Кулямин В. Технологии программирования. Компонентный подход – М.: Бином, 2007 г.
  • Якобсон, Айвар; Буч, Грэди; Рамбо, Джеймс. Унифицированный процесс разработки программного обеспечения. СПб: Питер, 2002. 496 с.

​

​

3 of 31

Основные области SWEBOK

4 of 31

Дополнительные

области SWEBOK

5 of 31

Основные области SWEBOK

6 of 31

Область знаний «проектирование ПО» в SWEBOK

7 of 31

Область знаний «проектирование ПО» в SWEBOK

  1. Основы проектирования
  2. Ключевые вопросы проектирования
  3. Структура и архитектура ПО
  4. Анализ качества и оценка результатов проектирования
  5. Нотации проектирования ПО
  6. Стратегии и методы проектирования ПО

8 of 31

Область знаний «проектирование ПО» в SWEBOK

  1. Основы проектирования
  2. Ключевые вопросы проектирования
  3. Структура и архитектура ПО
  4. Анализ качества и оценка результатов проектирования
  5. Нотации проектирования ПО
  6. Стратегии и методы проектирования ПО

9 of 31

1. Основы проектирования ПО

1.1. Общие концепции проектирования

1.2. Контекст проектирования ПО

1.3. Процесс проектирования ПО

1.4. Принципы проектирования ПО

10 of 31

1. Основы проектирования ПО

1.1. Общие концепции проектирования

1.2. Контекст проектирования ПО

1.3. Процесс проектирования ПО

1.4. Принципы проектирования ПО

11 of 31

1.1. Общие концепции проектирования

12 of 31

Пример формулировки целей потока работ «Проектирование» в RUP

13 of 31

Цели проектирования RUP (1)

1) Получить глубокое понимание моментов, относящихся к нефункциональным требованиям и ограничениям, связанным с:

    • языками программирования,
    • многократным использованием компонентов,
    • операционными системами,
    • технологиями распределённой и параллельной обработки,
    • технологиями баз данных,
    • управления транзакциями и т.п.

​

14 of 31

Цели проектирования RUP (2)

2) Получить возможность разбить работу на множество управляемых частей, которые можно распределить между командами разработчиков, возможно – работающих параллельно.

3) Определить основные интерфейсы между подсистемами.

​

15 of 31

Пример формулировки целей потока работ «Проектирование» в RUP

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

​

16 of 31

Цели проектирования RUP (3)

4) Получить возможность визуализировать в стандартной нотации и объяснить проект

5) Создать абстракцию реализации системы, близкую к тривиальной, исходя из следующей парадигмы: реализация является уточнением проекта, которое приводит лишь к «наращиванию мяса», но не меняет структуру.

​

17 of 31

1. Основы проектирования ПО

  • 1.1. Общие концепции проектирования
  • 1.2. Контекст проектирования ПО
  • 1.3. Процесс проектирования ПО
  • 1.4. Принципы проектирования ПО

18 of 31

1.2. Контекст проектирования

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

Проектирование

Реализация

Тестирование

Техническое задание

Технический проект

19 of 31

1.3. Процесс проектирования

Архитектурное проектирование

Детальное проектирование

Результат проекти-рования

Технический проект

Эскизный проект

20 of 31

Пример структуры результата проектирования (RUP)

21 of 31

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

22 of 31

Диаграмма последовательности

23 of 31

1.4. Принципы (техники) проектирования ПО

1.4.1 Абстракция (Abstraction)

1.4.2 Связанность и связанность (Coupling and Cohesion)

1.4.3 Декомпозиция и разбиение на модули (Decomposition and Modularization)

1.4.4 Инкапсуляция/сокрытие информации (Encapsulation/information hiding)

1.4.5 Разделение интерфейса и реализации (Separation of interface and implementation)

1.4.6 Достаточность, полнота и простота (Sufficiency, completeness and primitiviness)

​

24 of 31

1.4.1. Абстракция

  • Абстракция данных

(статическая, в отношении информации);

  • Процедурная абстракция

(динамическая, в отношении поведения);

  • Абстракция контроля

(в отношении управления системой и обрабатываемой ею информации).

​

25 of 31

1.4.3 Декомпозиция и разбиение на модули (Decomposition and Modularization)

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

​

26 of 31

1.4.2 Связность и связанность (Cohesion and Coupling)

  • Связность, соединение (Cohesion) модуля – это мера зависимости его частей.
  • Чем выше связность модуля, тем лучше результат проектирования (тем «чернее» его ящик (С.Орлов))
  • Связанность, сцепление (Coupling) – определяет силу связи (часто, взаимного влияния) между модулями
  • Связанность — внешняя характеристика модуля, которую желательно уменьшать.

​

​

27 of 31

Связность и связанность – детали

  • (Орлов)

28 of 31

Инкапсуляция/сокрытие информации (Encapsulation/information hiding)

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

​

29 of 31

1.4.5 Разделение интерфейса и реализации (Separation of interface and implementation)

  • Данная техника предполагает определение компонента через специфицирование интерфейса, который:
  • известен (описан) ,
  • доступен клиентам (или другим компонентам),
  • независим от непосредственных деталей реализации.

​

30 of 31

1.4.6 Достаточность, полнота и простота (Sufficiency, completeness and primitiviness)

  • Этот подход подразумевает, что создаваемые программные компоненты обладают всеми необходимыми характеристиками, определенными абстракцией (моделью), но не более того.
  • То есть не включают функциональность, отсутствующую в модели.
  • Данный принципy наиблоее ярко представлен в гибких (agile) подходах к разработке ПО через метафору YAGNI
  • “You Aren’ t Going to Need It”, то есть “не делай этого, пока не понадобится”.

​

​

31 of 31

Источники литературы

  • Орлик С. Программная инженерия. Проектирование программного обеспечения (на базе SWEBOK – 2004). http://www.sorlik.ru
  • Орлов С. Технологии разработки программного обеспечения: Учебник/ — СПб.: Питер, 2002. — 464 с.: ил.
  • Кулямин В. Технологии программирования. Компонентный подход – М.: Бином, 2007 г.
  • Якобсон, Айвар; Буч, Грэди; Рамбо, Джеймс. Унифицированный процесс разработки программного обеспечения. СПб: Питер, 2002. 496 с.

​