Базовые принципы разработки программ (их описание)

Базовые принципы разработки программ (их описание)

- Модульный - разработка модульного программирования основана на использовании структурных методов проектирования, целью которого является разбиение программы на компоненты.

- Объектно-ориентированный – основан на анализе проектировании и программировании объектов.

Программный модуль, программный продукт, система, нотация

Программный продукт – программное обеспечение и соответствующая документация, предназначенные для поставки пользователю.

Система – комплекс, состоящий из процессов, технических и программных средств, устройств и персонала, обладающих возможностью удовлетворять установленным потребностям или целям.

Нотация – система графических обозначений для записи результата разработки программных средств.

4. Жизненный цикл программных средств. Группы процессов жизненного цикла (определения) - – совокупность процессов работ и задач, охватывающих их жизнь от формирования концепции до прекращения использования. Каждый процесс ЖЦ разделен на набор работ. Каждая работа разделена на набор задач. Делятся на основные, вспомогательные, организационные.

Группы процессов жизненного цикла:

1. процессы соглашения — 2;

2. процессы организационного обеспечения проекта — 5;

3. процессы проекта — 7;

4. технические процессы — 11;

5. процессы реализации программных средств — 7;

6. процессы поддержки программных средств — 8;

7. процессы повторного применения программных средств — 3.

5. Основные процессы жизненного цикла (определения). Работы, из которых состоит процесс разработки

- Приобретение (действия и задачи заказчика, приобретающего ПО)

- Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)

- Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)

- Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)

- Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение — внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.

Работы, из которых состоит процесс разработки:

· Анализ требований → Спецификация программного обеспечения

· Проектирование программного обеспечения

· Программирование

· Тестирование программного обеспечения

· Системная интеграция (Systemintegration)

· Внедрение программного обеспечения (или Установка программного обеспечения)

· Сопровождение программного обеспечения

Базовые стратегии разработки ПО

· Каскадная

· Инкрементная

· Эволюционная

Каскадная стратегия разработки программных средств и систем (понятие, достоинства и и недостатки)

Каскадная стратегия разработки программных средств и систем – однократный проход этапов разработки.

Достоинства:

· Стабильность требований в течении ЖЦ

· Необходимость только одного прохода этапов разработки, это обеспечивает простоту применения стратегии

· Простота планирования контроля и управления проектом

· Доступность для понимания заказчиков

Недостатки:

· Сложность полного формулирования требований

· Сложность структуры процесса разработки

· Непригодность промежуточных продуктов для использования

· Недостаточное участие пользователя в процессе разработки ПО

Инкрементная стратегия разработки программных средств и систем (понятие, достоинства и недостатки)

Инкрементная стратегия разработки программных средств и систем – многократный проход этапов разработки с запланированным улучшением результата. Результат каждого цикла –инкремент.

Достоинства:

· Получение функционального продукта на промежуточных этапах

· Короткая продолжительность создания инкремента

· Снижение рисков

· Включение в процесс пользователей

Недостатки

· Сложность планирования и распределения работ

· Проявление человеческого фактора

V-образная модель

Основной принцип V-образной модели заключается в том, что детализация проекта возрастает при движении слева направо, одновременно с течением времени, и ни то, ни другое не может повернуть вспять. Итерации в проекте производятся по горизонтали, между левой и правой сторонами буквы.

Недостатки

1) необходимость в постоянном участии пользователя в процессе разработки

2) необходимость в высококвалифицированных разработчиках

3) возможность применения только для систем или ПС, для которых отсутствует требование высокой производительности;

4) жесткость временных ограничений на разработку прототипа;

5) неприменимость в условиях высоких технических рисков, при использовании новых технологий.

Область применения

· если пользователь может принимать постоянное участие в процессе разработки;

· если в проекте заняты разработчики, обладающие достаточными навыками в использовании инструментальных средств разработки;

· при выполнении проектов в сокращенные сроки;

