Файл: Лекции на специальности спо базовой подготовки 09. 02. 07 Информационные системы и программирование Ульяновск.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.05.2024
Просмотров: 88
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
| МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ДЛЯ СТУДЕНТОВ | Ульяновский авиационный колледж |
| ПРОФЕССИОНАЛЬНЫЙ ЦИКЛ | |
| Разработка программных модулей ЛЕКЦИИ на специальности СПО базовой подготовки 09.02.07 Информационные системы и программирование Ульяновск 2021 |
| | |
| ОДОБРЕНО на заседании ЦМК программирования и ИТ Протокол № __ от «__» ______20___ г. Председатель ЦМК: _________________ А.А. Шарифуллина | УТВЕРЖДАЮ Зам. директора по учебной работе _______________ Г.В. Знаенко «_____» __________ 20_____ г. |
| РАЗРАБОТЧИК: Кякшта М.А., преподаватель информационных дисциплин Ульяновского авиационного колледжа. | |
Содержание
Введение………………………………………………………………………….6
Тема 1 Разработка программного обеспечения………………………………..7
Понятие ЖЦ ПО…………………………………………………………………7
Компонентно-ориентированный подход при разработке ПО………………..8
Этапы разработки ПО…………………………………………………………..9
Тема 2 Структурное программирование………………………………………11
Структурное программирование……………………………………………….11
Тема 3 Объектно-ориентированное программирование……………………..12
Объективно-ориентированное программирование…………………………..12
Тема 4 Событийно-управляемое программирование…………………………14
Основные принципы событийно-управляемого программирования………...14
Элементы управления………………………..…………………………………15
Диалоговые окна. ……………………………………………………………….16
Обработчики событий…………………………………………………………..18
Введение в графику……………………………………………………………..19
Тема 5 Модульный принцип разработки ПО…………………………………20
Основные критерии оптимизации модулей…………………………………..20
Информационная закрытость. Связность. Виды связности…………………22
Сцепление. Типы сцепления…………………………………………………..24
Тема 6 Основы работы с базами данных……………………………………..25
Специальные библиотеки……………………………………………………..25
Базовый синтаксис SQL……………………………………………………….26
Создание таблицы, работа с данными………………………………………..27
Python DB-API модули………………………………………………………...29
Объектно-реляционное отображение (ORM)……………………………..31
Тема 7 Разработка пользовательского интерфейса……………………….33
Правила разработки интерфейсов пользователя………………………….33
Требования к интерфейсу…………………………………………………..34
Анализ интерфейса…………………………………………………………36
Тема 8 Архитектурные шаблоны в проектировании……………………..38
Назначение и виды паттернов……………………………………………...38
Порождающие паттерны Abstract Factory, Builder, Factory method……..39
Порождающие паттерны: Prototype, Singleton……………………………41
Структурные паттерны: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy ……………………………………………………………42
Поведенческие паттерны: Iterator, Observer, State, Strategy, Visitor, Template method………………………………………………………………………44
Поведенческие паттерны: Chain of Responsibility, Memento, Command, Mediator ……………………………………………………………………45
Тема 9 Конструирование ПО………………………………………………46
Рефакторинг. Определение, причины и цели. Приемы рефакторинга….46
Составление методов. ……………………………………………………..48
Перемещение функции между методами…………………………………49
Организация данных. ………………………………………………………51
Упрощение условных выражений………………………………………….53
Упрощение вызовов методов. ……………………………………………..55
Решение задач обобщения………………………………………………….57
Экстремальное программирование………………………………………..59
Тестирование. Виды, задачи……………………………………………….60
Модульные тесты. Интеграционные тесты……………………………….61
Регрессионное тестирование. Нагрузочное тестирование………………63
Стандарты оформления кода…………………………………………….65
Тема 10 Проведение изменений в ПО……………………………………67
Обратный инжиниринг. Определение, цели проведения……………….67
Этапы обратного инжиниринга……………………………………………68
Анализ исходных данных………………………………………………….70
Получение экспертиз. Реверсивный инжиниринг……………………….71
Методики проведения обратного инжиниринга…………………………73
Оформление кода…………………………………………………………..74
Реинжиниринг………………………………………………………………75
Анализ интерфейса…………………………………………………………77
Список использованных источников………………………………………..78
Введение
Программная инженерия является отраслью информатики, которая изучает вопросы построения компьютерных программ, отражает закономерности развития программирования, обобщает опыт программирования в виде комплекса знаний и правил регламентации инженерной деятельности разработчиков ПС.
Международным комитетом при американском объединении компьютерных специалистов ACM (Association for Computing Machinery) и институте инженеров по электронике и электротехнике IEEE было создано ядро знаний SWEBOK (Software Engineering Body of Knowledge) (2001, 2003 гг.).
В этом ядре были систематизированы разнородные знания в области программирования, планирования и управления, сформулировано понятие программной инженерии и областей, которые соответствуют процессам проектирования ПС и методам их поддержки.
Программная инженерия охватывает все аспекты создания ПС, начиная от
формирования требований до создания, сопровождения и снятия с эксплуатации, а также включает инженерные методы оценки трудозатрат, стоимости, производительности и качества.
Кроме программистов, занимающихся непосредственно разработкой ПС, в программной инженерии задействованы:
менеджеры, которые планируют и руководят проектом, отслеживают сроки его исполнения и затраты;
инженеры службы ведения библиотек и репозитариев компонентов;
технологи, которые определяют инженерные методы и стандарты, создают для проекта модель жизненного цикла ПС, удовлетворяющую его
целям и задачам;
тестировщики, которые проверяют правильность выполнения процесса разработки ПС путем тестирования, и на основе собранных данных проводят измерения характеристик качества;
валидаторы, которые проверяют ПС на соответствие заданным требованиям (в технике валидация подтверждает, что требования пользователя
удовлетворены);
верификаторы, которые проверяют правильность реализации алгоритмов и программ в проекте путем их сопоставления с эталонными данными, алгоритмами или программами (верификация — это внутренний процесс управления качеством, обеспечивающий согласование с правилами или спецификацией).
Тема 1 Разработка программного обеспечения
Понятие ЖЦ ПО.
Создание любого программного средства выполняется по некоторой схеме. Данная схема представляет собой последовательность стандартных этапов производственного процесса. Этот процесс нужно спланировать, оценить его ресурсы. В ходе реализации этого процесса нужно: спроектировать ПС в виде системы, состоящей из компонент; описать функции этих компонент и их связи между собой; запрограммировать эти компоненты, автономно их отладить, собрать вместе и провести комплексную отладку; подготовить документацию на ПС; обучить пользователей; провести опытную эксплуатацию ПС; организовать сопровождение системы.
Для сокращения затрат необходимо конкретизировать схему, упорядочить
действия, выполняемые на каждом этапе, разработать методы решения
возникающих на разных этапах проблем. В довершение ко всему, схема
подразумевает возвраты назад (циклы), в тех случаях, когда обнаруживаются
ошибки предыдущего этапа.
Под жизненным циклом программного средства (ЖЦПС) понимают весь
период его разработки и эксплуатации, начиная от момента возникновения
замысла ПС и кончая прекращением его использования. В настоящее время
можно выделить пять основных подходов к организации процесса создания и
использования ПС.
Компонентно-ориентированный подход при разработке ПО
ООП-подход в разработке ПО хорошо себя зарекомендовал. Инкапсуляция, наследование и полиморфизм помогают программисту повторно использовать функциональность базового класса и скрыть детали реализации. Но при разработке сложных систем, особенно систем, моделирующих процессы окружающего мира, ООП-программист сталкивается с рядом новых проблем, для решения которых необходим принципиально иной подход.
Главное отличие компонента от объекта заключается в том, что компонент функционирует в среде как часть единой системы – «фреймворка». Фреймворк предоставляет унифицированный способ доступа к ресурсам среды в рамках компонентной модели. Под средой (или окружением) обычно понимается среда выполнения — вычислительное окружение, необходимое для выполнения программы. В конечном итоге компонент взаимодействует как с операционной системой/виртуальной машиной, так и с пользователем, БД, периферийными устройствами и прочими объектами реального мира, используя возможности фреймворка. В контексте жизненного цикла разработки ПО, под средой также может пониматься среда разработки, среда выполнения и т.п.
Компонент может рассматриваться как объект, к которому предъявлен ряд дополнительных требований для функционирования в сложных средах с элементами неопределенности. Базовый класс компонента должен содержать всю необходимую функциональность, которая позволяет называть компонент компонентом.
Если жизненный цикл объекта в ООП, как правило, известен заранее вплоть до мельчайших деталей еще на этапе разработки архитектуры системы, то компоненты, являющиеся частью сложной системы, могут инициировать взаимодействие друг с другом в различное время «по требованию». При этом они изначально могут ничего не знать друг о друге — на этапе написания компонента программист ограничен возможностями компонентной модели. Поэтому компоненты должны уметь динамически «обрабатывать» события и обмениваться информацией о своих свойствах и умениях с другими компонентами.
Вот некоторые особенности, в той или иной мере присущие компонентно-ориентированному программированию:
-
интроспективность (способность компонентов к самоописанию), -
модульность и разграничение уровней доступа, -
автоматическая обработка исключительных ситуаций, -
автоматическое управление памятью, -
позднее связывание и динамический контроль типов, обработка событий, -
персистентность (способность компонентов сохранять и восстанавливать состояние), -
простота повторного использования.
Компоненты могут представлять сущности моделируемой системы, ресурсы среды (предоставлять доступ к файловой системе, базам данных), управлять рабочим потоком, предназначаться для выполнения определенных задач.
Этапы разработки ПО.
Разработка любой программысостоит из нескольких этапов, грамотная реализация которых является обязательным условием для получения хорошего результата.
Анализ требований
В рамках этой стадии происходит максимально эффективное взаимодействие нуждающегося в программном решении клиента и сотрудников компании-разработчика, в ходе обсуждения деталей проекта помогающих более четко сформулировать предъявляемые к ПО требования. Результатом проведенного анализа становится формирование основного регламента, на который будет опираться исполнитель в своей работе — технического задания на разработку программного обеспечения. ТЗ должно полностью описывать поставленные перед разработчиком задачи и охарактеризовать конечную цель проекта в понимании заказчика.
