- •Каскадная модель
- •Mодели разработки ПО
- •Инкрементная модель
- •пример
- •пример
- •2 этап Разработка ПО
- •проектирование
- •пример
- •Диаграммы классов
- •диаграммы
- •Отношения между классами
- •Отношения между классами
- •Кратность ассоциации
- •Отношения между классами
- •Проектирование
- •Дополнительные отношения между классами
- •Связи
- •Состав Case-систем
- •паттерны
- •пример
- •пример
- •пример
- •работа
- •тестирование
- •тестирование
- •Недостаки UML
- •Use case
- •Диаграмма деятельности
- •Диаграмма деятельности
- •Тестирование мобильных приложений
- •Тестирование мобильных приложений
- •тестирование Android Studio
- •типы мобильных приложений
- •интерфейс приложения может выглядеть по разному в разных типах приложений
- •типы мобильных приложений
- •Типы мобильных приложений
- •особенности тестирования мобильных приложений
- •особенности тестирования мобильных приложений
- •мобильные приложения
- •Инструменты для тестирования мобильных приложений
- •Инструменты для тестирования мобильных приложений
- •Тестирование API
- •Postman
- •Postman
- •Тестирование API
- •Postman
- •Postman
- •Postman
- •Postman
- •Postman
- •Postman
- •Postman
- •спецификация
- •спецификация
- •Примеры спецификации примеры
- •Спецификация(упрощенный вариант)
- •пример тест-кейса
- •методики
- •проектирование
Каскадная модель
Недостатки :
Каскадная модель не допускает смешивание этапов разработки поэтому;
Не готова быть гибкой (гибкость необходима т.к. невозможно предусмотреть все сложности.
В результате потеряно время и средства.
Второй недостаток: заказчик не задействован на этапах разработки и тестирования, т.е. заказчику предоставляется только конечный результат.
(хотя часто требуется чтобы заказчик комментировал работу и участвовал в работе.)
Третий недостаток; обнаружение проблем только после этапа тестирования
Mодели разработки ПО
Инкрементная модель
Инкрементная модель – функциональность программного продукта разбивается на инкременты.
Каждый инкремент представляет полноценную версию продукта.
Каждый инкремент разрабатывается и тестируется независимо от других инкрементов.
В конце каждой итерации производиться интеграция новых функций.
Инкрементная модель работает с итерационной моделью.
1.Сначала определяется объем проекта, требования и риски .
2.Разработка рабочей архитектуры.
3.Построение дополнительных архитектур.
4.Постепенный переход в производствееную среду.
пример
пример
2 этап Разработка ПО
Применение CASE –средств
CASE (COMPUTER Aided Software/System Engineering) –означает автоматизированное проектирование программ/информационных систем .
Большинство информационных систем похожи друг на друга.
Напр. складские базы данных электронных товаров и базы данных книгоизданий и т.д.
Информационные системы управления доступом предприятия и организации.
Такие системы похожи или по функциям или по решаемыми ими задач.
Поэтому возникла идея (в 90-е годы) автоматизации проектирования информационных систем и ПО.
ER
ER – диаграммы предназначены для создания моделей (логической модели ) БД.
Для проектирования моделей БД часто используется редактор Drow.io
проектирование
При построении диаграммы классов часто используется редактор Visual Paradigm (cкачать
Community версию)
Диаграммы классов «Сущность – связь»
Сущность – т.е. существительное – обозначает объект работник , банк и т.д. (класс )
Каждая сущность имеет атрибут.(атрибуты класса)
Рассмотрим пример Заказ (сущность): номер заказа , цена закза
Внизу : указываются методы (действия): отправить , закрыть (методы или операции класса)
пример
Диаграммы классов
В верхней части прямоугольника указывается имя сущности
Каждая сущность имеет атрибуты. Индентификаторы появляются в начале списка атрибутов. Первичный индентификатор является основным (напр. Фамилия и обозначается <1> )
Остальные индентификаторы – являются альтернативными.
Служащий
<1> Фамилия
Номер ГНИ Код организационно-правовой формы
Код вида деятельности