- •Сущность и актуальность дисциплины «Технологии программирования», основные понятия и определения дисциплины.
- •Жизненный цикл программного средства.
- •Модели жизненного цикла по.
- •Модель с промежуточным контролем
- •Спиральная модель
- •Спиральная или итерационная схема разработки программного обеспечения
- •Изменение жизненного цикла программного обеспечения при использовании case-технологий.
- •Качество программного обеспечения.
- •Модели качества по
- •Метрики качества программного обеспечения.
- •Измерение и оценка качества по, стандартный метод оценки значений показателей качества.
- •Управление качеством пс.
- •Требования стандарта к организации системы качества
- •Диалоговые программы, типы диалога, формы диалога.
- •Спецификация пс.
- •Определение требований к программному средству.
- •Спецификация качества программного средства.
- •Функциональная спецификация программного средства.
- •Методы контроля внешнего описания программного средства.
- •Способы записи алгоритмов.
- •Представление основных структур алгоритмов.
- •Псевдокоды.
- •Flow-формы.
- •Диаграммы Насси-Шнейдермана.
- •Классификация структур данных.
- •Файловые структуры, физическая организация файлов.
- •Логическая организация файлов.
- •Документирование файлов.
- •Модульные программы, модули и их свойства.
- •Сцепление и связность модулей.
- •Нисходящая и восходящая разработка программного обеспечения.
- •Программирование «с защитой от ошибок».
- •Основные подходы программирования, «стихийное» программирование.
- •Основные подходы программирования, структурный подход к программированию.
- •Основные подходы программирования, объектный подход к программированию.
- •Основные подходы программирования, компонентный подход и case-технологии.
- •36. Процедурное (императивное) программирование
- •37.Функциональное программирование.
- •38. Декларативное программирование
- •39. Объектно-ориентированное программирование
- •40.Объектно-ориентированные языки программирования.
- •41. Спецификация программного обеспечения при структурном подходе.
- •42.Диаграммы переходов состояний.
- •43. Функциональные диаграммы
- •44. Диаграмма потоков данных
- •45. Моделирование управляющих процессов с помощью диаграмм потоков данных
- •46. Структуры данных и диаграммы отношений компонентов данных
- •47. Диаграммы Джексона.
- •48. Скобочные диаграммы Орра
- •49. Сетевая модель данных
- •50. Проектирование программного обеспечения при структурном подходе
- •54. Метод пошаговой детализации для проектирования структуры по
- •55. Структурные карты Констайна.
- •56. Проектирование структур данных
- •57. Представление данных в оперативной памят
- •60. Проектирование программного обеспечения, основанное на декомпозиции данных Методикой Варнье-Орра
- •61. Case-технологии, основанные на структурных методологиях анализа и проектирования
- •63. Определение «вариантов использования»
- •64. Диаграммы вариантов использования
- •65. Построение концептуальной модели предметной области
- •69. Проектирование программного обеспечения при объектном подходе
- •70. Разработка структуры программного обеспечения при объектном подходе
- •Определение отношений между объектами.
- •Диаграммы последовательностей этапа проектирования.
- •Диаграммы кооперации.
- •Уточнение отношений классов.
- •Интерфейсы в uml.
- •Проектирование классов.
- •Проектирование методов класса.
- •Компоновка программных компонентов.
- •Проектирование размещения программных компонентов для распределенных программных систем.
- •Методы доказательства правильности программ.
- •Метод индуктивных утверждений Флойда.
- •Метод Хора доказательства правильности программ.
- •Виды контроля качества разрабатываемого программного обеспечения.
- •Формирование тестовых наборов, основные подходы.
- •Ручной контроль программного обеспечения, методы ручного контроля.
- •I. Контроль обращений к данным
- •2. Контроль вычислений
- •3. Контроль передачи управления
- •4. Контроль межмодульных интерфейсов
- •Структурное тестирование, критерии формирования тестовых наборов.
- •Функциональное тестирование, методы формирования тестовых наборов.
- •Тестирование модулей и комплексное тестирование.
- •Оценочное тестирование.
- •Отладка программного обеспечения.
- •Классификация ошибок программного обеспечения.
- •Методы отладки программного обеспечения.
- •Методы и средства получения дополнительной информации об ошибках.
- •Общая методика отладки программного обеспечения.
- •Документирование и стандартизация.
- •Виды программных документов.
- •Основные правила оформления программной документации.
- •Основные инженерные подходы к созданию программ.
- •Классификация технологических подходов к созданию программ.
- •Классификация технологических подходов к созданию программ, подходы со слабой формализацией.
- •Классификация технологических подходов к созданию программ, строгие каскадные подходы.
- •Классификация технологических подходов к созданию программ, строгие каркасные подходы.
- •Классификация технологических подходов к созданию программ, генетические подходы.
- •Классификация технологических подходов к созданию программ, подходы на основе формальных преобразований.
- •Классификация технологических подходов к созданию программ, ранние подходы быстрой разработки.
- •Классификация технологических подходов к созданию программ, адаптивные технологические подходы.
- •Классификация технологических подходов к созданию программ, подходы исследовательского программирования.
- •Особенности и компоненты case-средств.
- •Объектно-ориентированные case-средства анализа и проектирования.
- •Структурные case-средства анализа и проектирования.
- •Case-средства компании ibm Rational Software, средство визуального моделирования Rational Rose.
- •Системы автоматизированного проектирования и их место среди других автоматизированных систем.
- •Структура сапр.
- •Разновидности сапр.
- •Понятие о cals-технологиях.
48. Скобочные диаграммы Орра
Диаграмма Орра базируется на том же предположении о сходстве структур программ и данных, что и диаграмма Джексона. Отличие состоит лишь в нотации. Автор предлагает для представления конструкций данных использовать фигурные скобки (рис. 11.24).
Рис 11.23. Пример описания конструкции, в которой повторение встречается один или более раз
Рис. 11.24. Скобочная нотация для представления структур данных Орра: а – последовательность; б – выбор; в – повторение
49. Сетевая модель данных
Сетевые модели данных используют в тех случаях, если отношение между компонентами данных не исчерпываются включением. Для графического представления разновидностей этой модели используют несколько нотаций. Наиболее известны из них следующие: нотация П. Чена; нотация Р. Баркера; нотация IDEF1 (более современный вариант этой нотации – IDEF1X используется в CASE-системах, например, в системе ERWin).
Базовыми понятиями сетевой модели данных являются: сущность, атрибут и связь.
Сущность — реальный или воображаемый объект, имеющий существенное значение для рассматриваемой предметной области.
Каждая сущность должна: иметь уникальное имя; обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь; обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности.
Первичный ключ – это атрибут или совокупность атрибутов и/или связей, предназначенная для уникальной идентификации каждого экземпляра сущности (совокупность признаков, позволяющих идентифицировать объект).
Связь – поименованная ассоциация между двумя или более сущностями, значимая для рассматриваемой предметной области. Связь, таким образом, означает, что каждый экземпляр одной сущности ассоциирован с произвольным (в том числе и нулевым) количеством экземпляров второй сущности и наоборот. Если любой экземпляр одной сущности связан хотя бы с одним экземпляром другой сущности, то связь является обязательной
Различают три типа отношений: 1х1, 1хМ, МхМ. Кроме того, сущности бывают независимыми, зависимыми и ассоциированными.
Независимая сущность представляет независимые данные, которые всегда присутствуют в системе. Они могут быть связаны или не связаны с другими сущностями той же системы.
Зависимая сущность представляет данные, зависящие от других сущностей системы, поэтому она всегда должна быть связана с другими сущностями.
Ассоциированная сущность представляет данные, которые ассоциируются с отношениями между двумя и более сущностями.
50. Проектирование программного обеспечения при структурном подходе
сущность структурного подхода заключается в декомпозиции программы или программной системы по функциональному принципу. Все предлагаемые методы декомпозиции используют интерфейсы простейшего типа: примитивные интерфейсы и традиционные меню, и рассчитаны на анализ и проектирование, как структур данных, так и обрабатывающих их программ.
Причем в большинстве случаев первичным считают проектирование обрабатывающих компонентов, проектирование же структур данных выполняют параллельно. Существует и альтернативный подход, при котором первичным считают проектирование данных, а обрабатывающие программы получают, анализируя полученные структуры данных.
В любом случае проектирование программного обеспечения начинают с определения его структуры.
51. Разработка структурной и функциональной схем
Процесс проектирования сложного программного обеспечения начинают с уточнения его структуры, т. е. определения структурных компонентов и связей между ними. Результат уточнения структуры может быть представлен в виде структурной и/или функциональной схем и описания (спецификаций) компонентов.
52. Структурная схема разрабатываемого программного обеспечения
Структурной называют схему, отражающую состав и взаимодействие по управлению частей разрабатываемого программного обеспечения.
Структурные схемы пакетов программ не информативны, поскольку организация программ в пакеты не предусматривает передачи управления между ними. Поэтому структурные схемы разрабатывают для каждой программы пакета, а список программ пакета определяют, анализируя функции, указанные в техническом задании.
Самый простой вид программного обеспечения – программа, которая в качестве структурных компонентов может включать только подпрограммы и библиотеки ресурсов. Разработку структурной схемы программы обычно выполняют методом пошаговой детализации.
Структурными компонентами программной системы или программного комплекса могут служить программы, подсистемы, базы данных, библиотеки ресурсов и т. п.
Структурная схема программной системы, как правило, показывает наличие подсистем или других структурных компонентов. В отличие от программного комплекса отдельные части (подсистемы) программной системы интенсивно обмениваются данными между собой и, возможно, с основной программой. Структурная же схема программной системы этого обычно не показывает.
53. Функциональная схема
Функциональная схема или схема данных – схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом. Основные обозначения схем данных по ГОСТ 19. 701-90 приведены в табл. 12. 1.
Функциональные схемы, более информативны, чем структурные. На рис. 12. 3 для сравнения приведены функциональные схемы программных комплексов и систем.
Все компоненты структурных и функциональных схем должны быть описаны. При структурном подходе особенно тщательно необходимо прорабатывать спецификации межпрограммных интерфейсов, так как от качества их описания зависит количество самых дорогостоящих ошибок. К самым дорогим относятся ошибки, обнаруживаемые при комплексном тестировании, так как для их устранения могут потребоваться серьезные изменения уже отлаженных текстов.