- •Питання для підготовки до семестрового іспиту Спеціальність: 5.05010301 «Розробка програмного забезпечення»
- •Загальні відомості про стандарт swebok
- •1. Основы программных требований (Software Requirements)
- •2. Проектирование по (Software design)
- •3. Конструирование по (Software Construction)
- •4. Тестирование по (Software Testing)
- •5. Сопровождение по (Software maintenance)
- •6. Управление конфигурацией по (Software Configuration Management-scm)
- •7. Управление инженерией по (Software Engineering Management)
- •8. Процесс инженерии по (Software Engineering Process)
- •9. Методы и средства инженерии по (Software Engineering Tools and Methods)
- •10. Качество по (Software Quality)
- •Стандарт 12207: процеси життєвого циклу програмного забезпечення
- •Каскадна модель життєвого циклу програмного забезпечення
- •Інкрементна модель життєвого циклу програмного забезпечення
- •Спіральна модель життєвого циклу програмного забезпечення
- •Важковагові та полегшені процеси розробки програмного забезпечення
- •Види вимог
- •Аналіз та збирання вимог
- •Верифікація та формалізація вимог
- •Об’єктно-орієнтована інженерія вимог
- •Метод інженерії вимог а. Джекобсона
- •Визначення об’єктів в моделі аналізу вимог
- •Трасування та атрибути вимог
- •Перевірка та вимірювання вимог
- •Основні поняття аналізу предметної області
- •Метод аналіз та побудови моделей с. Шлаер та с. Меллора
- •Методи проектування архітектури пз
- •Структурний підхід до проектування
- •Об’єктно-орієнтований підхід до проектування
- •Методи моделювання uml
- •Предмети в uml
- •Відношення в uml
- •24. Діаграми в uml
- •Діаграми класів в uml
- •Діаграми схем станів
- •Діаграми діяльності
- •Діаграми взаємодії
- •Діаграми співробітництва
- •Діаграми послідовності
- •Діаграми Use Case
- •Діаграми об’єктів в uml
- •Основи конструювання
- •Стандарти конструювання програмного забезпечення
- •Моделі конструювання програмного забезпечення
- •Планування конструювання
- •Проектування в конструюванні
- •Статичні методи тестування програм
- •Динамічні методи тестування програм
- •Функціональне тестування програм
- •Організація підготовки тестів
- •Команда тестувальників
- •Організація процесу тестування
- •Модель якості програмного забезпечення
- •5). Сопровождаемость
- •Стандартний метод оцінки значень показників якості
- •Керування якістю програмного забезпечення
- •Моделі оцінки надійності
- •Методи керування проектами
- •Планування проекту
- •Організаційні аспекти керування в проекті
- •Оцінка проекту
- •Методи керування ризиками
- •Керування конфігурацією програмної системи
- •Проблеми організації документування
- •Формування вимог до документації
- •Планування документування проектів
- •Керування спеціалістами при документуванні
- •Документообіг в життєвому циклі
- •Стандарти, що регламентують документування програмних проектів
- •Стандарти, що регламентують експлуатаційну документацію
Об’єктно-орієнтований підхід до проектування
Объектно-ориентированное проектирование (ООП) представляет собой стратегию, в рамках которой разработчики системы вместо операций и функций мыслят в понятиях объектов. Объект - это нечто, способное пребывать в различных состояниях и имеющее определенное множество операций. Состояние определяется как набор атрибутов объекта. Операции, связанные с объектом, предоставляют сервисы другим объектам (клиентам) для выполнения определенных вычислений.
Объекты создаются в соответствии с определением класса объектов, который служит шаблоном для создания объектов. В него включены описания всех атрибутов и операций, связанных с объектом данного класса.
Программная система состоит из взаимодействующих объектов, которые имеют собственное локальное состояние и могут выполнять набор операций, определяемый состоянием объекта. Объекты скрывают информацию о представлении состояний и ограничивают к ним доступ.
Под процессом объектно-ориентированного проектирования подразумевается проектирование классов объектов и взаимоотношений между этими классами. Когда проект реализован в виде исполняемой программы, все необходимые объекты создаются динамически с помощью определений классов. Этот подход подразумевает выполнение трёх этапов при проектировании:
1. Объектно-ориентированный анализ. Создание объектно-ориентированной модели предметной области приложения. Здесь объекты отражают реальные объекты-сущности и операции, выполняемые этими объектами.
2. Объектно-ориентированное проектирование. Разработка объектно-ориентированной модели системы ПО (системной архитектуры) с учётом требований. В этой модели определение всех объектов подчинено решению конкретной задачи.
3. Объектно-ориентированное программирование. Реализация архитектуры (модели) системы с помощью объектно-ориентированного языка программирования (С++, Java) для определения объектов и средств определения классов объектов.
Данные этапы могут "перетекать" друг в друга, т.е. они могут не иметь четких рамок и на каждом этапе применяется одна и та же система нотации. Переход к следующему этапу приводит к усовершенствованию результатов предыдущего этапа путём более детального описания определенных ранее классов объектов и определения новых классов.
Объектно-ориентированные системы можно рассматривать как совокупность автономных и независимых объектов. Изменение реализации какого-нибудь объекта или добавление ему новых функций не влияет на другие объекты системы. Четкое соответствие между реальными объектами (например, аппаратными средствами) и управляющими объектами программной системы облегчает понимание и реализацию проекта.
Объекты могут быть повторно используемыми компонентами, они независимо инкапсулируют данные о состоянии и операциях. Архитектуру ПО можно разрабатывать проект на базе объектов, ранее созданных в предыдущих проектах. Это снижает стоимость проектирования, программирования и тестирования ПО. Кроме того, возможность использования стандартных объектов уменьшает риск, связанный с разработкой ПО.
Модель окружения системы и модель использования системы представляют собой две взаимно дополняющие друг друга модели взаимоотношений системы и с ее средой:
Модель окружения системы - это статическая модель, которая описывает другие системы из пространства разрабатываемого ПО. Модель использования системы – динамическая модель, которая показывает взаимодействие данной системы со своим окружением (средой).
Когда взаимодействия между проектируемой системой ПО и ее окружением определены, эти данные можно использовать как основу для разработки архитектуры системы. При этом необходимо применять знания об общих принципах проектирования системных архитектур и данные о конкретной предметной области.
Существует два типа моделей системной архитектуры:
- статические модели, которые описывают статическую структуру системы в терминах классов объектов и взаимоотношений между ними. Основными взаимоотношениями, которые документируются на данном этапе, являются отношения обобщения, отношения «используют-используются» и структурные отношения.
- динамические модели, которые описывают динамическую структуру системы и показывают взаимодействия между объектами системы (но не классами объектов).
Документируемые взаимодействия содержат последовательность запросов к сервисам объектов и описывают реакцию системы на взаимодействия между объектами.
Язык моделирования UML поддерживает большое количество возможных статических и динамических моделей, в том числе модель подсистем и модель последовательностей. Модель последовательностей — одна из наиболее полезных и наглядных моделей, которая в каждом узле взаимодействия документирует последовательность происходящих взаимодействий между объектами.