Программная инженерия

неделю
Курсовое проектирование: консультации
Зачет
Экзамен

англ. – М.: Издательский дом
"Вильямс", 2002. – 624 с.
Дана широкая

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

3-е изд., дополненное / Пер. с англ. — М. :

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

проектирования (3-е издание). Вильямс 2006. — 736 стр .
В

книге рассматриваются основные принципы и приемы объектно-ориентированного анализа и проектирования (ООА/П). В ней содержатся сведения об итеративном и гибком моделировании, шаблонах проектирования, архитектурном анализе и многих других вопросах. Весь материал рассматривается в контексте гибкого подхода к разработке с совместным применением процесса UP и других итеративных методов. Книга будет хорошим руководством для всех, кто интересуется вопросами ООА/П, языком моделирования UML 2 и современными эволюционными подходами к разработке программного обеспечения.

Петербург, 2007, с. 576 Рассмотрена современная технология объектно риентированного анализа и

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

Питер Серия: Классика Computer Science 2006 г., с. 736
Эта книга

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

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

измеримого подхода к разработке, функционированию и сопровождению программного обеспечения, а также исследованию этих подходов; то есть, приложение дисциплины инженерии к программному обеспечению (ISO/IEC/IEEE 24765:2017)

SWEBOK)

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

и проектирования
Язык UML предоставляет стандартный способ написания проектной документации на системы

Group: http://www.omg.org
Текущая версия стандарта, доступная для свободного скачивания, UML 2.5.1:
https://www.omg.org/spec/UML/2.5.1/PDF
UML

2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2.

— система условных обозначений (нотация) для моделирования бизнес-процессов.
Последняя версия стандарта

— BPMN 2.0.2 (январь 2014).

работы:
1. Концепция проекта, которая отражает в краткой форме все составляющие

проекта.
2. Технико-экономическое обоснование проекта
3. Требования к проекту (Use case документ)
4. Описание содержания проекта, которое содержит описание работ, которые предстоит выполнить, и результатов поставки.
5. План реализации проекта.
6. Описание проекта
7. Тест-план

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

для решения конкретных практических задач.
Требование определяется как некое свойство ПО, необходимое пользователю для решения проблемы при достижении поставленной цели;
“Условие или возможность, которое система должна выполнять или поддерживать”.

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

анализ предметной области.
Анализ требований — систематизация требований. Определение, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; выявление взаимосвязи требований.
Документирование требований — требования могут быть в различных формах, таких как простое описание, сценарии использования, пользовательские истории.
Специфицирование требований.
Управление требованиями.

срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования

обычно формулируются заказчиком.
Пользовательские требования (Пользовательские потребности). (User Requirement Specification - URS) Описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на нее. Ориентированы на заказчика ПО (руководство и специалисты организации – заказчика, пользователи)
Специфицированные требования (или просто требования) (Software Requirement Specification - SRS). Детализированное описание системных функций и ограничений. Системные требования служат основой для контракта между заказчиком и разработчиком. Ориентированы на заказчика и разработчика (специалисты разработчика и исполнителя)

с помощью методики основанной на вариантах использования.
В рамках этой методики

разрабатываются:
1. Диаграммы вариантов использования (Use Case диаграмма)
2. Сценарии вариантов использования
3. Создается Use Case документ

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

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

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

одного или нескольких актеров
Отвечает на вопрос «Что должна выполнять система?», не отвечая на вопрос «Как она должна выполнять это?»
Имена – отглагольное существительное или глагол в неопределенной форме

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

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

будут использовать систему
Кто будет получать пользу от использования системы
Кто будет

использовать информацию от системы
Будет ли использовать система внешние ресурсы
Может ли один пользователь играть несколько ролей при взаимодействии с системой
Могут ли различные пользователи играть одну роль при взаимодействии с системой
Будет ли система взаимодействовать с законодательными, исполнительными, налоговыми или другими органами

языке UML 2.х и может использоваться на различных канонических диаграммах

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

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

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

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

факта, что один элемент модели является специальным или частным случаем

другого элемента модели

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

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

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

и быстро ввести данные
Покупатель – хочет купить товары и быстро оформить покупку с минимальными усилиями. Хочет получить подтверждение факта покупки.
Компания – хочет оформить покупку и удовлетворить интересы покупателя
Налоговые службы – хотят получать налог с каждой продажи.
Триггер: покупатель подходит к кассовому аппарату с выбранными товарами.

товара и на основании каталога товаров и выдает его описание,

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

Сценарий варианта использования.

данного наименования товара
2б. В рамках одной категории существует несколько наименований

товара
2б1. Кассир может ввести идентификатор товара и количество единиц.
2в. Покупатель просит продавца отменить покупку одного из товаров
2в1. Кассир вводит идентификатор товара для удаления из продажи
2в2. Система отображает обновленную промежуточную стоимость.

Сценарий варианта использования.

использования.

Румбах)
Dr. Ivar Jacobson
Айвар Джекобсон
(Ивар Якобсон)
OMG (Object Management Group) — название

консорциума, созданного в 1989 году для разработки индустриальных стандартов с их последующим использованием в процессе создания масштабируемых неоднородных распределенных объектных сред.
Официальный сайт: www.omg.org

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

различного целевого назначения
Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области
Графическое представление моделей в нотации UML не должно зависеть от конкретных языков программирования и инструментальных средств проектирования
Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП
Способствовать распространению объектных технологий и поощрять развитие рынка программных инструментальных средств
Интегрировать в себя новейшие и наилучшие достижения практики ООАП

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

включая их классы, интерфейсы, атрибуты и отношения.
Модели поведения (behavioral models) – модели, предназначенные для описания процесса функционирования элементов системы, включая их методы и взаимодействие между ними, а также процесс изменения состояний отдельных элементов и системы в целом.