· при невысокой степени технических рисков;

· в составе других моделей жизненного цикла.

Эволюционная модель (выше)

Виды комментариев.

1) заголовки. Объясняют назначение основных компонентов

2) построчные. Описывают мелкие фрагменты программы;

3) вводные. Помещаются в начале текста программы и задают общую информацию о ней (назначение программы, сведения об авторах, дата написания, время выполнения, требуемый объем памяти).

Нормами комментариев.

• 4 - 5 строк комментария-заголовка на каждый компонент программы (подпрограмму, блок, модуль);

• по одному комментарию на каждые две строки исходного текста для построчных комментариев.

ESD-диаграмма

ESD-диаграмма представляет собой иерархию действий, выполняемых некоторой сущностью во времени. Сущности и действия на ESD-диаграмме представляются в виде прямоугольников. На каждой ESD-диаграмме имеется только одна сущность. Она помещается в корне дерева ESD-диаграммы.

Диаграммы Варнье–Орра

CASE-технологии

CASE-технология – это совокупность методологий разработки и сопровождения сложных систем (в том числе ПС), поддерживаемая комплексом взаимосвязанных средств автоматизации. Основные цели использования CASE-технологий при разработке ПС – отделить анализ и проектирование от программирования и последующих работ процесса разработки, предоставив разработчику соответствующие методологии визуального анализа и проектирования.

Основные понятия IDEF0-модели

Система -совокупность взаимодействующих компонентов и взаимосвязей между ними.

Моделирование - процесс создания точного описания системы.

Моделью IDEF0 - подразумевается графическое и текстовое представление результатов анализа предметной области, разработанное с определенной целью и с выбранной точки зрения и идентифицирующее функции системы.

Цель модели- назначение опсания.

Точка зрения – это позиция человека или объекта, в которую надо встать, чтобы увидеть систему в действии.

Субъектом моделирования является сама система.

Конечным результатом моделирования является набор тщательно взаимоувязанных описаний, начиная с описания самого верхнего уровня всей системы и кончая подробным описанием деталей или операций системы. Каждое из таких описаний называется диаграммой.

Виды диаграмм языка UML

Для моделирования различных аспектов предметной области или проектируемой системы в языке UML предусмотрены следующие виды диаграмм:

· диаграмма вариантов использования (UseCaseDiagram);

· диаграмма классов (ClassDiagram);

· диаграммы поведения (BehaviorDiagram), в том числе: диаграмма состояний (StatechartDiagram);

· диаграмма деятельности (ActivityDiagram);

· диаграммы взаимодействия (InteractionDiagram), в том числе: диаграмма последовательности (SequenceDiagram);

· диаграмма кооперации (CollaborationDiagram);

· диаграммы реализации (ImplementationDiagram), в том числе: диаграмма компонентов (ComponentDiagram);

· диаграмма развертывания (DeploymentDiagram)

Язык UML Модели языка UML

Язык UML – это язык визуального моделирования, позволяющий разрабатывать концептуальные, логические и физические модели сложных систем. Он предназначен для визуализации, анализа, спецификации, проектирования и документирования предметных областей, сложных систем вообще и ПС в частности.

Модели языка UML подразделяются на два вида: структурные модели (статические модели) описывают структуру сущностей предметной области или компонентов моделируемой системы, включая их классы, атрибуты, связи, интерфейсы; к данному виду моделей относятся диаграммы вариантов использования, классов, компонентов, развертывания; модели поведения (динамические модели) описывают функционирование сущностей предметной области или компонентов системы во времени, включая их методы, взаимодействия между ними, изменение состояний отдельных сущностей, компонентов и системы в целом; к данному виду моделей относятся диаграмма состояний, диаграмма деятельности, диаграмма последовательности, диаграмма кооперации.

Уровни моделей языка UML

Все модели языка UML подразделяются на три уровня:

