- •Абстаркция и абсттрагирование
- •Архитектура программной системы.
- •Объектно-ориентированный анализ
- •Объектно-ориентированное проектирование
- •Объектно-ориентированное программирование
- •Аналитическая модель
- •Алгоритмическая и объектно-ориентированная декомпозиция
- •Сложность программных систем. Основные причины, признаки сложной системы.
- •Понятие итеративного цикла разработки. Участники процесса разработки программного обеспечения.
- •Класс, объект. Состояние объекта. Поведение объекта.
- •Расширения uml: ограничения (constraint), стереотипы (stereotypes) и именованные
- •Агрегация и композиция. Их назначение и отличия
- •Понятие итеративного цикла разработки. Участники процесса разработки программного
- •Основные этапы разработки программного обеспечения (Анализ, проектирование,
- •Понятие стереотипов концептуальной модели (boundary, control, entity)
- •16. Язык um, назначение и структура языка uml. Визуальное моделирование
- •17. Интегрированная модель сложной системы
- •18. Модель системы в Rational Rose (Use Case View, Logical View, Component View, Deployment View)
- •Назначение диаграммы компонентов.
- •Диаграммы размещения (Deployment Diagram). Назначение, основные элементы (Processor, Device, Connection).
- •19. Анализ предметной области. Идентификация и систематизация функций системы. Атрибуты системы. Скрытые и типовые функции. Функции бизнес-логики
- •20. Модульность программной системы. Понятие и назначение Package. Отношения между Package. Организационные диаграммы.
- •21. Вариант использования (Use Case). Абстрактный вариант использования.
- •22. Диаграммы вариантов использования. Назначение. Основные элементы (Text Box, Use Case, Note, Anchor Note, Actor, Package)
- •23. Связи на диаграмме Вариантов Использования (Association, Unidirectional Association, Generalization, Extend use case, Include use case).
- •24. Сценарии use case. Описание (потоки событий) и назначение сценариев
- •25 Диаграммы деятельности. Назначение. Основные элементы (Activity, State, Start State, Stop State, State Transition, State to self, Synchronization, Decision, Swimlane)
- •26. Диаграммы последовательности (Sequence Diagram). Назначение, основные элементы (Object, Object Message, Message to Self) Соотнесение объектов с классами, сообщение с операциями.
- •27. Кооперативные диаграммы (Collaboration). Назначение, основные элементы (Object, Class Instance, Object Link, Link to Self, (Reverse) Link Message, (Reverse) Data Flow
- •28. Диаграммы классов (Class Diagram). Назначение, основные элементы (Class, Association, Dependency, Aggregation, Generalization). Атрибуты и операции, множественность (multiplicity) и роли
- •Назначение диаграммы вариантов использования (Use Case Diagram)
- •30. Диаграммы вариантов использования для моделирования предметной области. Назначение, основные элементы (Business Actor, Business Use Case, Association).
- •31. Назначение диаграммы компонентов
- •32. Диаграммы размещения (Deployment Diagram). Назначение, основные элементы (Processor, Device, Connection).
- •33. Последовательность разработки программной системы
- •34. Диаграммы анализа и проектирования
- •35. Основные задачи анализа. Функциональные и нефункциональные требования.
Понятие итеративного цикла разработки. Участники процесса разработки программного обеспечения.
Итеративный подход (англ. iteration - «повторение») в разработке программного обеспечения — это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл PDCA: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle).
Преимущества итеративного подхода:
снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;
организация эффективной обратной связи проектной команды с потребителем (а также заказчиками, стейкхолдерами) и создание продукта, реально отвечающего его потребностям;
акцент усилий на наиболее важные и критичные направления проекта;
непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;
раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;
более равномерная загрузка участников проекта;
эффективное использование накопленного опыта;
реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.
затраты распределяются по всему проекту, а не группируются в его конце[1].
Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна.
Когда оптимально использовать итеративную модель?
Требования к конечной системе заранее четко определены и понятны.
Проект большой или очень большой.
Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.
Участники процесса разработки ПО
Пользователь лицо или организация, которое используетдействующую систему для выполнения конкретной функции
Заказчик — лицо (физическое или юридическое), заинтересованноев выполнении исполнителем работ, оказании им услуг или приобретении у продавца какого-либо продукта (вшироком смысле). Иногда при этом предполагается оформление заказа, но не обязательно.
Разработчик,
Руководитель проекта,
Аналитик,
Тестировщик,
Поставщик
Класс, объект. Состояние объекта. Поведение объекта.
Класс (class) представляет собой абстракцию совокупности реальных объектов, которые имеют общий набор свойств и обладают одинаковым поведением.
Объект (object) – это некая сущность реального мира или концептуальная сущность с четко определенными границами. Каждый объект в системе имеет три характеристики: состояние, поведение и индивидуальность. Объект в контексте ООП рассматривается как экземпляр соответствующего класса.
Объекты, которые не имеют идентичных свойств или не обладают одинаковым поведением, по определению, не могут быть отнесены к одному классу.
Состоянием (state) объекта называется одно из условий, в которых он может находиться. Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (динамическими) значениями каждого из этих свойств – атрибуты (attribute) объекта
Поведение объекта (behavior) – определяет, как объект реагирует на запросы других объектов и что может делать сам объект.
Поведение объекта – это его наблюдаемая и проверяемая из вне деятельность. Поведение реализуется с помощью набора операций (operation) объекта.
Индивидуальность (identity) означает, что каждый объект уникален, даже если его состояние идентично состоянию другого объекта. Уникальность объекта реализуется в его имени: два разных объекта, принадлежащих одному классу не могут иметь одинаковое имя.
Качество классов
«Хороший» класс должен отражать только одну основную сущность. Названия классов выбирают в соответствии с понятиями предметной области. Имя класса должно быть существительным в единственном числе, наиболее точно характеризующем предмет.
«Хороший» класс должен содержать все необходимые атрибуты, характеризующие моделируемую сущность предметной области в контексте данного ПО и обладать необходимым и достаточным набором операций.
-
Модели классов объектно-ориентированного анализа
entity (сущность) – класс программной системы, отображение некой сущности предметной области. Основное назначение хранение данных.
bounary (граничный класс)- класс программной системы, представляющий интерфейс между внешним пользователем (actor) и программной системой.
control (менеджер)- класс программной системы, отображающий элементы управления.
Модель классов бизнес-анализа
business entity (бизнес-сущность) – класс бизнес-анализа, служит для моделирования предметной области.
Модель классов объектно-ориентированного программирования
класс проектирования- класс програмной системы, основной вид модели.
