Презентация Введение в Программную Инженерию онлайн

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

Содержание слайда: Отчет о хаосе The Standish Group International, “CHAOS Report”

Содержание слайда:

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

Содержание слайда:

Содержание слайда:

Содержание слайда:

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

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

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

Содержание слайда: software engineering (программная инженерия) - впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по науке и технике. Рассматривались проблемы проектирования, разработки, распространения и поддержки программ. - некоторая дисциплина, которую надо создавать и которой надо руководствоваться в решении перечисленных проблем.

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

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

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

Содержание слайда: Согласно 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 — качество программного обеспечения.

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

Содержание слайда:

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

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

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

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

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

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

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

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

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

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

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

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

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

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

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

Содержание слайда: Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны: Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны: Метод структурного анализа и проектирования Том ДеМарко (1978), Метод объектно-ориентированного анализа Буч (1994), Рамбо (1991). Метод сущность-связь проектирования информационных систем Чен (1976)

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

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

Содержание слайда:

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

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

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

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

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

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

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

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

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

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

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

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

Содержание слайда:

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

Содержание слайда:

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

Содержание слайда:

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

Содержание слайда:

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

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

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

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

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

Содержание слайда:

Содержание слайда:

Содержание слайда:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

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

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

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

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

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

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

Содержание слайда: Модель сущность-связь

Содержание слайда: ДАЛЕЕ ДЛЯ ДО

Содержание слайда: Архитектура ПО

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