· концептуальные модели представляют собой верхний, наиболее общий и абстрактный уровень описания моделируемой системы; к данному уровню относится диаграмма вариантов использования; с уровня концептуальной модели должно начинаться моделирование предметной области или проектируемой системы (программного средства);

· логические модели представляют собой второй уровень описания моделируемой системы; элементы моделей данного уровня не имеют физического воплощения и отражают логические аспекты структуры и поведения реальной предметной области или системы; логические модели должны строиться после концептуальных моделей; к данному уровню относятся диаграммы классов, состояний, деятельности, последовательности, кооперации;

· физические модели представляют собой нижний уровень описания моделируемой системы; элементы моделей данного уровня представляют собой 233 конкретные материальные сущности физической системы; данные модели рекомендуется строить в последнюю очередь; к данному уровню относятся диаграммы компонентов и развертывания.

61. Диаграмма вариантов использования

Диаграмма вариантов использования (UseCaseDiagram) определяет функциональное назначение моделируемой системы или предметной области. Данная диаграмма отображает множество актеров, взаимодействующих с проектируемой системой (программным средством) с помощью вариантов использования. Таким образом, основными элементами диаграммы вариантов использования являются актер и вариант использования.

Актер – это внешняя по отношению к моделируемой системе сущность, взаимодействующая с системой для решения некоторых задач. В качестве актера может использоваться человек, другая система, устройство или программное средство. Вариант использования определяет некоторый набор действий (операций), которые должны быть выполнены моделируемой системой или программным средством при взаимодействии с актером.

62. Виды отношений между элементами на диаграммах вариантов использования

На диаграммах вариантов использования определены следующие виды отношений между отдельными элементами:

· отношение ассоциации(определено для всех видов диаграмм языка UML. На диаграммах вариантов использования данное 238 отношение связывает актеров с вариантами использования и определяет конкретную роль актера при взаимодействии с вариантом использования);

· отношение включения(может иметь место между двумя вариантами использования. Данное отношение определяет, что последовательность действий одного варианта использования (включаемого) включается в качестве составной части в последовательность действий другого варианта использования (базового));

· отношение расширения(может существовать между двумя вариантами использования. Данное отношение определяет, что некоторый вариант использования является расширением для другого варианта использования (базового). Это означает, что последовательность действий базового варианта использования может быть дополнена последовательностью действий варианта-расширения);

· отношение обобщения(может существовать как между актерами, так и между вариантами использования. Данное отношение определяет, что некоторая сущность А является специализацией сущности В. 240 В этом случае сущность А называется потомком сущности В (дочерней сущностью), а сущность В – предком сущности А (родительской сущностью). При этом дочерние варианты использования наследуют свойства и поведение вари- антов-предков и могут наделяться новыми свойствами и поведением. Актеры- потомки наследуют все роли актеров-предков).

Отработка стратегий

Следующий уровень планирования — стратегический план. Он отвечает на вопросы что? И когда? При этом, чем более конкретна цель, тем более своеобразны будут стратегии ее достижения.

Документы обзоров

Документы обзоров

Документы обзоров ЖЦПИ

Фаза	Обзор событий		Вопросы
1.исследования	Ресурсы распределения	1,2	1. Распределение бюджета 2. Извещение о сроках 3. Согласование о требованиях 4. Спецификации 5. Издание документации 6. План испытаний 7. План поддержки 8. Отчеты 9. План выпуска 10. Конфигуратор
2.анализ осуществимости	Требование утверждения	1, 2, 3, 9, 10
3.конструирование	Спецификации утверждения	1, 2, 4, 5, 6
4.программирование	Испытания начаты	1, 2, 8
5.оценка	Распределение начато	2, 8, 9, 10
6.исполнение	Изделие снято с производства

Базовые принципы разработки программ (их описание)

- Модульный - разработка модульного программирования основана на использовании структурных методов проектирования, целью которого является разбиение программы на компоненты.

- Объектно-ориентированный – основан на анализе проектировании и программировании объектов.