Введение в технологию проектирования программного обеспечения (тема 1)

1.

АНОО ВО СИБИРСКИЙ ИНСТИТУТ БИЗНЕСА И ИНФОРМАЦИОННЫХ
ТЕХНОЛОГИЙ
Учебная дисциплина:
Основы проектирования ПО
Куликова Елена Васильевна

2.

Что изучает?
- ознакомление студентов с методами, подходами и
технологиями проектирования ПО;
- ознакомление студентов с инструментальными
средствами проектирования ПО;
- приобретение навыков разработки, тестирования,
отладки и оценки компонентов программных
проектов.

3.

Лекции: 18 часов (9 пар)
• Лабораторные работы: 36 часов (18 пар)
• Зачет

4.

Тема 1. Введение в технологию проектирования
программного обеспечения

5.

1.1 Процесс проектирования. Цели, основные
виды деятельности проектирования ПО

6.

Программирование ≠ Проектирование
Программирование – деятельность, которая
может
происходить во многих различных контекстах:
«просто нравиться»;
«чтобы научиться»;
«потому что надо»;
«в рамках разработки проекта»;
…..
6

7.

Раньше…
All rights reserved.
Программные продукты
могли в обозримые
сроки разрабатываться
одиночками
или IT-подразделениями
автоматизируемых
предприятий.

8.

Разработка программных продуктов сейчас?

9.

Сейчас
All rights reserved.
1. Разработка ПО – это производственный
процесс, в который вовлечено огромное количество
различных специалистов, находящихся в разных
странах и городах. Наличие ИТ-команды!

10.

ИТ-команда?

11.

Сейчас
All rights reserved.
2. Создание программного обеспечения – сложный
высоко-конкурентный бизнес, содержащий
большую долю творческой составляющей.

12.

Сейчас
All rights reserved.
3. Эффективное взаимодействие внутри команды и
между командами, включенными в общий проект,
невозможно без наличия общих договоренностей,
реализуемых в виде стандартов и методологий.

13.

Стандарты и методологии?

14.

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

15.

Эффективность ИТ-проектов, статистика
успешности
Статистика успешности ИТ проектов (по данным
компании «Standish Group» —компании,
предоставляющей услуги по исследованию и
анализу эффективности работы ИТ-проектов»)
15
Succeeded – выполнены в срок,
в
пределах
бюджета
и
реализовали
нужную
функциональность;
Challenged
–
превысили
бюджет
и/или
сроки,
реализовали
только
часть
функционала;
Failed
–
отменены
до
завершения либо завершены,
но не внедрены или результаты
не используются.

16.

Почему падают ИТ-проекты? Анализ,
выводы, собственная оценка…
16

17.

Особенности программных проектов
Высокая
сложность
Часто –
недостаточный
профессионализм
участников
17
Высокая
изменчивость

18.

Сложность ИТ-проектов.
Причины сложности ИТ-проектов:
большой объем сложной функциональности;
сложность документирования и затруднительность оценки
документов;
высокая сложность и быстрое изменение технологий разработки;
высокая сложность программной архитектуры;
необходимость обеспечить работоспособность на разных
All rights reserved.
аппаратно-программных платформах;
сложность и вариативность среды исполнения;
нематериальность артефактов;
относительно низкий объем повторяемой, рутинной деятельности;
проблема «собственности на код».

19.

Изменчивость ИТ-проектов
Составляющие высокой изменчивости ИТ-проектов:
изменчивость бизнес-среды заказчика;
сильная изменчивость пользовательских требований;
увеличение сложности по мере углубления в задачу.
All rights reserved.
Сложность
проектов
Невозможность предусмотреть
все заранее и избежать ошибок
Необходимость внесения уточнений
и исправлений в проектные решения

20.

Что в итоге?
отсутствие порядка в процессе разработки (разработка – есть,
упорядоченного процесса – нет);
высокая трудоемкость проверки соответствия работы системы
спецификациям;
отсутствие гарантий работоспособности системы в реальной
среде;
All rights reserved.
сложность дальнейшего развития.
Итог: недовольный Заказчик со всеми вытекающими…

21.

Что делать?
Знать и учитывать уникальность отрасли
разработки ПО.
Знать и использовать лучшие практики, как
основу успешного выполнения ИТ-проектов.
Постоянно и активно учиться:
• читать, слушать и слышать;
• пробовать;
• приспосабливать знания к текущей ситуации.
21

22.

software engineering
Инженерия разработки программного обеспечения
(software engineering) – это инженерная дисциплина,
охватывающая все аспекты разработки ПО.
Термин – software engineering (программная
инженерия) – впервые был озвучен в октябре 1968
года на конференции подкомитета НАТО по науке и
технике ( г. Гармиш , Германия):
Рассматривались проблемы проектирования,
разработки,
распространения и поддержки программ.
Впервые прозвучал термин «программная инженерия» как
некоторая дисциплина , которую надо создавать и которой
надо руководствоваться в решении перечисленных проблем .
22

23.

