ИГА_сети_ЭВМ_и_ТК. Хранения информации для коллективного пользования

• Название: Хранения информации для коллективного пользования
• Дата: 05.04.2022
• Размер: 0.88 Mb.
• Имя файла: ИГА_сети_ЭВМ_и_ТК.doc
• Тип: Документы; #445243
• страница: 6 из 7

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

Встроенные в систему реализации – все решения по проектированию и реализации

привязаны к выбранной СУБД;

Независимые от системы реализации – все решения по проектированию ориентирова-ны на унификацию начальных этапов ЖЦ и средств их документирования, обеспечивают большую гибкость в выборе средств реализации.
Классификация по типам отражает функциональную ориентацию средств на разные процессы ЖЦ разработки ПО:
 средства анализа для построения и анализа модели предметной области;
 средства проектирования БД и файлов;
 средства разработки приложений;
 средства сопровождения и реинжиниринга;
 средства планирования и управления проектом;
 средства тестирования;
 средства документирования.

Классификация по категориям определяет степень интегрированности по выполняемым функциям и включают:

 отдельные локальные средства (решение небольших автономных задач),

 частично интегрированные средства (охватывают большинство этапов ЖЦ),

 полностью интегрированные средства (охватывают весь ЖЦ ИС).

CASE-средства можно классифицировать и по таким признакам:
 применяемым методологиям и моделям систем и БД;
 степени интегрированности с СУБД;
 доступным платформам.
55. Размерно-ориентированные метрики.
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках (Lines Of Code).
LOC-оценка – это количество строк в программном продукте.

Эти метрики не универсальны и спорны, особенно это относится к такому показателю как LOC, который существенно зависит от используемого языка программирования.
Регистрируются следующие показатели:
- общие затраты (чел/мес);
- объем программного изделия (тысячи строк исходного кода);
- стоимость разработки;
- объем документации (стр.);
- ошибки, обнаруженные в течение первого года эксплуатации (число);
- число людей, работавших над изделием;
- срок разработки (месяцы).

На основе перечисленных показателей вычисляются:

производительность

качество

удельная стоимость

документированность
Достоинства:

1) широко распространены;

2) просты и легко вычисляются.
Недостатки:

1) зависимы от языка программирования;

2) требуют исходных данных, которые трудно получить на начальной стадии проекта;

3) не приспособлены к непроцедурным языкам программирования.

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

 Количественные метрики (количество строк кода, среднее число строк, количество операторов, присваивания значений) – определяют уровень качества программирования, сложности и информационного содержания программ, трудоемкости кодирования и др.

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

 Метрики сложности потока данных (использование, конфигурация, размещение дан-ных в программе) – оценивается исходный текст.
 Комбинированные метрики сложности управления и данных (число символов, глу-бина вложенности, связность данных и др.) – оценивают сложность программы при про-ектировании и реализации на ЯВУ.

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


57. Документирование программ.
Постоянное документирование должно составлять неотъемлемую часть каждого шага про-граммирования, что облегчается сам процесс программирования. Каждая стадия должна завершаться составле­нием соответствующих документов.

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

Разработку ПС начинают с составления пер­вичных спецификаций, которые в ходе выпол-нения проекта постепенно претерпевают изменения до про­граммных документов этапов и до документации по эксплуатации и сопровождению программы.

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

Внешние спецификации включают спецификации входных и вы­ходных данных, их орга-низацию, реакции на исключительные ситуации, определение действий человека (по каким алгоритмам он работает и откуда берет информацию) и машины. Эти спецификации силь-но зависят от ЖЦ программы.

Внутренние спецификации включают описание внутренних данных программы и алго-ритмов частей и всей программы, что облегчает чтение кода.
Описание программы – описывает программу с точки зрения её разработки, необходима для изучения того, как она сконструирована.

Руководство пользователя – объясняет пользователям их действия по взаимодействию с программой (руководство по установке программы).
Учебное пособие – учит пользователя применять новую программу;

Справочное руководство –знакомит с описанием команд ПО.

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

Построение оптимальной программы алгоритмически не разрешима, поэтому:

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

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

контекстных условий – проверка некоторых свойств собранной информации;

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

Цель тестирования (испытания программы) – выявление имеющихся в ней ошибок.

Цель отладки – выявление и устранение причин ошибок.
Отладку программы начинают с составления плана тестирования, основываясь на понятии об источниках и характере ошибок.

План тестирования включает:

Сравнение программы со схемой алгоритма

Визуальный контроль программы

Трансляция программы на машинных языках

Редактирование внешних связей и компоновка программы

Выполнение программы

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

