- •Ответы на вопросы по дисциплине «Технология программирования».
- •1.Жизненный цикл программного обеспечения. Каскадная модель. Спиральная модель.
- •3. Управление разработкой программного средства.
- •5. Понятие программного модуля и его основные характеристики.
- •7. Формирование пользовательского интерфейса в среде программирования Lazarus.
- •9. Виды документации программного средства.
- •11. Прототипирование и исследовательское программирование. Отличия.
- •13. Понятие программного средства. Понятие технологии программирования.
- •17. Функциональная спецификация программного средства.
- •15. Автономная отладка и тестирование программного средства.
- •19. Надежность программного средства.
- •21. Способы разработки определения требований к программному средству.
- •23. Табличный подход к спецификации функций. Метод таблиц решений. Алгебраический подход для определения функций.
- •25. Архитектура программного средства. Понятие модульности программного средства. Расширяемость.
- •29. Системы быстрой разработки приложений(rad). Особенности.
- •31. Диаграммы деятельности и коопераций, диаграммы состояний.
- •32. Эволюция технологий программирования.
- •33. Спецификация качества программного средства.
- •35. Внешнее описание программного средства. Руководство разработчика и руководство пользователя.
- •37. Case-технологии разработки программного средства.
- •40. Тестирование по методам «черного» и «белого» ящиков. Этапы тестирования.
- •41. Разработка технического задания. Требования к содержанию.
31. Диаграммы деятельности и коопераций, диаграммы состояний.
Представление деятельности является вариантом конечного автомата, в котором показаны длительные вычислительные деятельности. Деятельность представляет собой поток работ или выполнение операций. Представление деятельности отображает как последовательные, так и параллельные виды деятельности.
Изображаются такие модели на диаграммах деятельности.
Диаграмма деятельности отражает реальные потоки работ в человеческой организации. Такое бизнес-моделирование и есть основное ее назначение. С таким же успехом ее можно использовать и при моделировании работы программного приложения.
Диаграмма деятельности может оказаться полезной и для понимания поведения системы. При ее использовании не нужно указывать детали реализации, такие, например, как сообщения, которыми обмениваются объекты и которые необходимо отображать на диаграмме кооперации.
На диаграмме кооперации представлены объекты и связи между ними. Объекты и их связи имеют значение только в контексте определенного взаимодействия, причем объект описывается ролью-классификатором, а связь внутри кооперации -- ролью-ассоциацией.
Диаграмма кооперации служит для моделирования взаимодействия объектов в системе, однако каждая диаграмма имеет свою специфику. В диаграмме кооперации, главный акцент сделан на отображении отношений между ролями и связанных с ними сообщений.
32. Эволюция технологий программирования.
Первый этап — «стихийное» программирование.
Первые программы имели простейшую структуру. Они состояли из собственно программы на машинном языке и обрабатываемых ею данных.
Создание языков программирования высокого уровня, таких как FORTRAN и ALGOL, существенно упростило программирование вычислений, снизив уровень детализации операций. Это, в свою очередь, позволило увеличить сложность программ. Революционным было появление в языках средств, позволяющих оперировать подпрограммами. Подпрограммы можно было сохранять и использовать в других программах. В результате были созданы огромные библиотеки расчетных и служебных подпрограмм, которые по мере надобности вызывались из разрабатываемой программы. Типичная программа того времени состояла из основной программы, области глобальных данных и набора подпрограмм (в основном библиотечных), выполняющих обработку всех данных или их части. Слабым местом такой архитектуры было то, что при увеличении количества подпрограмм возрастала вероятность искажения части глобальных данных какой-либо подпрограммой. Чтобы сократить количество ошибок в подпрограммах, было предложено размещать локальные данные.
Второй этап — структурный подход к программированию (60—70-е годы XX в.).
В основе структурного подхода лежит декомпозиция (разбиение на части) сложных систем с целью последующей реализации в виде отдельных небольших (до 40—50 операторов) подпрограмм. С появлением других принципов декомпозиции (объектного, логического и т. д.) данный способ получил название процедурной декомпозиции. Поддержка принципов структурного программирования была заложена в основу так называемых процедурных языков программирования. Среди наиболее известных языков этой группы - PL/1, ALGOL-68, Pascal, С.
Модульное программирование предполагает выделение групп подпрограмм, использующих одни и те же глобальные данные в отдельно компилируемые модули (библиотеки подпрограмм), например модуль графических ресурсов, модуль подпрограмм вывода на принтер. Связи между модулями при использовании данной технологии осуществляются через специальный интерфейс, в то время как доступ к реализации модуля (телам подпрограмм и некоторым «внутренним» переменным) запрещен. Использование модульного программирования существенно упростило разработку программного обеспечения несколькими программистами.
Третий этап — объектный подход к программированию (с середины 80-х до конца 90-х годов XX в.). Объектно-ориентированное программирование определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений. Основными достоинствами ООП по сравнению с модульным программированием является «более естественная» декомпозиция ПО, более полная локализация данных и интеграция их с подпрограммами обработки, что позволяет вести практически независимую разработку отдельных частей (объектов), новые способы организации программ, основанные на механизмах наследования, полиморфизма, композиции, наполнения.
Четвертый этап — компонентный подход и CASE-технологии (с середины 90-х годов XX в. до нашего времени).
Компонентный подход предполагает построение ПО из отдельных компонентов физически отдельно существующих частей ПО, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы.
Компонентная объектная модель (СОМ - Component Object Model) — фундамент компонентно-ориентированных средств для всего семейства операционных систем Windows.
СОМ определяет стандартный механизм, с помощью которого одна часть программного обеспечения предоставляет свои услуги другой части. Общая архитектура предоставления услуг в библиотеках, приложениях, системном и сетевом программном обеспечении позволяет СОМ изменить подход к созданию программ.
СОМ устанавливает понятия и правила, необходимые для определения объектов и интерфейсов; кроме того, в ее состав входят программы, реализующие ключевые функции.
В СОМ любая часть ПО реализует свои услуги с помощью объектов СОМ. Каждый объект СОМ поддерживает несколько интерфейсов. Клиенты могут получить доступ к услугам объекта СОМ только через вызовы операций его интерфейсов — у них нет непосредственного доступа к данным объекта.
