
- •4.Дайте определение табл реш. Приведите пример.*
- •10. Приведите пример и дайте пояснения редуцирования табл реш для какой-либо внешней спецификации.*
- •7.Дайте определение спецификациям по, назовите известные Вам внешние спецификации и их особенности. Приведите пример спецификации.*
- •6.Дайте определение нотации. Приведите пример.*
- •11. Назовите нотации и приведите пример нотации для изображения стр-ных алгоритмов.*
- •8. Назовите группы симв, к-е исп в схемах проектов по согласно гост, и приведите примеры таких Симов. *
- •13. Дайте определение сцепления мод и приведите примеры мод с разными видами сцепления.*
- •16. Блочно-иерархический подход к созд-ю прог-ных систем.*
- •31. Принципы моДного прог-ирования.* *
- •14.Дайте определение технологии прог-ирования. Какие технологии Вы знаете и к каким периодам относится появление этих технологий? *
- •28. Стихийное прог-ирование. Этапы совершенствования архитектуры прог-.*
- •14.Дайте определение технологии прог-ирования. Какие технологии Вы знаете и к каким периодам относится появление этих технологий? *
- •28. Стихийное прог-ирование. Этапы совершенствования архитектуры прог-.*
- •32. Основные понятия объектно-ориентированного прог-ирования.*
- •33. Достоинства и недостатки объектно-ориентированного прог-ирования.*
- •27. Пошаговое тест-ие моДных прог-. Достоинства и недостатки подходов.*
- •30. Нисходящая стратегия разработки прог-.*
- •27. Пошаговое тест-ие моДных прог-. Достоинства и недостатки подходов.*
- •30. Нисходящая стратегия разработки прог-.*
- •22. Ручной контроль как метод тест-ия.* *
- •23. Методы стр-ного тест-ия. Общий недостаток методов.* //белый ящик
- •24. Методы ф-онального тест-ия. Области применения.* //черный ящик
- •25. Основные положения метода эквивалентного разбиения.*
- •1.Назовите цель разбиения исх-х д-х прог- на классы эквивалентности. Приведите пример выделения классов эквивалентности для какой-либо задачи * *
- •26. Основные положения метода граничных значений.*
- •2.Дайте определение стр-ы д-х. Приведите пример стр-ы д-х. Дайте пояснения относительно ее частей.*
- •17. Проблемы разработки сложных прог-ных систем.*
- •34. Case-технологии как результат эволюционного развития инструментальных средств.*
- •35. Сравнение этапов жизн-ого цикла в case-технологиях и при традиционной разработке по.*
- •34. Case-технологии как результат эволюционного развития инструментальных средств.*
- •35. Сравнение этапов жизн-ого цикла в case-технологиях и при традиционной разработке по.*
17. Проблемы разработки сложных прог-ных систем.*
Большинство современных прог-ных систем объективно очень сложны. Эта сложность обуславливается многими причинами, главной из которых явл-я логическая сложность решаемых ими задач.
Пока вычислительных установок было мало и возможности были ограничены, ЭВМ применяли в очень узких областях науки и техники, причем, в первую очередь, там, где решаемые задачи были хорошо детерминированы и требовали значительных вычислений. В наше время, когда созданы мощные компьютерные сети, появилась возможность переложить на них реш сложных ресурсоемких задач, о компьютеризации к-х раньше никто я не думал. Сейчас в процесс компьютеризации вовлекаются совершенно новые предметные области, а для уже освоенных областей усложняются уже сложившиеся постановки задач.
Доп факторами, увелич-ми сложность разработки прог-ных систем, явл:
• сложность формального определения требований к прог-ным систм;
• отсутствие удовлетворительных средств описания поведения дискретных систем с большим числом состояний при недетерминированной послед-ости входных воздействий;
• коллективная разработка;
• необходимость увеличения степени повторяемости кодов.
34. Case-технологии как результат эволюционного развития инструментальных средств.*
35. Сравнение этапов жизн-ого цикла в case-технологиях и при традиционной разработке по.*
34. Case-технологии как результат эволюционного развития инструментальных средств.*
CASE-систми или CASE-технологиями наз-этот реализованные в виде прог-ных продуктов технологические сист, ориентированные на созд-е сложных прог-ных систем и поддержку их полного жизн-ого цикла или его основных этапов. В настоящее время CASE-технологии прочно вошли в практику прог-ной индустрии. При этом они исп не только для производства ПП, но и как мощный инструмент реш исследовательских и проектных задач. Такие задачи включают стр-ный анализ предметной области, моделирование деловых предложений с целью реш задач оперативного и стратегического планирования и управ ресурсами - тех видов деятельности, на к-й в России в ближайшее время ожидается большой спрос.
CASE-технологии явл естественным продолжением эволюции всей отрасли разработки ПО. Традиционно выделяют 6 периодов, качественно отличающихся применяемой техникой и методами разработки ПО.
В качестве инструментальных средств в эти периоды использовались:
ассемблеры, дампы памяти, анализаторы;
компиляторы, интерпретаторы, трассировщики;
Симические отладчики, пакеты прог-;
сист анализа и управ исх-ми текстами;
CASE-средства анализа требований, проектирования спецификаций и стр-ы, редактирования интерфейсов (1-ая генерация CASE-1);
CASE-средства генерации исх-х текстов и реализации интегрированного окружения поддержки полного ЖЦ разработки ПО (2-ая генерация CASE-II).
Таким образом, CASE-средства явл результатом естественного эволюционного развития отрасли инструментальных (или технологических) средств. CASE-технологии начали развиваться с целью преодоления ограничений методологии стр-ного прог-ирования. Эта методология, несмотря на формализацию в составлении прог-, характ-ется все же сложностью понимания, большой трудоемкостью и стоимостью использования, трудностью внесения изменений в проектные спецификации. Однако заложенные в ней принципы позволили развивать эту методологию и повысить ее эффективность за счет автоматизации наиболее рутинных этапов. Напомню, что автоматизация рутинных работ возможна только в случае их формализации. Формализация в стр-ном прог-ировании оказалась наиболее приемлемой для автоматизации.
CASE обладают следующими основными достоинствами:
улучшают качество создаваемого ПО за счет средств автоматического контроля, прежде всего, контроля проекта;
позволяют за короткое время создавать прототип будущей сист, давая возможность на ранних этапах оценить ожидаемый результат;
ускоряют процесс проектирования и разработки;
позволяют разработчику > времени уделять творческой работе по созд-ю ПО, освобождая его от рутинной работы;
поддерживают развитие и сопровождение разработки (заметим, что этот аспект не затрагивался ни одной из рассмотренных нами технологий прог-ирования);
поддерживают технологии повторного использования компонент разработки).