Контрольные тесты – это специально подобранные задачи, результаты которых заранее известны или могут быть определены без существенных затрат:

Выбор исходных данных для легкого вычисления результатов вручную или калькулятором

Использование результатов других ЭВМ или программ.

Использование знаний о физической природе процесса.
Программные ошибки делятся на три вида:

Синтаксическая ошибка – ошибки в записи конструкций языка программирования (чисел, переменных, функций, выражений, операторов, меток).

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

Логическая ошибка – нарушение логики программы, приводящее к неверному результату

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

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

60. Источники и классификация ошибок.
Ошибка – состояние программы, при котором выдаются неправильные результаты, причи-ной которых являются изъяны в операторах программы или в технологическом процессе ее разработки, что приводит к неправильной интерпретации исходной информации и к невер-ному решению.
Источники:

Ошибки процесса разработки проекта, компонентов, кода и документации;

Недоработки при определении требований, проекта, генерации кода или документации;

Ошибки процесса разработки программы или интерфейсов ее элементов;

Непонимание требований заказчика;

Неточная спецификация требований в документах проекта;

Изменение синтаксиса и семантики описания системы командой разработчиков системы.
Классификация:

логические и функциональные ошибки (нарушение логики алгоритма, правил программи-рования, определения функций и их применения и др.);

ошибки вычислений и времени выполнения (неточности исходных данных, формул и т.д.);

ошибки ввода-вывода и манипулирования данными (некачественные данные);

ошибки интерфейсов (взаимосвязи отдельных элементов друг с другом);

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

Объекты содержат инкапсулированные данные и процедуры и, следовательно, ограничива-ют к ним доступ. Под процессом ООП подразумевается проектирование классов объектов и взаимоотношений между этими классами. Изменение реализации какого-нибудь объекта или добавление новых функций не влияет на другие объекты системы.
Основные понятия ООП включают:

— основные компоненты – независимые объекты со своими состояниями и операциями;

— определяются классы объектов, предоставляющих сервисы другим объектам;

— объекты реализуются последовательно и параллельно;

— создаются различные модели: статические (классов, обобщения, агрегирования) и дина-мические (последовательностей, конечного автомата);

— важное преимущество – упрощен процесс модификации системы.
Использование методов ООП строго регламентировано, поэтому:

— возрастает производительность труда разработчиков;

— запросы и объекты реального мира проще моделируются;

— компоненты системы легко изменяются и применяются повторно;

— требования отслеживаются проще;

— поддерживается эффективное прототипирование;

— разработка проекта отличается непрерывностью в представлении объектов;

— работа по проектированию осуществляется с помощью универсальных технологических инструментов.
ООП является частью объектно-ориентированного процесса разработки системы и состоит из трех этапов: ООП-анализ, ООП-проектирование и ООП-программирование, которые могут «перетекать» друг в друга.

ООП отображает предметную область задачи и ответственности системы, но задерживает определение подробностей реализации объектов, переносит их на более поздний этап раз-работки и минимизирует влияние изменений в функциональных требованиях.
При ООП основное внимание уделяется тому, что следует делать, каким образом добиться цели, а процесс ее достижения зависит от этапа разработки. Использование объектного подхода повышает уровень унификации разработки и пригодность для повторного ис-пользования не только программных компонентов, но и больших комплексов программ, что ведет к созданию унифицированной среды разработки и переходу к сборочному созда-нию программных продуктов.
62. Язык UML.
UML (унифицированный язык моделирования) – язык графического описания для объект-ного моделирования в области разработки ПО. Это стандарт для визуального представле-ния моделей программ. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. Не является языком программиро-вания, но на основании UML-моделей возможна генерация кода.
Одна из основных диаграмм UML – диаграмма классов, описывающая классы и отражаю-щая отношения между ними. Модели программ – это графическое представление связей между объектами в программном коде.
Использование языка UML особенно эффективно в следующих областях:

ИС масштаба предприятия, банковские и финансовые услуги, телекоммуникации, тран-спорт, оборонная промышленность, авиация и космонавтика, розничная торговля, наука,

медицинская электроника, распределенные Web-системы.
В настоящее время язык UML получил широкое распространение в силу открытости сво-его стандарта и широкого профиля применимости. Сфера применения UML не ограничива-ется моделированием программного обеспечения. Его выразительность позволяет модели-ровать, документооборот в юридических системах, структуру и функционирование систе-мы обслуживания пациентов в больницах, осущест-влять проектирование аппаратных средств.
63. Современные технологии проектирования приложений.
Компании-разработчики стремятся повысить продуктивность своей работы, сократить сро-ки вывода новых продуктов на рынок, контролировать расходы и быстро получать отдачу от инвестиций.

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

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