Разные трактовки термина «Программная
нженерия»
установление и использование обоснованных инженерных
принципов (методов) для экономного получения ПО,
которое надежно и работает на реальных машинах [Bauer
1972].
та форма инженерии, которая применяет принципы
информатики (computer science) и математики для
рентабельного решения проблем ПО [CMU/SEI-90- TR-003]
применение систематического, дисциплинированного,
измеряемого подхода к разработке, использованию и
сопровождению ПО [IEEE 1990].
дисциплина, целью которой является создание
качественного ПО, которое завершается вовремя, не
превышает выделенных бюджетных средств и
удовлетворяет выдвигаемым требованиям [Schach, 99]
23

24.

Промышленное программирование
Предметом программной инженерии является
круг вопросов и проблем, возникающих при
промышленной разработке программных
продуктов.
Промышленное программирование
24

25.

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

26.

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

27.

Промышленное программирование
Оплата
работы
Четкое
понимание
конечного
результата
(«что нужно
Заказчику?»)
Определен
ные сроки
Заказчик
Команда
27
Промышлен
ное
программир
ование
Результат
должен быть
нужного
качества

28.

Программная инженерия =
программирование + дополнительные
виды деятельности
Дополнительные виды деятельности:
анализ,
разработка требований,
планирование,
организация процесса разработки
учет удобств дальнейшего сопровождения, повторного
использования и интеграции с другими системами
проектирование,
тестирование,
конфигурационное управление,
проектный менеджмент,
создание различной документации (проектной,
пользовательской и пр.).
28

29.

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

30.

Методы проектирования
Методы
проектирования
Метод структурного
анализа и
проектирования
SADT, DFD,
IDEF3
30
Метод сущность-связь
проектирования
информационных
систем
Нотация Чена, нотация
Мартина, IDEF1X и др.
Метод объектноориентированного
анализа
Язык UML

31.

Методология структурного анализа
Методология структурного анализа —
систематический пошаговый подход к анализу
требований и проектированию спецификаций
системы.
Целью этой методологии: преобразование общих,
неясных знаний о требованиях к системе в как можно
более точные определения.
Том Демарко — американский инженер-программист,
писатель и консультант по программной инженерии.
31

32.

Модели в структурном анализе и
проектировании
Используются различные модели, описывающие:
Функциональную структуру системы;
Последовательность выполняемых действий;
Передачу информации между функциональными
процессами;
Отношения между данными.
32

33.

Модели в структурном анализе и
проектировании
Наиболее распространенные модели :
функциональная модель SADT (Structured
Analysis and Design Technique);
DFD (Data Flow Diagrams) - диаграммы потоков
данных;
IDEF3 (Integrated DEFinition for Process Description
Capture Method) — методология моделирования и
стандарт документирования процессов,
происходящих в системе.
33

34.

SADT
SADT (structured analysis and design technique) —
методология структурного анализа и
проектирования, интегрирующая процесс
моделирования, управление конфигурацией
проекта, использование дополнительных
языковых средств и руководство проектом со
своим графическим языком.
34
Процесс моделирования может быть разделен на
несколько этапов: опрос экспертов, создание
диаграмм и моделей, распространение документации,
оценка адекватности моделей и принятие их для
дальнейшего использования.

35.

SADT
Формализовать процесс создания системы можно,
разбив его на следующие фазы:
• Анализ — определение того, что система будет
делать
• Проектирование — определение подсистем и их
взаимодействие
• Реализация — разработка подсистем по
отдельности, объединение — соединение
подсистем в единое целое
• Тестирование — проверка работы системы
• Установка — введение системы в действие
• Эксплуатация — использование системы
35

36.

Основные элементы SADT-диаграммы
36

37.

Пример. SADT-диаграмма
37

38.

Пример. SADT-диаграмма
38

39.

Пример. SADT-диаграмма
39

40.

DFD
DFD (Data Flow Diagrams) – метод структурного
анализа, использующий понятия «процесс»,
«поток данных» и «хранилище данных» для
описания системы в виде набора диаграмм,
отражающих и структурирующих назначение
проектируемой системы.
40
Требования к системе разбиваются на
функциональные компоненты (процессы) и
представляются в виде сети процессов, связанных
потоками данных.

41.

Основные элементы DFD
41

42.

Пример. DFD-диаграмма
42

43.

Пример. DFD-диаграмма
С точки зрения DFD:
Клиент– это внешняя
сущность, которая
является источником
данных и получением
результата.
Процесс обработки заказа
(подтверждение и
проводка данных в
системе менеджером).
Сбор заказа на складе
(после получения заявки).
Оформление отгрузки
(создание необходимых
документов).
43

44.

DFD и SADT?
DFD создавались как средство проектирования ИС
любой класс систем моделируется при помощи DFDориентированных методов
большой набор элементов, адекватно отражающих
специфику различных систем (например, хранилища
данных являются прообразами файлов или баз данных,
внешние сущности отражают взаимодействие
моделируемой системы с внешним миром)
акцент на взаимодействие между собой потоков данных
SADT создавались как средство моделирования
систем вообще
SADT-диаграммы менее выразительны и удобны при
моделировании ПО
Дуги в SADT жестко типизированы (вход, выход,
управление, механизм)
44

