Разделы презентаций


Введение в Программную Инженерию

Содержание

Отчет о хаосе The Standish Group International, “CHAOS Report”

Слайды и текст этой презентации

Слайд 1Введение в Программную Инженерию

Введение в  Программную Инженерию

Слайд 2Отчет о хаосе The Standish Group International, “CHAOS Report”

Отчет о хаосе  The Standish Group International, “CHAOS Report”

Слайд 4Что влияет на успешность программного проекта ?

Что влияет на успешность программного проекта ?

Слайд 8В конце 60-х – начале 70-х годов прошлого века произошло

событие, которое вошло в историю как первый кризис программирования. Событие

состояло в том, что стоимость программного обеспечения стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ для компьютеров. Тогда и заговорили о программной инженерии (или технологии программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ.

В конце 60-х – начале 70-х годов прошлого века произошло событие, которое вошло в историю как первый

Слайд 9Software Engineering ( SE ) 1968 год Конференции НАТО

Software Engineering ( SE ) 1968 год Конференции НАТО

Слайд 10Этапы развития программной инженерии
Повторное использование кода (модульное программирование)
Рост сложности программ

(структурное программирование)
Модификация программ (ООП)

Этапы развития программной инженерииПовторное использование кода (модульное программирование)Рост сложности программ (структурное программирование)Модификация программ (ООП)

Слайд 11software engineering
(программная инженерия) - впервые был озвучен в октябре

1968 года на конференции подкомитета НАТО по науке и технике.
Рассматривались

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

software engineering (программная инженерия) - впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по

Слайд 12Все виды деятельности, выполняемые в процессе промышленного программирования и необходимые

для успешного выполнения заказов называют программной инженерией (software engineering)
Получается, что

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

Слайд 13 Установление и использование правильных инженерных принципов (методов) для экономичного

получения надежного и работающего на реальных машинах программного обеспечения [Bauer

1972].
 Программная инженерия является такой формой инженерии, которая применяет принципы информатики (computer science) и математики для получения рентабельных решений в области программного обеспечения [CMU/SEI-90-TR-003].
 Наука о принципах и методологиях, применяемых при разработке и сопровождении программных систем. Она изучает применение систематического, упорядоченного и исчисляемого подхода к разработке, эксплуатации и сопровождению программного обеспечения (ПО), применение принципов инженерии по отношению к процессу разработки ПО [IEEE Std 610.12-1990]
 Установление и использование правильных инженерных принципов (методов) для экономичного получения надежного и работающего на реальных машинах

Слайд 14ТАКИМ ОБРАЗОМ
программная инженерия посвящена систематическим, управляемым и эффективным методам создания

высококачественного программного обеспечения.

ТАКИМ ОБРАЗОМ		программная инженерия посвящена систематическим, управляемым и эффективным методам создания высококачественного программного обеспечения.

Слайд 15Согласно SWEBOK (Software Engineering Body of Knowledge )
программная инженерия включает

в себя 10 основных и 7 дополнительных областей знаний, на

которых базируются процессы разработки ПО. К основным областям знаний относятся следующие области:
Software requirements — программные требования.
Software design — дизайн (архитектура).
Software construction — конструирование программного обеспечения.
Software testing — тестирование.
Software maintenance — эксплуатация (поддержка) программного обеспечения.
Software configuration management — конфигурационное управление.
Software engineering management — управление в программной инженерии.
Software engineering process — процессы программной инженерии.
Software engineering tools and methods — инструменты и методы.
Software quality — качество программного обеспечения.

Согласно SWEBOK (Software Engineering Body of Knowledge )		программная инженерия включает в себя 10 основных и 7 дополнительных

Слайд 16Дополнительные области знаний включают в себя:
Computer engineering — разработка компьютеров.
Computer

science — информатика.
Management — общий менеджмент.
Mathematics — математика.
Project management —

управление проектами.
Quality management — управление качеством.
Systems engineering — системное проектирование.

Дополнительные области знаний включают в себя:Computer engineering — разработка компьютеров.Computer science — информатика.Management — общий менеджмент.Mathematics —

Слайд 18Программное обеспечение
Программное обеспечение это набор компьютерных программ, процедур и

связанной с ними документации и данных (ISO/IEC 12207).

Программное обеспечение Программное обеспечение это набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC

Слайд 19ЖЦ, Программный процесс
Одним из основных понятий программной инженерии является понятие

жизненного цикла программного продукта и программного процесса.
Жизненный цикл –

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

ЖЦ, Программный процессОдним из основных понятий программной инженерии является понятие жизненного цикла программного продукта и программного процесса.

Слайд 20Программный процесс — это набор действий и связанных с ними

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

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

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

Слайд 21Модель программного процесса
это упрощенное описание программного процесса, представленное с некоторой

точки зрения. Модель задается в виде практических этапов, необходимых для

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

Слайд 22 Говоря о моделях процессов, необходимо различать фазы и виды деятельности:
Фаза

(phase) – это определенный этап процесса, имеющий начало, конец и

выходной результат. Например, фаза проверки осуществимости проекта, сдачи проекта и т.д. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и, часто, выплатой денег за выполненную часть работы.
Говоря о моделях процессов, необходимо различать фазы и виды деятельности:Фаза (phase) – это определенный этап процесса, имеющий

Слайд 23Вид деятельности (activity)
– это определенный тип работы, выполняемый в

процессе разработки ПО. Разные виды деятельности часто требуют разные профессиональные

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

Слайд 24К наиболее известным моделям относятся:
Водопадная (каскадная) модель
Спиральная (циклическая) модель
Быстрая

разработка приложений

К наиболее известным моделям относятся:Водопадная (каскадная) модель Спиральная (циклическая) модельБыстрая разработка приложений

Слайд 30







ЯП 4 поколения SQL+ языки визуального программирования (3 пок –

алгоритмический (как делать))

ЯП 4 поколения SQL+ языки визуального программирования (3 пок – алгоритмический (как делать))

Слайд 37







Артефакты - это некоторые продукты проекта, порождаемые или используемые в

нем при работе над окончательным продуктом (файлы, документы, шаблоны, коды


Артефакты - это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом (файлы,

Слайд 45Методы программной инженерии
Метод программной инженерии — это структурный подход к

созданию ПО, который способствует производству высококачественного продукта эффективным в экономическом

аспекте способом.
Методы программной инженерииМетод программной инженерии — это структурный подход к созданию ПО, который способствует производству высококачественного продукта

Слайд 46Метод программной индустрии основан на идее создания моделей ПО с

поэтапным преобразованием этих моделей в программу – окончательную модель решаемой

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

Метод программной индустрии основан на идее создания моделей ПО с поэтапным преобразованием этих моделей в программу –

Слайд 47 Методы должны включать в себя следующие компоненты:
Описание моделей системы и

нотация, используемая для описания этих моделей (например, объектные модели, конечно-автоматные

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

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

Слайд 48 Начиная с 70-х годов создано достаточно много методов разработки ПО.

Наиболее известны:
Метод структурного анализа и проектирования Том ДеМарко (1978),
Метод

объектно-ориентированного анализа Буч (1994), Рамбо (1991).
Метод сущность-связь проектирования информационных систем Чен (1976)


Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны:Метод структурного анализа и проектирования Том

Слайд 49UML Unified Modeling Language
блок-схемы (40г) ()
структурный анализ (60 г SADT, 70

г сущность-связь, потоков данных)
Объектно-ориентированный подход стандарт UML(1997 г.) С тех

пор вышло несколько версий стандарта UML. Текущая версия UML  2.4.1 

UML Unified Modeling Languageблок-схемы (40г) ()структурный анализ (60 г SADT, 70 г сущность-связь, потоков данных)Объектно-ориентированный подход стандарт

Слайд 50Виды диаграмм
Каждый вид диаграмм является типом моделей, реализующим определенную точку

зрения на программную систему. Виды диаграмм не являются строго обязательными

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

Слайд 52Структурные диаграммы
диаграммы классов (class diagrams) предназначены для моделирования структуры объектно-ориентированных

приложений классов, их атрибутов и заголовков методов, наследования, а также

связей классов друг с другом;
диаграммы компонент (component diagrams) используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов;
диаграммы объектов (object diagrams) применяются для моделирования фрагментов работающей системы, отображая реально существующие в runtime экземпляры классов и значения их атрибутов;
диаграммы композитных структур (composite structure diagrams) используются для моделирования составных структурных элементов моделей – коопераций, композитных компонент и т.д.;
диаграммы развертывания (deployment diagrams) предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);
Структурные диаграммыдиаграммы классов (class diagrams) предназначены для моделирования структуры объектно-ориентированных приложений классов, их атрибутов и заголовков методов,

Слайд 53Поведенческие диаграммы
диаграммы активностей (activity diagrams) используются для спецификации бизнес-процессов, которые

должно автоматизировать разрабатываемое ПО, а также для задания сложных алгоритмов;
диаграммы

случаев использования (use case diagrams) предназначены для «вытягивания» требований из пользователей, заказчика и экспертов предметной области;
диаграммы конечных автоматов (state machine diagram) применяются для задания поведения систем;
диаграммы взаимодействий (interaction diagram):
диаграммы последовательностей (sequence diagram) используются для моделирования временных аспектов внутренних и внешних протоколов ПО;
диаграммы схем взаимодействия (interaction overview diagram) служат для организации иерархии диаграмм последовательностей;
диаграммы коммуникаций (communication diagrams) являются аналогом диаграмм последовательностей, но по-другому изображаются (в привычной, графовой, манере);
временные диаграммы (timing diagrams) являются разновидностью диаграмм последовательностей и позволяют в наглядной форме показывать внутреннюю динамику взаимодействия некоторого набора компонент системы.
Поведенческие диаграммыдиаграммы активностей (activity diagrams) используются для спецификации бизнес-процессов, которые должно автоматизировать разрабатываемое ПО, а также для

Слайд 541. Диаграммы вариантов использования (Use Case)
описывает функциональное назначение системы

или, другими словами, то, что система будет делать в процессе

своего функционирования.
.

1. Диаграммы вариантов использования (Use Case) 		описывает функциональное назначение системы или, другими словами, то, что система будет

Слайд 55Суть диаграммы use case
Проектируемая система представляется в виде множества сущностей

или актеров, взаимодействующих с системой с помощью так называемых вариантов

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

Суть диаграммы use case		Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью

Слайд 56Базовые элементы этого вида диаграмм — вариант использования и актер.



Базовые элементы этого вида диаграмм — вариант использования и актер.

Слайд 57Стандартные элементы
Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого

или рядом с ним содержится его краткое название или имя

в форме глагола с пояснительными словами.

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

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

Слайд 58Варианты использования описывают не только взаимодействия между пользователями и сущностью,

но также реакции сущности на получение отдельных сообщений от пользователей

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

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

Слайд 59Актеры
Актер представляет собой любую внешнюю по отношению к моделируемой системе

сущность, которая взаимодействует с системой и использует ее функциональные возможности

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

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

АктерыАктер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует

Слайд 60Интерфейсы
Интерфейс (interface) служит для спецификации параметров модели, которые видимы извне

без указания их внутренней структуры.
В языке UML интерфейс является

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

Слайд 61Примечания
Примечания (notes) в языке UML предназначены для включения в модель

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

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

ПримечанияПримечания (notes) в языке UML предназначены для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к

Слайд 62Отношения на диаграмме вариантов использования
Между компонентами диаграммы вариантов использования могут

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

вариантов использования с экземплярами других актеров и вариантов. Один актер может взаимодействовать с несколькими вариантами использования. В этом случае этот актер обращается к нескольким сервисам данной системы. В свою очередь один вариант использования может взаимодействовать с несколькими актерами, предоставляя для всех них свой сервис.
Два варианта использования, определенные для одной и той же сущности, не могут взаимодействовать друг с другом, поскольку каждый из них самостоятельно описывает законченный вариант использования этой сущности.
Варианты использования всегда предусматривают некоторые сигналы или сообщения, когда взаимодействуют с актерами за пределами системы.
В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:
Отношение ассоциации (association relationship)
Отношение расширения (extend relationship)
Отношение обобщения (generalization relationship)
Отношение включения (include relationship)

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

Слайд 63Отношение ассоциации
Отношение ассоциации является одним из фундаментальных понятий в языке

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

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

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

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

Слайд 65Отношение расширения
Отношение расширения определяет взаимосвязь экземпляров отдельного варианта использования с

более общим вариантом, свойства которого определяются на основе способа совместного

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

Слайд 67  Отношение обобщения
Отношение обобщения служит для указания того факта, что некоторый

вариант использования А может быть обобщен до варианта использования В.

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

Слайд 69Отношение включения
Отношение включения между двумя вариантами использования указывает, что некоторое

заданное поведение для одного варианта использования включается в качестве составного

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

Слайд 71Бизнес ВИ и Системные ВИ
На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют

внешние пользователи с вашей организацией для достижения бизнес целей. На

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

Слайд 72Системная диаграмма ВИ
На Системной Диаграмме ВИ (СВИ) отображается, как взаимодействуют ваши внутренние

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

к ПО. Данная диаграмма используется на этапе Системного Анализа и формализации требований к ПО.
Системная диаграмма ВИНа Системной Диаграмме ВИ (СВИ) отображается, как взаимодействуют ваши внутренние Пользователи с вашей автоматизированной Системой, т.е. отображаются

Слайд 73Пример диаграммы вариантов использования
В качестве примера рассмотрим процесс моделирования системы

продажи товаров по каталогу, которая может быть использована при создании

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

Пример диаграммы вариантов использованияВ качестве примера рассмотрим процесс моделирования системы продажи товаров по каталогу, которая может быть

Слайд 74На следующем этапе разработки данной диаграммы вариант использования "Оформить заказ

на покупку товара" может быть уточнен на основе введения в

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

Слайд 75Приведенная диаграмма вариантов использования, в свою очередь, может быть детализирована

далее с целью более глубокого уточнения предъявляемых к системе требований

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

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

Слайд 79Диаграмма деятельности

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

Слайд 80
При моделировании поведения проектируемой или анализируемой системы возникает необходимость не

только представить процесс изменения ее состояний, но и детализировать особенности

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

Слайд 81В контексте языка UML деятельность (activity) представляет собой некоторую совокупность

отдельных операций.
При этом отдельные операции могут приводить к некоторому

результату или действию (action).
На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности.
В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных операций. При этом отдельные операции могут

Слайд 82Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции,

а переход в следующее состояние срабатывает только при завершении этой,

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

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

Слайд 83Ветвление на диаграмме деятельности обозначается небольшим ромбом, внутри которого нет

никакого текста
Процедуру вычисления корней квадратного уравнения можно представить в виде

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

Слайд 84В языке UML для распараллеливания операций используется специальный символ для

разделения (рис. а) и слияния (рис. б) параллельных потоков.

В языке UML для распараллеливания операций используется специальный символ для разделения (рис. а) и слияния (рис. б)

Слайд 85Диаграммы деятельности в моделировании бизнес-процессов
Для моделирования Б-ПР в языке UML

используется специальная конструкция, получившее название дорожки (swimlanes). Имеется в виду

визуальная аналогия с плавательными дорожками в бассейне, если смотреть на соответствующую диаграмму. При этом все состояния действия на диаграмме деятельности делятся на отдельные группы, которые отделяются друг от друга вертикальными линиями. Две соседние линии и образуют дорожку, а группа состояний между этими линиями выполняется отдельным подразделением (отделом, группой, отделением, филиалом) компании
Диаграммы деятельности в моделировании бизнес-процессовДля моделирования Б-ПР в языке UML используется специальная конструкция, получившее название дорожки (swimlanes).

Слайд 86В общем случае действия на диаграмме деятельности выполняются над теми

или иными объектами. Эти объекты либо инициируют выполнение действий, либо

определяют некоторый результат этих действий.
Для графического представления объектов используются прямоугольник где имя объекта подчеркивается. Далее после имени может указываться характеристика состояния объекта в прямых скобках. Такие прямоугольники объектов присоединяются к состояниям действия отношением зависимости пунктирной линией со стрелкой.
Соответствующая зависимость определяет состояние конкретного объекта после выполнения предшествующего действия.

В общем случае действия на диаграмме деятельности выполняются над теми или иными объектами. Эти объекты либо инициируют

Слайд 87Состояние действия (action state) является специальным случаем состояния с некоторым

входным действием и, по крайней мере, одним выходящим из состояния

переходом. Этот переход неявно предполагает, что входное действие уже завершилось. Графически состояние действия изображается прямоугольником с закругленными углами
Состояние действия (action state) является специальным случаем состояния с некоторым входным действием и, по крайней мере, одним

Слайд 88
Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное

состояния.

Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния.

Слайд 89Переход как элемент языка UML переводит деятельность в последующее состояние

сразу, как только закончится действие в предыдущем состоянии.
На диаграмме

такой переход изображается сплошной линией со стрелкой.

Переход как элемент языка UML переводит деятельность в последующее состояние сразу, как только закончится действие в предыдущем

Слайд 90Поток объектов. Объекты, которые являются входными или выходными данными для

какого-либо действия, можно изображать в виде символов-объектов. Такой символ представляет

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

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

компании являются отдел приема и оформления заказов, отдел продаж и

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

Слайд 92Центральным объектом процесса продажи является заказ или вернее состояние его

выполнения.
Вначале до звонка от клиента заказ как объект отсутствует

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

Слайд 98Упражнение
Построить UML Диаграммы ПО, автоматизирующего процесс покупки товара в книжном

магазине.


Диаграмма ВИ (системный уровень)
Диаграмма последовательности для одного из вариантов использования


УпражнениеПостроить UML Диаграммы ПО, автоматизирующего процесс покупки товара в книжном магазине.Диаграмма ВИ (системный уровень)Диаграмма последовательности для одного

Слайд 99Исходные данные
На данный момент книжный магазин «Букварь» не имеет никакой

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

торгового зала и ассортимента книг. На сегодняшний день имеется зал со стеллажами. Книги по жанрам разделены на отделы, такие как «Детективы», «Классическая литература», «Кулинария», «Книги для детей» и т.д., в каждой отделе находится консультант, который помогает клиентам найти интересующую книгу, полагаясь только на свою память. Клиент, получая книгу, следует к кассе. Кассир узнает стоимость товара по «стикеру» наклеенному на книгу. Оплата производится только наличными.
Исходные данные		На данный момент книжный магазин «Букварь» не имеет никакой информационной системы. Потребность в ней появилась в

Слайд 100Проблемы
Консультант может забыть о наличии какой-либо книги. Он должен быть

в курсе всех новых поступлений и местонахождении книг, что при

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

Слайд 101Решения
Книжный магазин «Букварь» имеет потребность в информационной системе, которая бы

выполняла следующие функции:
Слежение за количеством товара; Формирование каталога; Формирование чека; Запись и хранение

данных о продаже; Авторизация платежа. Каждая книга будет иметь свой идентификационный номер, который равен штрих-коду.
Кассир будет сканировать сканером штрих-код, на экране появится номер книги, автор, цена согласно каталогу книг. Система сама сформирует чек, а так же запишет данные о продаже. Оплата будет возможна как наличным так и безналичным платежом. Так же в зале будут располагаться терминалы, которыми будут пользоваться консультанты. Вход будет запаролен. С помощью этого терминала консультанты смогут просматривать полный каталог книг, выполнять поиск и фильтрацию по разным критериям. В этом каталоге книги будут «разбиты» по жанрам, аналогично отделам. В каталоге будет храниться полная характеристика каждой книги (Издательство, год и т.д.), номер стеллажа и полки, а так же количество оставшегося товара. 
Решения		Книжный магазин «Букварь» имеет потребность в информационной системе, которая бы выполняла следующие функции:	Слежение за количеством товара; Формирование

Слайд 102Цель
Совершенствование бизнеса. Улучшение качества обслуживания клиентов. Сокращение времени расчета с покупателем. Минимизация ошибок

вызванных человеческим фактором. Использовать данную систему будут консультанты и кассиры магазина. Система

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

Слайд 103подсказка
- Кассир  - Покупатель - Консультант - Банк (который принимает платеж по

карточке)

подсказка	- Кассир  - Покупатель - Консультант  - Банк (который принимает платеж по карточке)

Слайд 104Модель сущность-связь

Модель сущность-связь

Слайд 105ДАЛЕЕ ДЛЯ ДО

ДАЛЕЕ ДЛЯ ДО

Слайд 106Архитектура ПО

Архитектура ПО

Слайд 107Управление требованиями

Управление требованиями

Обратная связь

Если не удалось найти и скачать доклад-презентацию, Вы можете заказать его на нашем сайте. Мы постараемся найти нужный Вам материал и отправим по электронной почте. Не стесняйтесь обращаться к нам, если у вас возникли вопросы или пожелания:

Email: Нажмите что бы посмотреть 

Что такое TheSlide.ru?

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


Для правообладателей

Яндекс.Метрика