45.

IDEF3
IDEF3 (Integrated DEFinition for Process Description
Capture Method) — методология моделирования и
стандарт документирования процессов,
происходящих в системе (показывает причинноследственные связи между ситуациями и событиями
в понятной эксперту форме).
использует графическое описание информационных
потоков, взаимоотношений между процессами обработки
информации и объектов, являющихся частью этих
процессов.
дает возможность аналитикам описать ситуацию, когда
процессы выполняются в определенной
последовательности, а также описать объекты,
участвующие совместно в одном процессе
45

46.

IDEF3, типы диаграмм
Модель в нотации IDEF3 может содержать два типа
диаграмм:
диаграмму Описания Последовательности
Этапов Процесса (Process Flow Description
Diagrams, PFDD)
диаграмму Сети Трансформаций Состояния
Объекта (Object State Transition Network, OSTN)
46

47.

Основные элементы IDEF3
47

48.

Пример. IDEF3-диаграмма
48

49.

Пример. IDEF3-диаграмма
49

50.

Нотация IDEF1X
См. Тема «Проектирование базы данных»
50

51.

Нотация Чена
См. Тема «Реляционные базы данных»
51

52.

Нотация Мартина
См. Тема «Реляционные базы данных»
52

53.

Методы объектно-ориентированного
анализа и проектирования
53

54.

Главная цель объектного анализа
Главная цель объектного анализа -
представить предметную область как множество
объектов со свойствами и характеристиками,
которые достаточны для их определения и
идентификации, а также для задания поведения
объектов в рамках выбранной системы понятий и
абстракций.
54

55.

Примеры методов объектно-ориентированного
анализа (их очень много! «Проверенных» более 50)
объектно-ориентированного системного анализа,
OOAS (Object- • метод
позволяющий выделить сущности и объекты ПрО (предметной
определить их свойства и отношения, а также
Oriented system области),
построить на их основе информационную модель, модель
состояний объектов и процессов представления потоков данных
analysis)
(dataflow);
OOA (ObjectOriented
analysis)
• метод объектно-ориентированного анализа ,
обеспечивающий моделирование ОМ (объектной модели) и
формирование требований к ПрО с помощью понятия
"сущность-связь", спецификацию потоков данных и
соответствующих процессов;
SD (Structured
Design)
• метод структурного проектирования системы, данных и
программ преобразования входных данных в выходные с
помощью структурных карт Джексона;
55

56.

Примеры методов объектно-ориентированного
анализа
OMT (Object
Modeling
Technique)
• технология объектного моделирования включает в
себя процессы (анализа, проектирования и
реализации), набор нотаций для задания четырех
моделей (объектной, динамической, функциональной и
взаимодействия)
UML
• объединенный метод , включающий средства и
понятия метода Г. Буча (объекты, классы,
суперклассы), принципы наследования, полиморфизма
и инкапсуляции, диаграммные средства
взаимодействия объектов Румбауха и др.
CORBA
• метод определения распределенных объектов на
основе объектной модели CORBA и набора сервисных
системных компонентов общего пользования,
обеспечивающих их функционирование в среде
распределенных приложений
56

57.

Принципы объектно-ориентированного
анализа и проектирования
принцип абстрагирования –
• предписывает включать в модель только те аспекты предметной области, которые имеют
непосредственное отношение к выполнению проектируемой системой своих функций
принцип инкапсуляции –
• предписывает разделять элементы абстракции на секции с различной видимостью, что
позволяет отделить интерфейс абстракции от его реализации; обычно скрываются структура
объектов и реализация их методов;
принцип модульности –
• определяет возможность декомпозиции проектируемой системы на совокупность сильно
связанных и слабо сцепленных модулей;
принцип иерархии –
• предписывает выполнять иерархическое построение моделей сложных систем на различных
уровнях детализации;
принцип многомодельности –
• обозначает, что при моделировании предметной области необходимо разрабатывать
различные модели проектируемой сложной системы, отражающие различные аспекты ее
поведения или структуры.
57
Куликова Елена Васильевна

58.

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

59.

UML (сокр. от англ. Unified Modeling Language –
унифицированный язык моделирования) – язык
графического описания для визуального
(объектного) моделирования в области
разработки программного обеспечения.
59

60.

Использование UML:
моделирование
программного
обеспечения
системное
проектирование
60
моделирование
бизнеспроцессов (BPM Business Process
Modeling)
отображение
организационных
структур
Куликова Елена Васильевна

61.

UML – язык программирования???
UML является языком широкого профиля, это
открытый стандарт, использующий графические
обозначения для создания абстрактной модели
системы, называемой UML моделью.
UML не является языком программирования, но в
средствах выполнения UML-моделей как
интерпретируемого кода возможна
кодогенерация.
61
Куликова Елена Васильевна