Шпора ИСРП


ЭКЗАМЕНАЦИОННЫЕ ВОПРОСЫ ПО ИСРП
Rational Rose – инструмент логического проектирования программ.
UML – средства описания проекта на логической стадии разработки.
Базы данных. Основные понятия.
Базы знаний.
Виды инструментальных средств.
Диаграмма взаимодействия ПО, как способ выражение сценария ПО.
Диаграмма классов: структура, состав, связи.
Диаграмма компонентов для объектно-ориентированной системы и web-системы.
Диаграмма коопераций: определение, идеология, структура, пример.
Диаграмма последовательностей: определение, структура, состав, пример.
Диаграмма развертывания и архитектура ПО: сходство и отличие.
Диаграмма развертывания: назначение, структура, пример.
Диаграмма состояний: определение, назначение, структура, пример.
Идеологический смысл технического задания.
Инсталляция и установка программных систем – проблемы, пути решения, инструменты.
Инструментальные средства разработки программного обеспечения (ПО).
Информационный поиск. Модели поиска. Стратегии поиска.
История развития программного инструмента.
Качество ПО.
Классификация направлений программирования и их особенностей.
Классификация стандартов программирования.
Логическая форма графического описания взаимодействия активных объектов системы.
Методы разработки программы.
Моделирование программного обеспечения.
Модель данных "сущность–связь".
Модель: определение, классификация, пример.
Общие требования технического задания на разработку ПО.
Оптимизация программных продуктов – методы и инструменты.
Отличие идеологии разработки от цели разработки ПО.
Парадигмы связывания и видимости объектов – глобальные и локальные, статические и динамические, внутренние и внешние - методы и инструменты реализации.
Перспективы развития инструментальных средств.
Полнофункциональность и целостность ПО.
Понятие концептуальной, логической, физической структуры БД.
Понятие модели данных.
Последовательность действий при разработке программ.
Построение контекстной помощи – средства и методики.
Психологические особенности разработки ПО.
Разработка технического задания.
Реляционная модель данных.
Современное программирование – базовые понятия и инструменты.
Современные технологии разработки ПО.
Современные языки программирования ПО.
Специфические требования технического задания.
Сравнение возможностей пакетов программирования баз данных.
Сравнение возможностей систем управления базы данных.
Сравнение диаграммы деятельности и алгоритма работы программы.
Сравнение диаграммы классов и структуры базы данных.
Сравнение диаграммы объектов и диаграммы компонент.
Сравнения возможностей объектных языков программирования.
Тестирование и отладка ПО.
Технико-экономическое обоснование ПО.
Технические требования к разработке ПО.
Требования, предъявляемые к разработке ПО.
Файл - менеджеры – программы управления файлами при разработке – возможности и их наращивание, разнообразие и характеристики использования.
Целостность и защита данных. Структуры БД.
Экономические требования разработки ПО.
Этап выработки требований к программе - методы и инструменты.
Перспективы инструментальных средств

1.Rational Rose – инструмент логического проектирования программ.
Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации [21]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
Структура и функции
В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов.
В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ.
Репозиторий представляет собой объектно-ориентированную базу данных.
Средства просмотра обеспечивают "навигацию" по проекту, в том числе, перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д.
Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания.
Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации. Таким образом скелет программы может быть уточнен путем прямого программирования на языке С++.
Анализатор кодов С++ реализован в виде отдельного программного модуля. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран.
Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент.
В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:
диаграммы классов;
диаграммы состояний;
диаграммы сценариев;
диаграммы модулей;
диаграммы процессов;
спецификации классов, объектов, атрибутов и операций
заготовки текстов программ;
модель разрабатываемой программной системы.
2.UML – средства описания проекта на логической стадии разработки.
UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (англ. generalization), агрегация (англ. aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.
UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;
UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
UML получил широкое распространение и динамично развивается.
Структурные диаграммы:
Диаграмма классов
Диаграмма компонентов
Диаграмма композитной/составной структуры
Диаграмма кооперации (UML2.0)
Диаграмма развёртывания
Диаграмма объектов
Диаграмма пакетов
Диаграмма профилей (UML2.2)
Диаграммы поведения:
Диаграмма деятельности
Диаграмма состояний
Диаграмма вариантов использования
Диаграммы взаимодействия:
Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
Диаграмма обзора взаимодействия (UML2.0)
Диаграмма последовательности
Диаграмма синхронизации (UML2.0)
3.Базы данных. Основные понятия.
Реляционные базы данных - организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность логически связанных данных, характеризующая актуальное состояние некоторой предметной области и используемая для удовлетворения информационных потребностей пользователей.
Особенности БД
БД хранится и обрабатывается в вычислительной системе.
Данные в БД логически структурированы (систематизированы) с целью обеспечения возможности их эффективного поиска и обработки в вычислительной системе.Структурированность подразумевает явное выделение составных частей (элементов), связей между ними, а также типизацию элементов и связей, при которой с типом элемента (связи) соотносится определённая семантика и допустимые операции.
Информационную систему
рассматривают как программно-аппаратную систему, предназначенную для автоматизации целенаправленной деятельности конечных пользователей, обеспечивающую, в соответствии с заложенной в нее логикой обработки, возможность получения, модификации и хранения информации.
Основной задачей ИС является удовлетворение конкретных информационных потребностей в рамках конкретной предметной области. Современные ИС немыслимы без использования баз данных и СУБД.

Предметная область – это часть реального мира, подлежащая изучению с целью создания базы данных для автоматизации процесса управления.
Сущности – это базовые типы информации, которые хранятся в БД рассматриваемой предметной области (в реляционной БД каждой сущности назначается таблица).
Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности. В реляционной БД атрибуты хранятся в полях таблиц.Связь – взаимосвязь между сущностями в предметной области. Связи представляют собой соединения  между частями БД (в реляционной БД – это соединение между записями таблиц).
Справочник БД
- это абстрактный список (таблица), хранящий в себе некоторые "константные" значения (например, города, профессии, известные виды, типы и т. д.). На элементы этого списка могут ссылаться различные компоненты программы или данные в БД.
Для подключения справочников используется компонент:
DBLookUpComboBox Первичный ключ – это одно или несколько полей, комбинация значений которых однозначно определяет каждую запись в таблице. Первичный ключ не допускает значений Null и всегда должен иметь уникальный индекс. Внешний (вторичный) ключ - это одно или несколько полей (столбцов) в таблице, содержащих ссылку на поле или поля первичного ключа в другой таблице. Внешний ключ определяет способ объединения таблиц.
Ассоциативная таблица - промежуточная таблица, в которой хранятся пары вида «ключ, ключ» (где каждому ключу соответствует свое значение из другой таблицы) и поддерживающая операции добавления пары, а также поиска и удаления пары по ключу.
Применяется для организации связей «многие ко многим»!
4.Базы знаний.
База знаний в информатике и исследованиях искусственного интеллекта — это особого рода база данных, разработанная для оперирования знаниями (метаданными). База знаний содержит структурированную информацию, покрывающую некоторую область знаний, для использования кибернетическим устройством (или человеком) с конкретной целью. Современные базы знаний работают совместно с системами поиска информации, имеют классификационную структуру и формат представления знаний.
Простые базы знаний могут использоваться для создания экспертных систем хранения данных в организации: документации, руководств, статей технического обеспечения. Главная цель создания таких баз — помочь менее опытным людям найти уже существующее описание способа решения какой-либо проблемы.
Двумя наиболее важными требованиями к информации, хранящейся в базе знаний интеллектуальной системы, являются:
Достоверность конкретных и обобщённых сведений, имеющихся в базе данных;
Релевантность информации, получаемой с помощью правил вывода базы знаний.
Ниже перечислены некоторые из особенностей, которые могут (но не обязаны) быть у системы, оперирующей базами знаний.
Автоматическое доказательство (вывод). Способность системы выводить новые знания из старых, находить закономерности в БЗ.
Доказательство заключения. Способность системы после выдачи ответа «объяснить» ход её рассуждений, причем «по первому требованию».
Интроспекция. Нахождение противоречий, нестыковок в БЗ, контроль правильной организации БЗ.
Машинное обучение. Превращение БЗ в гибкую систему, адаптация к проблемной области. Аналогична человеческой способности «набирать опыт».
5. Виды инструментальных средств.
По своему назначению и функциональным возможностям инструментальные программы, применяемые при проектировании экспертных систем, можно разделить на четыре достаточно большие категории.
1)Оболочки экспертных систем
Системы этого типа создаются, как правило, на основе какой-нибудь экспертной системы, достаточно хорошо зарекомендовавшей себя на практике. При создании оболочки из системы-прототипа удаляются компоненты, слишком специфичные для области ее непосредственного применения, и оставляются те, которые не имеют узкой специализации. Примером может служить система EMYCIN, созданная на основе прошедшей длительную «обкатку» системы MYCIN
2) Языки программирования высокого уровня
Инструментальные средства этой категории избавляют разработчика от необходимости углубляться в детали реализации системы – способы эффективного распределения памяти, низкоуровневые процедуры доступа и манипулирования данными. Одним из наиболее известных представителей таких языков является OPS5. Этот язык прост в изучении и предоставляет программисту гораздо более широкие возможности, чем типичные специализированные оболочки.
3) Среда программирования, поддерживающая несколько парадигм
Средства этой категории включают несколько программных модулей, что позволяет пользователю комбинировать в процессе разработки экспертной системы разные стили программирования. Среди первых проектов такого рода была исследовательская программа LOOP, которая допускала использование двух типов представления знаний: базирующегося на системе правил и объектно-ориентированного. На основе этой архитектуры во второй половине 1980-х годов было разработано несколько коммерческих программных продуктов, из которых наибольшую известность получили KEE, KnowledgeCraft и ART
4) Дополнительные модули
Средства этой категории представляют собой автономные программные модули, предназначенные для выполнения специфических задач в рамках выбранной архитектуры системы решения проблем.
6. Диаграмма взаимодействия ПО, как способ выражение сценария ПО
Взаимодействие между объектами в системе представляются диаграммами взаимодействия (interaction diagrams). Диаграммы взаимодействия подразделяются на два основных типа диаграмм: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).
Как правило, диаграмма взаимодействия используется для описания поведения в рамках одного варианта использования. На такой диаграмме изображается ряд объектов и те сообщения, которыми они обмениваются в рамках этого варианта использования.
Диаграммы последовательности и кооперативные диаграммы несут в себе одну информацию, но выраженную разными способами. Диаграммы последовательности показывают взаимодействие объектов во времени и отражают последовательность происходящих событий. На диаграмме не отражаются связи между объектами. Кооперативные диаграммы позволяют пространственно располагать объекты, для того чтобы лучше представить взаимодействие между объектами. Временная последовательность передаваемых сообщений отражается при помощи нумерации сообщений.
Диаграмма взаимодействия предназначена для моделирования отношений между объектами (ролями, классами, компонентами) Системы в рамках одного прецедента. 
Данный вид диаграмм отражает следующие аспекты проектируемой Системы:
обмен сообщениями между объектами (в том числе в рамках обмена сообщениями со сторонними Системами)
ограничения, накладываемые на взаимодействие объектов
события, инициирующие взаимодействия объектов.
7. Диаграмма классов: структура, состав, связи
Существует два вида:
Статический вид диаграммы рассматривает логические взаимосвязи классов между собой;
Аналитический вид диаграммы рассматривает общий вид и взаимосвязи классов входящих в систему.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
Концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
Точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;
Точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.
Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Если диаграмма классов является частью некоторого пакета, то ее компоненты должны соответствовать элементам этого пакета, включая возможные ссылки на элементы из других пакетов.
8.Диаграмма компонентов для объектно-ориентированной системы и web-системы.
Диаграммы компонентов - это один из двух видов диаграмм, применяемых при моделировании физических аспектов объектно-ориентированной системы. Они показывают организацию наборов компонентов и зависимости между ними.
Диаграммы компонентов применяются для моделирования статического вида системы с точки зрения реализации. Сюда относится моделирование физических сущностей, развернутых в узле, например исполняемых программ, библиотек, таблиц, файлов и документов. По существу, диаграммы компонентов - это не что иное, как диаграммы классов, сфокусированные на системных компонентах.
Диаграммы компонентов важны не только для визуализации, специфицирования и документирования системы, основанной на компонентах, но и для создания исполняемых систем путем прямого и обратного проектирования.
Диаграмма компонентов (Component diagram) показывает набор компонентов и отношения между ними. Графически диаграмма компонентов представляется в виде
Диаграмма компонентов обладает общими свойствами, присущими всем диаграммам - именем и графическим содержанием, которое отражает одну из проекций модели. Отличается она от других диаграмм своим специфичным содержанием.
13. Диаграмма состояний: определение, назначение, структура, пример.
Диаграмма состояний - диаграмма, определяющая все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий. Показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию. Диаграмма состояний - это граф, узлы которого представляют состояния, а направленные дуги, помеченные именами соответствующих событий, - переходы. Диаграмма состояний позволяет получить последовательность состояний по заданной последовательности событий. Диаграммы состояний чаще всего используются для описания поведения отдельных объектов, но также могут быть применены для спецификации функциональности других компонентов моделей, таких как варианты использования, актеры, подсистемы, операции и методы.
Пример:

14. Идеологический смысл технического задания.
Техническое задание - исходный документ для разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).
Идеология разработки ПО - система взглядов и идей, в которых раскрывается концепция и глобальная цель, ориентированная на перспективу будущего.
Функция идеологии состоит не в том, чтобы предложить нам способ ускользнуть от действительности, а в том, чтобы представить саму действительность как укрытие от некой травматической, реальной сущности.
Примеры идеологий: Разработка Интернет-магазина
Улучшение качества сервиса предоставления товаров и услуг с помощью компьютера через Интернет.
Разработка Антивируса
Защита компьютеров от вирусов, путем сравнения их с базой данных вредоносных кодов.
Разработка информационного обеспечения системы по выдачи напитков (система вендинга)
Автоматизация продажи, доступность, сервис за счет независимости от человеческого фактора
15. Инсталляция и установка программных систем – проблемы, пути решения, инструменты.
Установка программного обеспечения, инсталляция — процесс установки программного обеспечения на компьютер конечного пользователя. Выполняется особой программой (пакетным менеджером), присутствующей в операционной системе (например, RPM, APT или dpkg в Linux, Установщик Windows в Microsoft Windows), или же входящим в состав самого программного обеспечения средством установки. В операционной системе GNU очень распространено использование системы GNU toolchain и её аналогов для компиляции программного обеспечения непосредственно перед установкой.
Возможные варианты установки
Установка вручную — установка выполняется без установщика или со значительным количеством операций, вручную выполняемых пользователем.
«Тихая» установка — установка, в процессе которой не отображаются сообщения или окна. «„Тихая“ установка» не является синонимом «автоматическая установка», хотя часто ошибочно используется в этом значении.
Самостоятельная установка — установка, которая не требует начального запуска процесса. Например, Vodafone Mobile Connect USB Modem, который устанавливается с USB-порта компьютера при подключении к нему без необходимости в ручном запуске.
Удалённая установка — установка, которая выполняется без использования монитора, подсоединённого к компьютеру пользователя (в частности, выполняемая на компьютере без видеовыхода вообще). Это может быть контролируемая установка с другой машины, соединенной через локальную сеть или посредствомпоследовательного кабеля. Автоматическая и удалённая установки являются обычными операциями, выполняемыми системными администраторами.
16. Инструментальные средства разработки программного обеспечения (ПО).
Инструмента́льное програ́ммное обеспе́чение — программное обеспечение, предназначенное для использования в ходе проектирования, разработки и сопровождения программ, в отличие от прикладного и системного программного обеспечения.
К этой категории относятся программы, предназначенные для разработки программного обеспечения:
ассемблеры — компьютерные программы, осуществляющие преобразование программы в форме исходного текста на языке ассемблера в машинные команды в виде объектного кода.
трансляторы — программы или технические средства, выполняющие трансляцию программы.
компоновщики (редакторы связей) — программы, которые производят компоновку — принимают на вход один или несколько объектных модулей и собирают по ним исполнимый модуль.
препроцессоры исходных текстов — это компьютерные программы, принимающие данные на входе и выдающие данные, предназначенные для входа другой программы, например, такой, как компилятор
отла́дчик (debugger) является модулем среды разработки или отдельным приложением, предназначенным для поиска ошибок в программе.
текстовые редакторы — компьютерные программы, предназначенные для создания и изменения текстовых файлов, а также их просмотра на экране, вывода на печать, поиска фрагментов текста и т. п.
Виды инструментального ПО
Текстовые редакторыИнтегрированные среды разработкиSDKКомпиляторыИнтерпретаторыЛинковщикиПарсеры и генераторы парсеров (см. Javacc)
АссемблерыОтладчикиПрофилировщикиГенераторы документации17.Информационный поиск. Модели поиска. Стратегии поиска.
Информационный поиск – это направление исследований, изучающее процессы поиска документов, обработки результатов поиска, а также целый ряд смежных вопросов моделирования, кластеризации и фильтрации документов, проектирования архитектуры поискавых систем и пользовательских интерфейсов, языки запросов и.т.д
Модель поиска это сочетание след. Составляющих:
Способ представления документов
Способ представления поисковых запросов
Вид критериев релевантности документов
Вариации этих составляющих определяют большое число всевозможных реализаций систем текстового поиска
Существуют такие модели как: Простейшие модели – это модели где документ представляется в виде набора ассоциированных с ним внешних атрибутов. К простейшим моделям поиска относяться модель дескрипторного поиска и модель, основанная на Дублинксом ядре.
Дублинское ядро – это набор элементов метаданных, смысл которых зафиксирован в спецификации определяющего его стандарта.
Модели основанные на классификаторах:
Это одна из разновидностей простейшей модели поиска.
Булевская модель:
В Булевсках моделях поиска пользователь может формировать запрос в виде булевского выражения, используя для этого операторы И,ИЛИ,НЕТ.
Стратегии
18.История развития программного инструмента
Язык Ассемблера
На протяжении 1950-х годов запросы на разработку программного обеспечения возросли и программы стали очень большими.
Теперь, когда была нужна эффективная программа, вместо машинных языков использовались близкие к ним машинно-ориентированные языки ассемблера. К таковым относились, например, Autocode, с 1954-го г. — IPL (предшественник языка LISP) и, с 1955-го г. — FLOW-MATIC (предшественник языка COBOL). Теперь люди стали использовать мнемонические команды взамен машинных команд.
Следующий шаг был сделан в 1954 году, когда была начата разработка языка высокого уровня — Фортран, компилятор для которого впервые появился в апреле 1957 года[3]. Вслед за ним появились и некоторые другие языки, например: LISP, ALGOL 58, FACT. Языки высокого уровня имитируют естественные языки, используя некоторые слова разговорного языка и общепринятые математические символы. Эти языки более удобны для человека, с помощью них можно писать программы до нескольких тысяч строк длиной. В дальнейшем появились COBOL (1959), Паскаль (1970), Си (1972).
1962-й год — Симула. С него началась эпоха структурного программирования.
Появление структурного программирования
К тому времени люди начали понимать, что создание программного обеспечения — гораздо более сложная задача, чем они себе представляли. Это привело к разработке труктурного программирования. С развитием структурного программирования следующим достижением были процедуры и функции. Это способствовало созданию модульных программ.
Следующим достижением было объединение разнородных данных, которые используются в программе в связке, в структуры.
Структурное программирование предполагает точно обозначенные управляющие структуры, программные блоки, отсутствие инструкций безусловного перехода (GOTO), автономные подпрограммы, поддержка рекурсии и локальных переменных.
Суть такого подхода заключается в возможности разбиения программы на составляющие элементы.
Также создавались функциональные (аппликативные) языки (Пример: Lisp — англ. LISt Processing, 1958) и логические языки (пример: Prolog — англ. PROgramming in LOGic, 1972).
Класс — это структура данных, содержащая в себе не только переменные, но и функции, которые работают с этими переменными.
В итоге в конце 1970-х и начале 1980-х были разработаны принципы объектно-ориентированного программирования. ООП сочетает лучшие принципы структурного программирования с новыми концепциями инкапсуляции, полиморфизма подтипов и наследования.
Примерами объектно-ориентированных языков являются Object Pascal, C++, Java, C# и др.
ООП позволяет оптимально организовывать программы, разбивая проблему на составные части, и работая с каждой по отдельности. Программа на объектно-ориентированном языке, решая некоторую задачу, по сути, описывает часть мира, относящуюся к этой задаче.
19. Качество ПО
Качество программного обеспечения (Software Quality)
это степень, в которой программное обеспечение обладает требуемой комбинацией свойств.
это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Рассмотрим определение "качества ПО" в контексте международных стандартов: Качество программного обеспечения - это степень, в которой ПО обладает требуемой комбинацией свойств . Качество программного обеспечения — это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности. На данный момент наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO 9126. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки.

20. Классификация направлений программирования и их особенностей:
Процедурное программирование - такое программирование, когда программа отделена от данных и состоит из последовательности команд, обрабатывающих данные. Данные как правило хранятся в виде переменных. Весь процесс вычисления сводится к изменению их содержимого.
Декларативные языки программирования - это языки объявлений и построения структур. К ним относятся функциональные и логические языки программирования. Эти языки получили широкое применение в системах автоматизированного проектирования (САПР), в так называемых CAD-пакетах, в моделировнии, системах исккусственного интеллекта.
Объектно-ориентированное программирование - в этих языках переменные и функции группируются в так называемые классы (шаблоны). Объекты, порождённые от классов вызывают методы (функции или процедуры) друг друга и меняют таким образом состояние свойств (переменных).
Сетевые языки - языки, предназначенные для организации взаимодействия удаленных компьютеров в интенсивном интерактивном режиме, а поэтому они построены на принципах интерпретации, поэтому часто они называются скриптовыми.
Машинно - ориентированные языки
Машинно - ориентированные языки - это языки, наборы операторов и изобразительные средства которых существенно зависят от особенностей ЭВМ (внутреннего языка, структуры памяти и т.д.). Машинно -ориентированные языки позволяют использовать все возможности и особенности Машинно - зависимых языков:
высокое качество создаваемых программ;
возможность использования конкретных аппаратных ресурсов;
предсказуемость объектного кода и заказов памяти;
для составления эффективных программ необходимо знать систему команд и особенности функционирования данной ЭВМ;
трудоемкость процесса составления программ;
низкая скорость программирования;
невозможность непосредственного использования программ, составленных на этих языках, на ЭВМ других типов.
Машинно-ориентированные языки по степени автоматического программирования подразделяются на классы.
Языки Символического Кодирования
 Языки Символического Кодирования (далее ЯСК), так же, как и МЯ, являются командными. Однако коды операций и адреса в машинных командах, представляющие собой последовательность двоичных (во внутреннем коде) или восьмеричных (часто используемых при написании программ) цифр, в ЯСК заменены на символы (идентификаторы), форма написания которых помогает программисту легче запоминать смысловое содержание операции. Это обеспечивает существенное уменьшение числа ошибок при составлении программ.
Использование символических адресов - первый шаг к созданию ЯСК. Команды ЭВМ вместо истинных (физических) адресов содержат символические адреса. По результатам составленной программы определяется требуемое количество ячеек для хранения исходных промежуточных и результирующих значений.
Автокоды
Есть также языки, включающие в себя все возможности ЯСК, посредством расширенного введения макрокоманд - они называются Автокоды.
В системе с генерацией имеются специальные программы, анализирующие макрокоманду, которые определяют, какую функцию необходимо выполнить и формируют необходимую последовательность команд, реализующих данную функцию.
Развитые автокоды получили название Ассемблеры. Сервисные программы и пр., как правило, составлены на языках типа Ассемблер. Более полная информация об языкеАссемблера см. ниже.
Макрос
Язык, являющийся средством для замены последовательности символов описывающих выполнение требуемых действий ЭВМ на более сжатую форму - называется Макрос(средство замены).
Макрос одинаково может работать, как с программами, так и с данными.
Машинно - независимые языки
Машинно - независимые языки - это средство описания алгоритмов решения задач и информации, подлежащей обработке. Они удобны в использовании для широкого круга пользователей и не требуют от них знания особенностей организации функционирования ЭВМ и ВС.
Т.о., командные последовательности (процедуры, подпрограммы), часто используемые в машинных программах, представлены в высокоуровневых языках отдельными операторами. Программист получил возможность не расписывать в деталях вычислительный процесс на уровне машинных команд, а сосредоточиться на основных особенностях алгоритма.
Проблемно - ориентированные языки
проблемно - ориентированные языки- Эти языки, ориентированные на решение определенных проблем, должны обеспечить программиста средствами, позволяющими коротко и четко формулировать задачу и получать результаты в требуемой форме.
Проблемных языков очень много, например:
Фортран, Алгол - языки, созданные для решения математических задач;
Simula, Слэнг - для моделирования;
Лисп, Снобол - для работы со списочными структурами.
Об этих языках рассказано дальше.
Универсальные языки
Универсальные языки были созданы для широкого круга задач: коммерческих, научных, моделирования и т.д. Первый универсальный язык был разработан фирмой IBM, ставший в последовательности языков Пл/1. Второй по мощности универсальный язык называется Алгол-68.
Программы в Пл/1 компилируются с помощью автоматических процедур. Язык использует многие свойства Фортрана, Алгола, Кобола. Однако он допускает не только динамическое, но и управляемое и статистическое распределения памяти.
Диалоговые языки
Появление новых технических возможностей поставило задачу перед системными программистами - создать программные средства, обеспечивающие оперативное взаимодействие человека с ЭВМ их назвали диалоговыми языками.
Одним из примеров диалоговых языков является Бэйсик.
Бэйсик использует обозначения подобные обычным математическим выражениям. Многие операторы являются упрощенными вариантами операторов языка Фортран. Поэтому этот язык позволяет решать достаточно широкий круг задач.
Непроцедурные языки
Непроцедурные языки составляют группу языков, описывающих организацию данных, обрабатываемых по фиксированным алгоритмам (табличные языки и генераторы отчетов), и языков связи с операционными системами.
Позволяя четко описывать как задачу, так и необходимые для её решения действия, таблицы решений дают возможность в наглядной форме определить, какие условия должны быть выполнены прежде чем переходить к какому-либо действию. Одна таблица решений, описывающая некоторую ситуацию, содержит все возможные блок-схемы реализаций алгоритмов решения.
21. Классификация стандартов программирования.
Основные требования к разработке программного средства.
Стандарты  области программного обеспечения предоставляют возможность разработчикам ПО использовать данные и программы других разработчиков, осуществлять экспорт/импорт, стандарты межпрограммного интерфейса.
Стандарты могут содержать как обязательные для исполнения нормы, так и рекомендательные. Все нормы обеспечивают право потребителя на приобретение товаров надлежащего качества, а также право на безопасность и комфортность труда. Подтверждает соответствие стандарту - сертификат.
ГОСТ - государственный стандарт
ИСО -  международная организация по стандартам 1946г.
МЭК - международная электротехническая комиссия 1881г.
 
Основные требования к разработке ПС:
использование современных информационных технологий. Выбор языка программирования д.б. целесообразным.
Стандартизация основных этапов ЖЦ ПС (промежуток времени от постановки задачи до ликвидации).
обеспечение надежности (свойство объекта выполнять заданные функции) и качества ПС.
Тестирование ПС.
Классификация стандартов в области информационных технологий:
в зависимости от масштаба:
международные
национальные
отраслевые
внутрифирменные
в зависимости от возникновения:
де-факто
де-юре
Стандарт «де-факто» - термин, обозначающий продукт какого-либо поставщика, который захватил большую долю рынка и который другие поставщики стремятся эмулировать, копировать или использовать для того, чтобы захватить свою часть рынка. Это было  в 60-70 годах.
Стандарт «де-юре» создаются формально признанной стандартизирующей организацией. Он разрабатывается при соблюдении правил консенсуса (согласие, единодушие, без голосования) в процессе открытой дискуссии.
стандарты на организацию ЖЦ:
стандарты обеспечения качества
стандарты надежности
стандарты тестирования
стандарты документирования
стандарты разработки ПО:
программирования
обмена данными
интерфейса.
22. Логическая форма графического описания взаимодействия активных объектов системы.
Диаграмма реализаций вариантов использования – логическая форма графического описания взаимодействия активных субъектов к системы. Реализация варианта использования (use case realization) — это описание всех или некоторых сценариев, составляющих вариант использования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
Разработка диаграммы вариантов использования преследует цели:
Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
Сформулировать общие требования к функциональному поведению проектируемой системы.
Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. 
23. Методы разработки программы.
В качестве разработки модульной структуры программы принято использовать древовидную структуру, включая деревья со сросшимися ветвями. В узлах такого дерева размещаются программные модули, а направленные дуги (стрелки) показывают статическую подчиненность модулей, т.е. каждая дуга показывает, что в тексте модуля, из которого она исходит, имеется ссылка на модуль, в который она входит. Другими словами, каждый модуль может обращаться к подчиненным ему модулям, т.е. выражается через эти модули. При этом модульная структура программы, в конечном счете, должна включать и совокупность спецификаций модулей, образующих эту программу. Спецификация программного модуля содержит:
• синтаксическую спецификацию его входов, позволяющую построить на используемом языке программирования синтаксически правильное обращение к нему (к любому его входу),
• функциональную спецификацию модуля (описание семантики функций, выполняемых этим модулем по каждому из его входов).
Функциональная спецификация модуля строится так же, как и функциональная спецификация ПС.
В процессе разработки программы ее модульная структура может по-разному формироваться и использоваться для определения порядка программирования и отладки модулей, указанных в этой структуре. Существуют два метода: метод восходящей разработки и метод нисходящей разработки.
Метод восходящей разработки заключается в следующем. Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модулей самого нижнего уровня (листья дерева модульной структуры программы), в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось их программирование.
Метод нисходящей разработки заключается в следующем. Как и в предыдущем методе сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке.
24. Моделирование программного обеспечения.
UML - это язык визуального моделирования программного обеспечения (и не только), включающий в себя определенную систему условных обозначений (нотацию), которая предназначена для выражения идей и решений, выполненных на этапе объектно-ориентированного анализа и проектирования.
При этом общие положения выглядят так:
1. Каждая сложная система имеет самое лучшее приближение через набор небольших и почти независимых представлений модели. Ни одно из представлений не является достаточным.
2. Каждая модель может быть выражена на различных уровнях точности или абстракции.
3. Лучшие модели приближены к реальности.
Языки описания архитектуры:
ADLS - языки описания архитектуры ПО:
- AADL (стандарт SAE)
- Wright (разработан в университете Carnegie Mellon)
- Acme (разработан в университете Carnegie Mellon)
- xADL (разработан в UCI)
- Darwin (разработан в Imperial College в Лондоне)
- DAOP-ADL (разработан в Университете Малаги)
- ByADL (Университет L'Aquila, Италия).
Виды архитектуры ПО:
Функциональный/логический вид
Структурный вид
Вид параллельности выполнения процессов (потоков)
Физический вид (развертывания)
Вид с точки зрения действий пользователя
Вид с точки зрения данных
25. Модель данных "сущность–связь". Модель сущность-связь (ER-модель)
 (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области.
ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной,объектной, сетевой или др.).
ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма)(англ. entity-relationship diagram, ERD).
Понятия ER-модель и ER-диаграмма часто ошибочно не различают, хотя для визуализации ER-моделей предложены и другие графические нотации (см. ниже). Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen)[1], американским профессором компьютерных наук в университете штата Луизиана

26. Модель: определение, классификация, пример.
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. Процесс моделирования какой -либо системы в IDEF0 начинается с определения контекста, т.е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель. Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.
Основу методологии IDEF0 составляет графический язык описания бизнес- процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры, представляющая собой самое общее описание системы и ее взаимодействия с внешней средой, называется контекстной диаграммой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области указывают на соответствие реальных бизнес - процессов созданным диаграммам. Найденные несоответствия исправляются и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Таким образом достигается соответствие модели реальным бизнес - процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели. Работы (Activity), которые означают некие поименованные процессы, функции или задачи, изображаются в виде прямоугольников. Именем работы должен быть глагол или глагольная форма (например "Изготовление детали", "Прием заказа" и т.д.). Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, "Заготовка", "Изделие", "Заказ"). В IDEF0 различают пять типов стрелок:
Вход (Input) - материал или информация, которая используется или преобразовывается работой.
Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления.
Выход (Output) - материал или информация, которая производится работой. Каждая работа должна иметь хотя бы одну стрелку выхода.
Механизм (Mechanism)- ресурсы, которые выполняют работу, например, персонал предприятия станки, механизмы и т.д.
Вызов - специальная стрелка, указывающая на другую модель работы.
Каждый тип стрелок подходит или выходит к определенной стороне прямоугольника, изображающего работу. К левой стороне подходят стрелки входов, к верхней - стрелки управления, к нижней - механизмов реализации выполняемой функции, а из правой - выходят стрелки выходов. Такое соглашение предполагает, что используя управляющую информацию и реализующий ее механизм, функция преобразует свои входы в соответствующие выходы.
При создании новой модели (меню File / New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом. Для внесения имени работы следует кликнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других аспектов контекста служит диалог Model Definition Editor (вызывается из меню Edit/Model Definition).
« DFD (Data flow diagramming) переводится на русский как «схемы потоков данных». С их помощью описываются документооборот и обработка информации. DFD можно использовать как дополнение к модели IDEF0, когда требуется более наглядное отображение текущих операций документооборота, описания функций обработки информации, документов, объектов, а также сотрудников или отделов, которые участвуют в обработке информационных потоков. Синтаксис DFD, помимо работ и стрелок, включает дополнительно два типа объектов.

Рис. 3. Пример схемы DFD
Первый, внешняя сущность, служит для отображения внешних по отношению к проектируемой системе объектов. Это может быть клиент, отдел кадров, справочник и т.п.
Второй, хранилище данных, — это «склад» информационных объектов. Им может быть база данных, файл или архив бумажных документов. Хранилище данных как бы «замораживает» данные, позволяя отобразить отсрочку в передаче объектов и информации от одной работы к другой.
IDEF3
Для описания логики взаимодействия информационных потоков более подходит IDEF3. Иногда ее называют workflow diagramming — моделирование с использованием графического описания информационных потоков, взаимоотношений между процессами обработки информации и объектами, являющимися частью этих процессов. У IDEF3 имеется специфический элемент перекресток. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования любой функции, моделируемой на схеме IDEF0.
Смешанная модель

Рис. 4. Представление смешанной модели в Model Explorer
Вспомогательные операции
BPwin позволяет эффективно манипулировать моделями: сливать и расщеплять, документировать их благодаря генерации отчетов и т. д. Кстати, существует семь предопределенных типов отчетов и поддерживаются определяемые пользователем запоминаемые стандартные отчеты.
Пакет BPwin помогает пользователю справиться с ошибками. Часть их анализируется на этапе внесения новых объектов, так как некоторые ошибочные элементы просто невозможно внести в схему, а другая часть документируется в специальном отчете Model Consistency Report, который представляет собой список синтаксических ошибок.
Построение моделей
Обычно при реорганизации предприятия сначала строится функциональная модель существующей организации работы — «AS-IS» (как есть). Модель «AS-IS» позволяет выяснить, «что мы делаем сегодня», перед тем, как перепрыгнуть на то, «что мы будем делать завтра». Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации производства. Найденные в модели «AS-IS» недостатки можно исправить при создании модели «TO-BE» (как будет) — модели новой организации процесса производства. Подобная модель нужна для анализа альтернативных путей выполнения операций и документирования того, как компания будет вести бизнес в будущем.
Оценка полученных моделей
Как правило, моделей «TO-BE» строят несколько и по определенному критерию выбирают лучшую. Проблема состоит в том, что таких критериев много и непросто найти важнейший. Для того чтобы определить качество созданной модели с точки зрения эффективности бизнес-процессов, необходима система количественной оценки. BPwin предоставляет аналитику два инструмента для оценки модели: стоимостной анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP).
Стоимостной анализ
Стоимостной анализ (ABС) является широко распространенной методикой, используемой международными корпорациями и государственными организациями для поиска истинных источников затрат в организации. Стоимостной анализ представляет собой соглашение об учете, используемое для сбора данных о затратах, связанных с работами. На основании таких данных определяется общая стоимость процесса. ABC основан на модели работ, поскольку количественная оценка невозможна без детального понимания функционирования предприятия. С помощью стоимостного анализа можно также:
определить действительную стоимость производства продукта;
определить действительную стоимость поддержки клиента;
обнаружить работы, которые стоят больше всего и которые, следовательно, должны быть улучшены в первую очередь, и т. д.
Для эффективности стоимостной анализ следует проводить лишь в том случае, если модель работы является:
последовательной (следует синтаксическим правилам IDEF0);
корректной (отражает процесс производства);
полной (охватывает всю рассматриваемую область);
стабильной (проходит цикл экспертизы без изменений).
Методика ABC включает такие основные понятия, как объект затрат (причина, по которой работа выполняется), движитель затрат (характеристики входов и управлений работы, которые влияют на то, как выполняется и как долго она длится), и центры затрат (статьи расхода).
Страницы MS Visio и их назначение. Шаблоны страниц ИТ MS Visio. Сохранение результата, использование заготовок, выдача документа разработки или его экспорт. Net технологии – Sun , MS – основные идеи и методы.. Подобия и отличия. Структура MS Net – технологические инструменты разработок программ.
Их использование для описания функциональных возможностей разработки и спецификации требований к программам.
27. Общие требования технического задания на разработку ПО. Разработка программы ведется поэтапно. На каждом этапе должно решаться ограниченное число четко поставленных задач с ясным пониманием их значения и роли в контексте всей задачи. Если такое понимание не достигнуто, это говорит о том, что данный этап слишком велик и его нужно разделить на более элементарные шаги.
Концепция модульного программирования.
Так же как и для структурной технологии, концепцию модульного программирования можно сформулировать в виде нескольких понятий и положений:
Функциональная декомпозиция задачи - разбиение большой задачи на ряд более мелких, функционально самостоятельных подзадач - модулей. Модули связаны между собой только по входным и выходным данным.
Модуль - основа концепции модульного программирования. Каждый модуль в функциональной декомпозиции представляет собой "черный ящик" с одним входом и одним выходам. Модульный подход позволяет безболезненно производить модернизацию программы в процессе ее эксплуатации и облегчает ее сопровождение.
Реализуемые решения должны быть простыми и ясными. Если назначение модуля непонятно, то это говорит о том, что декомпозиция начальной или промежуточной задачи была проведена недостаточно качественно. При наличии сложных мест в проекте их нужно подробнее документировать с помощью продуманной системы комментариев. Этот процесс нужно продолжать до тех пор, пока вы действительно не добьетесь ясного понимания назначения всех модулей задачи и их сочетания.
Назначение всех переменных модуля должно быть описано с помощью комментариев по мере их определения.
Объектно-ориентированная парадигма.
Идея ООП заключается в стремлении связать данные с обрабатывающими эти данные процедурами в единое целое - объект. ООП основано на трех важнейших принципах: инкапсуляция, наследование и полиморфизм.
Инкапсуляция - объединение в одно целое данных и алгоритмов обработки этих данных. В рамках ООП данные - поля объекта, алгоритмы - объектные методы. Поля и алгоритмы м.б. доступны извне, - общие, внешние или только внутри объекта – приватные, внутренние или группы связанных объектов – защищенные.
Наследование - свойство объектов порождать своих потомков и наделять их своими возможностями по умолчанию. Объект - потомок, может дополнять эти возможности собственными или заменять (перекрывать) их.
Полиморфизм - свойство родственных объектов (т.е. объектов, имеющих одного общего родителя) решать схожие по смыслу проблемы разными способами в зависимости от места и времени использования.»
Инструмент разработки программ определяется на основе выбранного уровня, направления, категории разработки и носит текстуальный или визуальный характер. Современное программирование – компонентное (объектное), событийное и визуальное. (Определить понятия.)
Разработка программ ведется в соответствии со стандартами – республиканскими и международными, по типовым или предлагаемым разработчиком технологиям и методикам.
Классификация инструментальных средств. По месту в процессе разработки и реализации, по временному принципу, по применяемым технологиям и методикам, по качеству продукта и т.п.
Предмет и задачи дисциплины. См. силлабус.
Роль и место инструментальных средств в процедуре разработки программ. Каждый этап разработки программы имеет свой набор инструментов. Характеристики качества и использования инструментария. Пространственные, временные, устойчивые, надежные, современные, интуитивно понятные, визуальные, статические и динамические, обеспечивающие изменяемость и настройку разработки, по характеристикам результата, соответствующие стандартам и технологиям, по избыточности целей и т. п.
28. Оптимизация программных продуктов – методы и инструменты. Инструменты и методы. Оптимизация размеров и времени выполнения программ. Определение исполняемых и выделение DLL модулей в разработке. Различие в построении DLL и EXE. Различие в использовании. . «DLL и EXE. Со временем наступает время, когда вам хочется разделить ваш APP (и следовательно EXE) на небольшие, более управляемые части. Вы будете создавать новое APP и потребуется импортировать процедуры из оригинальной копии. Целью является преобразование главного APP в несколько небольших приложений, что дает следующие преимущества:
Более быстрый цикл разработки: После фазы начального проектирования, разработка обычно разделяется на несколько небольших APP. Так как APP содержит не всю программу (процедуры и файлы), время генерации и компиляции сокращается.
Многопользовательская разработка: Различные APP легче распределить между разработчиками.
Упрощение распространения: Небольшие изменения могут потребовать небольшого апгрейда (например, изменения могут касаться только одной DLL).
Каждый APP создает выполняемую программу или библиотеку с процедурами и данными. Есть два основных типа библиотек: 1)Статическая: Все данные и процедуры линкуются в файл библиотеки (.LIB), который может быть включен (целиком) в другие приложения. 2)Динамическая: Все данные и процедуры линкуются в динамическую библиотеку (.DLL), которая является независимой единицей и которую нужно поставлять вместе с EXE-файлом программы. Предположим, что программа будет состоять из следующих частей (каждая часть соответствует отдельному APP):
Глобальная DLL (только одна)
Программные DLL (несколько)
Главный EXE (только один)
Чтобы сделать разные типы DLL и EXE, нужно предоставить дополнительную информацию:
Является ли приложение DLL или EXE (параметры проекта)
Указать какие элементы (данные/классы/процедуры) линкуются в приложение (поведение по умолчанию)
Указать какие элементы (данные/классы/процедуры), публикуются (экспортируются) для использования в других приложениях. Эта информация указывается в определении модуля или экспортном файле, который имеет имя приложения и расширение EXP, и включает все точки входа соответствующего файла библиотеки.
Указать какие элементы (данные/классы/процедуры) находятся в других приложениях. Это делается при помощи атрибутов EXTERNAL и DLL.  Соответствующий библиотечный файл также должен включен в проект.
Глобальный DLL. Область видимости данных очень важна в мульти-DLL приложениях. Простое создание данных во вкладке глобальных свойств - это не то же самое что создание глобальных данных (данных видимых в других DLL).
Для создания глобальной DLL выполним следующие шаги: Шаг 1: Чтобы дать возможность шаблонам правильно генерировать глобальные данные, они должны быть перемещены из секции данных (Global Properties) в файл глобальных данных Dictionary. Позднее любой APP, который использует эту Dictionary, будет способен сгенерировать глобальные данные с нужными атрибутами. Шаг 2: Создать новое APP, используя существующий DCT. Шаг 3: В диалоге Proect Editop|Global Options нужно установить Target Type на "DLL". Это сообщает компилятору/линкеру создавать DLL, и определяет какие элементы публиковать (экспортировать) при чтении файла EXP приложения. Будущее обсуждение файла экспорта потребует еще одной статьи! Шаг 4: В диалоге Global Properties на вкладке General установить Generate Templates Globals and ABC's As External в выключенное состояние. При генерации, все глобальные данные шаблонов и объявления классов ABC-библиотеки НЕ БУДУТ иметь атрибутов External или DLL. Это также приводит к тому, что библиотека ABC прилинковывается к этой DLL путем установки _ABCLinkMode_ в TRUE. Шаг 5: В диалоге Global Properties на вкладке File Control  убедитесь что параметр Generate All File Declarations включен. Это обеспечит генерацию всех объявлений файлов Dictionary. Так как глобальное APP не будет иметь браузеров или отчетов, без этого переключателя описания файлов вообще не будут генерироваться. Установите File Attributes/Export files/Export all file declarations в включенное положение. Это подобно Шагу 4 и в результате все сгенерированные описания файлов НЕ БУДУТ иметь атрибутов External или DLL.
Программные DLLs Программные DLLs содержат тело программы: браузеры , формы и отчеты. Главный EXE. Главный EXE обычно содержит Application Frame и процедуры Splash и About. Являясь exe-файлом, он не может экспортировать процедуру и вызывает процедуры из Процедурных DLLs. Шаг 1: Создайте новое APP и импортируйте нужные процедуры из оригинального APP (Frame, Splash и т.д.). Шаг2: Повторите Шаги 2, 3 и 4 раздела Программные DLLs. Шаг 3: Имеются несколько ToDo процедур, каждая из которых относится к пункту меню, который вызывает данную процедуру. Чтобы вызвать эти процедуры, соответствующие им DLL/Lib файлы должны быть сначала добавлены в список модулей (это разрешит вызовы внешних процедур для линковщика).  Для каждой DLL выполняем Шаг 2 раздела Программные DLLs. Шаг 4: Для каждой ToDo процедуры выбираем процедурный шаблон External и убеждаемся что в поле Module Name выбрана правильная  библиотека (Lib-файл). Это добавляет объявления процедур в глобальный Map, в правильный модуль. Шаг 5: Компилируем главный EXE.
Построение модульных диаграмм. Шаблоны представления модулей- нотация. Модули и компоненты. Пакеты. Определение деталей компонент. Зависимости между компонентами Представление размещения – диаграмма. Средства управления периода исполнения и их использование. Библиотеки периода выполнения программ.
Понятие концептуальной, логической, физической структуры БД
Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретнуюСУБД и модель данных. 
Чаще всего концептуальная модель базы данных включает в себя:
- описание информационных объектов или понятий предметной области и связей между ними.
- описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.
Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например,реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных 
Понятие модели данных.
Ядром любой базы данных является модель данных. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними.
Модель данных - это совокупность структур данных и операций их обработки. Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.
Иерархическая модель представляет собой совокупность элементов, расположенных в порядке их подчинения от общего к частному и образующих перевернутое по структуре дерево
В сетевой структуре при тех же основных понятиях (уровень, узел, связь) каждый элемент может быть связан с любым другим элементом.
Реляционная модель данных объекты и связи между ними представляет в виде таблиц, при этом связи тоже рассматриваются как объекты. Все строки, составляющие таблицу в реляционной базе данных, должны иметь первичный ключ. Все современные средства СУБД поддерживают реляционную модель данных.
Последовательность действий при разработке программ.
- создание модели данных и методики вычислений;
- описание функциональности;
- определение структуры данных; определение и описание способа реализации задачи (алгоритма решения);
- определение и описание интерфейса пользователя;
- определение средств поддержки ПО;
- спецификация задачи;
- написание текста программы;
- трансляция и отладка программы;
- связывание и подключение библиотек поддержки;
- создание среды выполнения; размещения исходного модуля и загрузка;
- создание встроенной помощи и документирование разработки;
- создание устанавливаемого (инсталляцион.) пакета ПО.

Построение контекстной помощи – средства и методики.
Основные типы помощи пользователям программных средств: - контекстно-независимая помощь, реализованная либо в виде статических руководств, либо в виде обучающих систем.Статические руководства, в свою очередь, могут быть представлены в виде онлайновой помощи и реализованы с помощью различных средств (Microsoft Winhelp, Microsoft Compressed HTML Help, HTML Help 2.0, AP Help 1.0). 
- контекстно-зависимая помощь, реализованная в некоторых моделеориентированных средствах (CTTE, TWIW, CACTUS, FUSE, UIDE).
Принцип работы
С каждым вопросом пользователя, на который он может получить ответ, связан алгоритм, который генерирует ответ на поставленный вопрос. Входными данными для каждого алгоритма является текущее состояние, в котором находится пользователь, а также информация о задачах, решенных им на предыдущих шагах. Пользователь взаимодействует с системой помощи через «интерфейс помощи», содержащий вопросы, на которые пользователь может получить ответы. 
Технология разработки системы контекстно-зависимой помощи:1. Разработать модель задач, отражающую логическую структуру программного средства.2. Произвести интеграцию системы помощи в код программного средства. Интеграция системы помощи в программное средство производится путем пометки графических элементов пользовательского интерфейса аннотациями (специальными комментариями, предназначенными длякомпилятора), что полностью исключает изменение логики кода.
3.Создать анимационные обучающие ролики.  Интерактивные обучающие ролики представляют собой набор действий, автоматически выполняемых системой помощи в прикладной программе. Ролики не выполняют задачи пользователя, они только эмулируют выполнение этих задач [1].
37.Психологические особенности разработки ПО.
Разработка программного продукта — это процесс, в котором человеческий фактор играет очень важную роль.
Разработка программного обеспечения — нелинейный процесс. Если на проект выделено 5 разработчиков, которые за 5 месяцев должны разработать продукт (25 чел./мес.), то 25 разработчиков не смогут сделать эту же работу за 1 месяц (те же 25 чел./мес.). 
И да, скорее всего, 10 разработчиков тоже не смогут сделать исходную объем работы за 2,5 месяца, так как совместные действия 10 разработчиков на проекте длительностью 5 месяцев, скорее всего, приведут к дедлоку или другим проблемам коммуникации.
Для иллюстрации “цены ошибки” часто используют конус неопределенности — график, на горизонтальной оси которого указано время, а на вертикальной оси — значение ошибки, которая закладывается при оценке трудоёмкости. C течением времени, по мере того, как становится известно всё больше данных об оцениваемом проекте, о том, что же конкретно и в каких условиях придётся делать, «разброс» ошибки становится всё меньше. Как цена ошибки растет в случае с переоценкой и недооценкой? Оказывается, что при переоценке цена ошибки растет линейно, при недооценке цена ошибки растет по экспоненте.Линейный рост в первом случае объясняется законом Паркинсона, который гласит: работа заполняет время, отпущенное на неё. Также этот закон называют “синдромом студента” — сколько бы времени не дали на выполнение курсовой, всё равно она делается до последнего дня перед сдачей.
38.Разработка технического задания.
ТЗ - исходный документ для разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).
ТЗ содержит основные технические требования, предъявляемые к ПП; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской (проектной, технологической, программной и т.п.) документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации.
ТЗ разрабатывается заказчиком для разработчика
Как инструмент коммуникации ТЗ позволяет:
обеим сторонам:
представить готовый продукт
выполнить попунктную проверку готового продукта
уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности
заказчику:
осознать, что именно ему нужно
требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ
исполнителю (разработчику):
понять суть задачи, показать заказчику «технический облик» ПО
спланировать выполнение проекта и работать по намеченному плану
отказаться от выполнения работ, не указанных в ТЗ
В ТЗ входит:
Введение
Общие сведения
Назначение и цели создания по
Требования к программному обеспечению
Психологические особенности
Экономическое обоснование
Стадии и этапы разработки по
Тестирование и отладка по
Порядок контроля и приемки
Общие сведения
2.1 Полное название ПО и ее условное обозначение
Название. Условное обозначение. Обоснование.
2.2 Наименование предприятий разработчика и заказчика и их реквизиты
Название, адрес, ФИО, телефоны, РНН и т.д.
2.3 Плановые сроки начала и окончания работы по созданию ПО
2.4 Сведения об источниках и порядке финансирования работ
Указать источник (спонсор) и порядок финансирования работ.
Назначение и цели создания ПО
3.1 Актуальность разработки ПО
3.2 Область применения
3.3 Идеология программного обеспечения
3.4 Постановка проблемы
3.5 Постановка задачи
3.6 Цель разработки ПО
3.7 Задачи исследования
3.8 Преимущества программы
Недостатки программы
39.Реляционная модель данных
Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка.
На реляционной модели данных строятся реляционные базы данных.
Реляционная модель данных включает следующие компоненты:
Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.
Аспект (составляющая) целостности — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).
Кроме того, в состав реляционной модели данных включают теорию нормализации.
Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».
Для лучшего понимания РМД следует отметить три важных обстоятельства:
модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;
для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно — явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;
наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.
40.Современное программирование – базовые понятия и инструменты.
Современное программирование ведется на так называемых языках высокого уровня, так что от программиста в идеале не требуется ничего знать об устройстве конкретного компьютера, скажем, о том, какие там регистры, в каких разрядах машинного слова помещаются коды команды, а в каких - адреса операндов и тому подобное. 
Современное программирование существенно отличается от технологии разработки программ для старых ЭВМ. 
Задачи современного программирования приводят к сложным алгоритмам. Например, при поиске научной информации в некотором массиве данных организуется целый ряд сравнений ( с признаком или набором признаков), логическая структура которых сложная, что затрудняет непосредственное программирование. 
В современном программировании существует несколько различных форм представления программы, соответствующих этапам разработки, отладки и счета: входной текст на языке программирования; промежуточный массив на языке загрузки; рабочая программа в командах ЭВМ. 
Важным средством современного программирования является возможность распараллеливания программы. Недостатком всех трех языков является отсутствие таких средств на языковом уровне. 
Первый такой мячик связан с именем бабушки современного программирования Грейс Мюррей Хоппер.
Абстракция является одним из наиболее важных инструментов современного программирования. Выбор разработчиками языка программирования тех или иных механизмов абстракции оказывает сильнейшее влияние на возможность функциональной абстракции и абстракции данных. А это, в свою очередь, определяет способ разработки и реализации ( т.е. способ декомпозиции) большого программного комплекса. 
Принцип модульности - один из основополагающих в современном программировании, позволяющий просто и эффективно реализовать системный подход и иерархическое построение программного обеспечения пакета. Принцип модульности упрощает разработку пакета, обеспечивая эффективную организацию разработки всех элементов программного обеспечения, легкость поддержания и гибкость.
Модульное программирование основано на понятии модуля - логически взаимосвязанной совокупности функциональных элементов, оформленных в виде отдельных программных модулей.
Модуль характеризуют:
один вход и один выход - на входе программный модуль получает определенный набор исходных данных, выполняет содержательную обработку и возвращает один набор результатных данных, т.е. реализуется стандартный принцип IPO (Input - Process - Output) - вход-процесс-выход;
функциональная завершенность - модуль выполняет перечень регламентированных операций для реализации каждой отдельной функции в полном составе, достаточных для завершения начатой обработки;
логическая независимость - результат работы программного модуля зависит только от исходных данных, но не зависит от работы других модулей;
слабые информационные связи с другими программными модулями - обмен информацией между модулями должен быть по возможности минимизирован;
обозримый по размеру и сложности программный элемент.
Таким образом, модули содержат определение доступных для обработки данных, операции обработки данных, схемы взаимосвязи с другими модулями.
41. Современные технологии разработки ПО. Rational Unified Process
Это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.
Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.
RUP обеспечивает строгий подход к распределению задач и ответственности внутри организации-разработчика. Его предназначение заключается в том, чтобы гарантировать создание точно в срок и в рамках установленного бюджета качественного ПО, отвечающего нуждам конечных пользователей.
RUP способствует повышению производительности коллективной разработки и предоставляет лучшее из накопленного опыта по созданию ПО, посредством руководств, шаблонов и наставлений по пользованию инструментальными средствами для всех критически важных работ, в течение жизненного цикла создания и сопровождения ПО.
Экстремальное программирование — сравнительно молодая методология разработки программных систем, основанная на постепенном улучшении системы и разработки ее очень короткими итерациями. По своей сути экстремальное программирование (XP) — это одна из так называемых «гибких» методологий разработки ПО, которая представляет собой небольшой набор конкретных правил, позволяющих максимально эффективно выполнять требования современной теории управления программными проектами.
XP ориентирована на:
командную работу с тесными связями внутри команды и с заказчиком;
разработку наиболее простых работающих решений;
гибкое адаптивное планирование;
оперативную обратную связь (путем модульного и функционального тестирования).
Microsoft Solutions Framework (MSF) — это методология ведения проектов и разработки решений, базирующаяся на принципах работы над продуктами самой фирмы Microsoft и предназначенная для использования в организациях, нуждающихся в концептуальной схеме для построения современных решений.
Microsoft Solutions Framework является схемой для принятия решений по планированию и реализации новых технологий в организациях. MSF включает обучение, информацию, рекомендации и инструменты для идентификации и структуризации информационных потоков бизнес-процессов и всей информационной инфраструктуры новых технологий.
42. Современные языки программирования ПО.
В настоящее время в мире существует несколько сотен реально используемых языков программирования, для каждого из которых существует своя область применения. В зависимости от степени детализации предписаний обычно определяется уровень языка программирования - чем меньше детализация, тем выше уровень языка.
Современные языки программирования:
С++. Ключевым понятием С++ является класс, Класс – тип , определяемый пользователем. Классы обеспечивают скрытие данных, неявное преобразование типов, определенных пользователем, динамическое задание типа, контролируемое пользователем управление памятью и механизм перегрузки операций .
Java. “Молодой” язык программирования и основной инструмент программирования для Internet. Создатели Java безжалостно удалили из С все несовременные конструкции, и в то же время сумели удержаться от излишнего “раздувания” языка включением в него новых теоретических разработок. В результате получился не очень объемный, но стройный, “крепко сбитый” язык программирования с ярко выраженной идеологией. К сожалению, ориентация на Internet не дает возможности использовать Java как язык системного программирования, однако это хороший пример реформы С.
PASCAL. Один из самых распространенных языков программирования поддерживающий структурное и модульное программирование. Он берет свои корни из АЛГОЛА-60,и был создан Швейцарцем Н.Виртом. Особо следует отметить надежность программ на Паскале достигаемой за счет описания переменных и соответствующих типов. Читабельность языка помогает нахождению ошибок в коде……
MODULA-2. Наиболее известный клон PASCAL и любимый язык автора этой статьи. Классический набор операторов и конструктор типов. Хорошо разработанные механизмы раздельной компиляции (конкуренцию MODULA в этом классе может составить только ADA). Маленький и удобный язык с точки зрения разработчика компилятора (как и все языки Вирта, видимо, сказывается то обстоятельство, что Вирт сам пишет компиляторы для своих языков). Недостатком языка можно считать полное отсутствие механизмов ООП.
OBERON-2. Последний из языков Вирта и клонов PASCAL. OBERON позиционировался как MODULA + ООП, однако при создании языка Вирт выбросил из MODULA много приятных возможностей (часть из которых была добавлена при создании OBERON-2, считающегося современным вариантом языка).
ADA-95.Самый мощный из используемых сегодня языков программирования, ADA вызывает противоречивые чувства. С что создание компиляторов для него стало крайне трудоемким и дорогостоящим делом.

43. Специфические требования технического задания.
Техническое задание содержится следующая информация: Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний.
Согласно ГОСТу, настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Надо быть предельно внимательным и осторожным, создавая его, т.к. зачастую умело (и грамотно) составленное техническое задание определяет успех всей работы.
Техническое задание оформляют на листах формата А4 и/или А3, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
Техническое задание должно содержать следующие разделы:
наименование и область применения;
основание для разработки;
назначение разработки;
технические требования к программе или программному изделию;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.
44. Сравнение возможностей пакетов программирования баз данных.
Первые базы данных появились очень давно, как только появилась потребность в обработке больших массивов информации и выборки групп записей по определенным признакам. Для этого был создан структурированный язык запросов SQL (Structured Query Language), Он основан на мощной математической теории и позволяет выполнять эффективную обработку баз данных, манипулируя не отдельными записями, а группами записей.
Для управления большими базами данных и их эффективной обработки разработаны СУБД (Системы Управления Базами Данных). Практически в каждой СУБД помимо поддержки языка SQL имеется также свой уникальный язык, ориентированный на особенности этой СУБД и не переносимый на другие системы.
Сегодня в мире насчитывается пять ведущих производителей СУБД: Microsoft (SQL Server), IBM (DB2), Oracle, Software AG (Adabas), Informix и Sybase. Их продукты нацелены на поддержку одновременной работы тысяч пользователей в сети, а базы данных могут храниться в распределенном виде на нескольких серверах. В Oracle имеется встроенный язык PL/SQL, в Informix - INFORMIX 4GL, в Adabas - Natural и т. д.
С появлением персональных компьютеров были созданы так называемые настольные СУБД. Родоначальником современных языков программирования баз данных для ПК принято считать СУБД dBase II, язык которой был интерпретируемым. Затем для него были созданы компиляторы, появились СУБД FoxPro и Clipper, поддерживающие диалекты этого языка. Сегодня похожие, но несовместимые версии языков семейства dBase реализованы в продуктах Visual FoxPro фирмы Microsoft и Visual dBase фирмы Inprise.
45.Сравнение возможностей систем управления базы данных.
SQLite
Легко встраиваемая в приложения база данных. Так как это система базируется на файлах, то она предоставляет довольно широкий набор инструментов для работы с ней, по сравнению с сетевыми СУБД.
Преимущества SQLite
Файловая структура - вся база данных состоит из одного файла, поэтому её очень легко переносить на разные машины
Используемые стандарты - использует SQL.
Отличная при разработке
Недостатки SQLite
отсутствие системы пользователей - более крупные СУБД включают в свой состав системы управления правами доступа пользователей.
отсутствие возможности увеличения производительности - исходя из проектирования, довольно сложно выжать что-то более производительное из нее.
MySQL
MySQL - это самая распространенная полноценная серверная СУБД. MySQL очень функциональная, свободно распространяемая СУБД, которая успешно работает с различными сайтами и веб приложениями.
Преимущества MySQL
Простота в работе. Дополнительные приложения, например GUI, позволяет довольно легко работать с БД
Богатый функционал
Безопасность
Масштабируемость - MySQL легко работает с большими объемами
Скорость - упрощение некоторых стандартов позволяет MySQL значительно увеличить производительность.
Недостатки MySQL
Известные ограничения функционала
Проблемы с надежностью
Медленная разработка
PostgreSQL
PostgreSQL является самым профессиональным из всех трех рассмотренных нами СУБД. Она свободно распространяемая и максимально соответствует стандартам SQL. От других СУБД PostgreSQL отличается поддержкой востребованного объектно-ориентированного и/или реляционного подхода к базам данных. Например, полная поддержка надежных транзакций, т.е. атомарность, последовательностьи д.р
Достоинства PostgreSQL
Открытое ПО соответствующее стандарту SQL - PostgreSQL - бесплатное ПО с открытым исходным кодом. Эта СУБД является очень мощной системой.
Большое сообщество
Большое количество дополнений
Возможность расширения функционала
Объектность
Недостатки PostgreSQL
Производительность - при простых операциях чтения PostgreSQL может значительно замедлить сервер и быть медленнее своих конкурентов, таких как MySQL
Популярность - популярностью эта СУБД похвастаться не может
Хостинг -иногда довольно сложно найти хостинг с поддержкой этой СУБД.
46.Сравнение диаграммы деятельности и алгоритма работы программы.
Алгоритм – это инструкция о том, в какой последовательности нужно выполнить действия при переработке исходного материала в требуемый результат. На практике получили известность два способа изображения алгоритмов:в виде пошагового словесного описания;в виде блок-схем.
Диаграммы деятельности - это один из пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов поведения системы. Диаграмма деятельности - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой.
Диаграммы деятельности позволяют моделировать сложный жизненный цикл объекта, с переходами из одного состояния (деятельности) в другое. Но этот вид диаграмм может быть использован и для описания динамики совокупности объектов. Они применимы и для детализации некоторой конкретной операции, причем, предоставляют для этого больше возможностей, чем "классическая" блок-схема.

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

Аналогия с дорожками действительно очень удачна. Именно таково официальное название элемента нотации UML, позволяющего указать распределение ролей на диаграмме активностей.
Более формально, дорожка - часть области диаграммы деятельности, на которой отображаются только те деятельности, за которые отвечает конкретный объект.
47. Сравнение диаграммы классов и структуры базы данных.
Диаграмма классов - называют диаграмму, на которой показано множество классов, интерфейсов, коопераций и отношений между ними.
Классом (Class) называется описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.
Атрибут поименованное свойство класса, описывающее диапазон значений, которые могут принимать экземпляры этого свойства.
Отношения: 1. Зависимости, которые описывают существующие между классами отношения использования ;
2. Обобщения, связывающие обобщенные классы со специализированными;
3. Ассоциации, представляющие структурные отношения между объектами.

Схема базы данных (от англ. Database schema) — её структура, описанная на формальном языке, поддерживаемом СУБД. В реляционных базах данных схема определяет таблицы, поля в каждой таблице (обычно с указанием их названия, типа, обязательности), и ограничения целостности (первичный, потенциальные и внешние ключи и другие ограничения).
Сущности – это базовые типы информации, которые хранятся в БД рассматриваемой предметной области (в реляционной БД каждой сущности назначается таблица), что в диаграмме классов мы называем классом.
Как и в диаграмме классов сущность имеет:
Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности. В реляционной БД атрибуты хранятся в полях таблиц.Связь – взаимосвязь между сущностями в предметной области. Связи представляют собой соединения  между частями БД (в реляционной БД – это соединение между записями таблиц).

:
В отличии от диаграммы классов сущность имеет Ключи БД:
Первичный ключ – это одно или несколько полей, комбинация значений которых однозначно определяет каждую запись в таблице.
Внешний (вторичный) ключ - это одно или несколько полей (столбцов) в таблице, содержащих ссылку на поле или поля первичного ключа в другой таблице
48.Сравнение диаграммы объектов и диаграммы компонент.
Диаграммы объектов
демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

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

49. Сравнение возможностей объектных языков программирования
C# и Java — два языка программирования, развивающих язык программирования С++, с синтаксисом, во многом наследующим синтаксис С++, и созданных, во многом, в условиях конкуренции, и вследствие этого, обладающими определённым сходством, а, также, имеющими и ряд различий.
Общий взгляд
Языки C# и Java появились в разное время. Язык Java был создан задолго до появления C#. Под названием Oak Java был разработан компанией Sun Microsystems в 1990 г., а в 1995 была выпущена первая бета-версия Java. Создание C# было анонсировано в 2000 году, а в 2002 году вышла первая версия платформы .NET, поддерживающей C#. Таким образом, если Java создавался опираясь в большей степени на опыт языков Objective C и C, то для C# такой опорой являлись C++ и сам Java[1]. И, несмотря на своё название, C# оказался ближе к Java, чем к C++[2][3].
С точки зрения разработчика языки Java и C# очень похожи. Оба языка являются строго типизированными, объектно-ориентированными. Оба вобрали в себя многое из синтаксиса C++, но в отличие от C++, проще в освоении для начинающих. Оба языка используют сборку мусора. Оба используют фигурные скобки для выделения блоков. Оба языка сопровождаются богатыми коллекциями библиотек. Но есть в языках также свои особенности и различия, сильные и слабые стороны. C# учёл многие недостатки Java, и исправил их в своей реализации[4]. Но и Java не стоит на месте, развиваясь параллельно с C#.
Кик Рэдек из Microsoft считает С# более сложным языком, чем Java[1]. По его мнению, «язык Java был построен таким образом, чтобы уберечь разработчика от стрельбы себе в ногу» (англ. «Java was built to keep a developer from shooting himself in the foot»), а «С# был построен так, чтобы дать разработчику ружьё, но оставить его на предохранителе» (англ. «C# was built to give the developer a gun but leave the safety turned on»).
Синтаксис
Оба языка используют в качестве синтаксической основы язык программирования C. В частности, от него унаследованы без изменений:
обозначения начала/конца блока кода фигурными скобками;
обозначения, ассоциативность и приоритет большинства встроенных операций (присвоение, арифметические, логические, побитовые операции, операции инкремента/декремента, тернарная условная операция «?:»);
синтаксис описания и использования переменных и функций (порядок «тип имя», использование модификаторов, обязательность скобок для функций, описание формальных параметров);
синтаксис всех основных конструкций: условного оператора, циклов, оператора множественного выбора;
Синтаксических различий также достаточно.
Объектные средства
Оба языка — объектно-ориентированные, с синтаксисом, унаследованным от C++, но значительно переработанным. Код и данные могут описываться только внутри классов.
Инкапсуляция
В Java модификатор protected в описании, помимо доступа из классов-потомков, разрешает доступ из всех классов, входящих в тот же пакет, что и класс-владелец.
C# для объектов, которые должны быть видны в пределах сборки (примерный аналог пакета Java) введён отдельный модификатор internal (аналог default в Java), а protected сохраняет свой изначальный смысл, взятый из C++ — доступ только из классов-потомков. Допускается комбинировать internal и protected — тогда получится область доступа, соответствующая protected в Java.
Внутренние классы
Оба языка позволяют определить класс внутри класса.
В Java внутренние классы используются для эмуляции замыканий. Внутренние классы Java имеют доступ к нестатическим членам родительского класса, то есть «знают о this»; кроме того, внутри методов можно определять локальные классы, имеющие доступ по чтению к локальным переменным, и безымянные (анонимные) локальные классы, которые фактически позволяют создавать экземпляры объектов и интерфейсов, перекрывающие методы своего класса, непосредственно в месте их использования. На этом механизме в Java-программах может строиться обработка событий (событие генерирует вызов метода, в исходном классе-обработчике являющегося абстрактным; там, где нужен конкретный обработчик события, программист создаёт экземпляр локального анонимного класса — наследника базового класса-обработчика и непосредственно использует его). Таким образом, исчезает необходимость в специальном типе и синтаксической поддержке для событий, но сам код, создающий обработчики, несколько более сложен для понимания. В частности, сложнее становятся области видимости переменных.
В C# есть замыкания и лямбды. Подход C# более напоминает C++: внутренние классы в C# имеют доступ только к статическим членам внешнего класса, а для доступа к нестатическим членам нужно явно указывать экземпляр внешнего класса. Локальные внутренние классы в C# и не поддерживаются.
Методы
В обоих языках методы определяются через функции класса. Тело метода располагается внутри описания класса. Поддерживаются статические методы, абстрактные методы. В C# также есть явная реализация методов интерфейса, что позволяет классу реализовывать методы интерфейса отдельно от собственных методов или давать разные реализации одноимённых методов, принадлежащих двум разным интерфейсам.
В Java примитивные типы (byte, int, double, float, bool и пр.) передаются по значению, а для остальных (объектные) по значению передается ссылка на объект.
В C# в дополнение к примитивным типам передаются по значению структуры (struct) (т. н. значимые типы), остальные типы передаются по ссылке (т. н. ссылочные типы). C# также поддерживает явное описание передачи параметров по ссылке (ключевые слова ref и out). При использовании out компилятор контролирует наличие в методе присваивания значения. Использовать их стоит только при работе с неуправляемым кодом, который это требует (например, Winapi), так как это нарушает концепцию ООП.
В C# запрещается давать методам наименование, совпадающее с названием класса, что предотвращает ошибки (в Java программист может определить конструктор, который будет на самом деле являться методом)
Массивы и коллекции
Массивы и коллекции тоже получили выражение в синтаксисе обоих языков, благодаря особой разновидности цикла for (цикл по коллекции, известный также как цикл foreach). В обоих языках массив является объектом класса Array, но в Java он не реализует какие-либо интерфейсы коллекций, хотя по массивам возможна итерация циклом for(:). Оба языка имеют в стандартной библиотеке классы типичных коллекций.
50. Отладка программного обеспечения
Под отладкой понимается процесс, позволяющий получить программное обеспечение, функционирующее с требующимися характеристиками в заданной области входных данных.
Отладка не является разновидностью тестирования, хотя слова «отладка» и «тестирование» часто используют как синонимы. Под ними подразумеваются разные виды деятельности:
- тестирование — деятельность, направленная на обнаружение ошибок;
- отладка направлена на установление точной природы известной ошибки, а затем - на исправление этой ошибки;
- результаты тестирования являются исходными данными для отладки.
Эти два вида деятельности очень тесно связаны и поэтому они обычно рассматриваются совместно.
В результате отладки программное обеспечение должно соответствовать определенной фиксированной совокупности правил и показателей качества, принимаемой для него за эталонную. Иными словами: отладка — это этап разработки, на котором устраняются недостатки только что созданного программного обеспечения.
Основная задача отладки в целом состоит в завершении разработки всего программного обеспечения и в доведении его характеристик до значений, заданных требованиями технического задания (соглашения о требованиях). При этом ПО должно гарантированно удовлетворять всем требованиям не только в диапазоне типичных условий его функционирования, но и при предельных, критических сочетаниях значений всех параметров. Это обеспечивает надежность функционирования ПО при разнообразных произвольных, в том числе, искаженных сочетаниях исходных данных.
По оценкам специалистов, в общем, времени разработки программного обеспечения, отладка занимает от 50 % до 90% (зависит от результатов проведения предыдущих этапов).
Отладку можно разделить на синтаксическую и семантическую.
Отладка синтаксиса обычно не вызывает трудностей и требует только аккуратности. Результаты синтаксически правильной программы сравниваются с тестовыми, их несовпадение является признаком наличия семантической ошибки. Это сравнение надо выполнять очень скрупулезно: даже лишний пробел между двумя значениями может дать ключ к поиску ошибки.
В отличие от синтаксической ошибки, семантическая ошибка не формализуема и поэтому она составляет основу отладки.
Отладка готовой части (ветви) программного обеспечения может быть начата ранее, чем будет написан весь программный продукт, в результате чего сокращается время разработки ПО, т.е. экономится календарное время его разработки. Временно отсутствующие блоки либо оставляются пустыми, либо заменяются печатью сообщения о том, что программное обеспечение не рассчитано на такие данные, или пишутся временные программные заглушки.
51. Технико-экономическое обоснование ПО
Под технико-экономическим обоснованием стоимости (договорной цены)
программного обеспечения будем понимать методику оценивания трудовых,
временных и финансовых ресурсов по созданию ПО, соответствующей требованиям заказчика.
В основу определения требуемых объемов ресурсов должны быть положены:
- совокупность функций (бизнес-процессов), реализуемых в будущей программной системе и их относительная важность (приоритет) для заказчика;
- требования к функциональной полноте и качеству реализации каждой
функции.
В качестве основных показателей оценки стоимости ПО используются:
- сложность (размеры);
- трудозатраты на разработку;
- длительность разработки в целом и отдельных
этапов;
- численность и квалификация специалистов, привлекаемых к созданию;
- фонд оплаты труда специалистов на создание программной системы в целом и по конкретному этапу жизненного цикла;
- прочие прямые затраты и накладные расходы.
В основу определения размеров ПО положено понятие «сложности», под которой понимается количество элементов (программных компонент, файлов, входных и выходных документов) и взаимосвязей между ними.
Под термином трудозатраты понимается суммарный объем труда специалистов для создания программного продукта.
Длительность разработки и численность специалистов определяются на
основе трудозатрат и нормативной производительности труда программиста,
выражаемой в количестве строк кода, создаваемых программистом в единицу времени. При этом выделяются следующие этапы жизненного цикла ПО:
- анализ требований к ПО;
- определение спецификаций;
- проектирование;
- кодирование;
- тестирование и комплексные испытания;
- опытная эксплуатация.
В реализации проекта на каждом этапе принимает участие три группы
специалистов:
- руководитель проекта, системные аналитики;
- непосредственные разработчики программных систем и специалисты по
комплексированию;
- технический персонал, обеспечивающий тестирование, документирование
и опытную эксплуатацию программного обеспечения.
Фонд оплаты труда на реализацию проекта определяется исходя из производительности труда специалиста и согласованной базовой месячной заработной платы.
Все нормативы и другие статистические данные, используемые в методиках технико-экономического обоснования стоимости основываются на статистических данных, обобщающих зарубежный и российский опыт разработки.
52. Требования к программному обеспечению 
— совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.
Требования могут выражаться в виде текстовых утверждений и графических моделей.
Этапу разработки требований, возможно, предшествовало технико-экономическое обоснование, или концептуальная фаза анализа проекта. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификация (документирование требований) и проверка правильности.
Виды требований по уровням:
Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).
Функциональные требования — охватывают предполагаемое поведение системы, определяя действия, которые система способна выполнять[источник не указан 858 дней]. Описывается в системной спецификации (англ. system requirement specification, SRS).
Виды требований по характеру
Функциональный характер — требования к поведению системы
Бизнес-требования
Пользовательские требования
Функциональные требования
Нефункциональный характер — требования к характеру поведения системы
Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)
Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять. К системным требованиям и ограничениям относятся:
Ограничения на программные интерфейсы, в том числе к внешним системам
Требования к атрибутам качества
Требования к применяемому оборудованию и ПО
Требования к документированию
Требования к дизайну и юзабилити
Требования к безопасности и надёжности
Требования к показателям назначения (производительность, устойчивость к сбоям и т. п.)
Требования к эксплуатации и персоналу
Прочие требования и ограничения (внешние воздействия, мобильность, автономность и т. п.).
53.Требования, предъявляемые к разработке ПО.
Требования, предъявляемые к ТС ПО(технологии создания по)
Технология создания ПО - упорядоченная совокупность взаимосвязанных технологических процессов в рамках ЖЦ ПО.
Основным требованием, предъявляемым к современным ТС ПО, является их соответствие стандартам и нормативным документам, связанным с процессами ЖЦ ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Согласно этим нормативам, ТС ПО должна поддерживать следующие процессы:
управление требованиями;
анализ и проектирование ПО;
разработка ПО;
эксплуатация;
сопровождение;
документирование;
управление конфигурацией и изменениями;
тестирование;
управление проектом.
Полнота поддержки процессов ЖЦ ПО должна поддерживаться комплексом инструментальных средств (CASE-средств).
Соответствие стандартам означает также, в частности, использование общепринятых, стандартных нотаций и соглашений. Для того чтобы проект мог выполняться разными коллективами разработчиков, необходимо использование стандартных методов моделирования и стандартных нотаций, которые должны быть оформлены в виде нормативов до начала процесса проектирования. Несоблюдение проектных стандартов ставит разработчиков в зависимость от фирмы-производителя данного средства, делает затруднительным формальный контроль корректности проектных решений и снижает возможности привлечения дополнительных коллективов разработчиков, смены исполнителей и отчуждения проекта, поскольку число специалистов, знакомых с данным методом (нотацией), может быть ограниченным.
Другим важным требованием является адаптируемость к условиям применения, которая достигается за счет поставки технологии в электронном виде вместе с CASE-средствами и библиотеками процессов, шаблонов, методов, моделей и других компонентов, предназначенных для построения ПО того класса систем, на который ориентирована технология. Электронные технологии должны включать средства, обеспечивающие их адаптацию и развитие по результатам выполнения конкретных проектов. Процесс адаптации заключается в удалении ненужных процессов и действий ЖЦ ПО, в изменении неподходящих или в добавлении собственных процессов и действий, а также методик, стандартов и руководств.
54. Файл - менеджеры – программы управления файлами при разработке – возможности и их наращивание, разнообразие и характеристики использования
Файловый менеджер — это программа, которая позволяет пользователю управлять файлами и папками на компьютере. Файловый менеджер позволяет выполнять наиболее частые операции над файлами — создание, открытие/проигрывание/просмотр, редактирование, перемещение, переименование, копирование, удаление, изменение атрибутов и свойств, поиск файлов и назначение прав. Помимо основных функций, многие файловые менеджеры включают ряд дополнительных возможностей, например, таких, как работа с сетью (через FTP, NFS и т. п.), резервное копирование, управление принтерами и пр.
Выделяют различные типы файловых менеджеров, например:
Навигационные и пространственные — иногда поддерживается переключение между этими режимами.
Двухпанельные — в общем случае имеют две равноценных панели для списка файлов, дерева каталогов и т. п.
Двупанельные — например FAR, Unreal Commander.
Файловые менеджеры, в зависимости от операционной системы, в которой они используются, подразделяются на:
Менеджеры Windows — например Проводник (встроенный в Windows),  FAR, Unreal Commander.
Менеджеры Linux — например Gnome Commander, Krusader.
Менеджеры Mac OS — например Finder (встроенный) Disk Order.
Кроссплатформенные (работающие в нескольких операционных системах) — например JC, muCommander.
Преимущества двупанельных файловых менеджеров перед  навигационными:
-Прежде всего это удобство и быстрота работы.
-Количество действий при работе с файлами (копирование, перемещение) снижается в разы!
55.Целостность и защита данных. Структуры БД.
Це́лостность ба́зы да́нных (database integrity) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint).
Выделяют три группы правил целостности:
Целостность по сущностям.
Целостность по ссылкам.
Целостность, определяемая пользователем.
Защита данных – это организационные, программные и технические методы и средства, направленные на удовлетворение ограничений, установленных для типов данных или экземпляров типов данных в системах обработки данных (ГОСТ 20886-85).
Защита данных включает предупреждение случайного или несанкционированного доступа к данным, их изменения или разрушения со стороны пользователей или при сбоях аппаратуры. Реализация защиты включает:
контроль достоверности данных с помощью ограничений целостности;
обеспечение безопасности данных (физической целостности данных);
обеспечение секретности данных.
Структура базы данных
Структура баз данных – даталогическая (ER-диаграмма, инфологическая, физическая модель). По UML представляет с собой диаграмму классов с отношениями между таблицами.
Файл (таблица) представляет собой набор данных о том, или ином предмете или объекте. Данные в таблице (файле) хранятся в виде столбцов (полей) и строк (записей). Все данные в таблице должны относиться к объектам одного типа и только к ним.
Поле файла (таблицы) определяет род сведений о предмете.
114300025082500Записью является набор сведений о человеке, предмете или событии. Каждая запись в таблице содержит один и тот же набор полей и каждое поле одного и того же рода сведения о предмете.
56. Экономические требования разработки ПО
Разработка бизнес-плана
Расчет стоимости
Расчет сметы затрат
Расчет стоимости разработки программного обеспечения
Расчет стоимости одного CD программного продукта
Расчет экономической эффективности
РR-компания
Анализ рынка сбыта
Проведение рекламной компании по раскрутке ПО.
57.Этап выработки требований к программе - методы и инструменты.
Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.
Требования могут выражаться в виде текстовых утверждений и графических моделей. В классическом техническом подходе совокупность требований используется на стадии проектирования программного обеспечения (ПО). Требования также используются в процессе проверки ПО, так как тесты основываются на определённых требованиях. Этапу разработки требований, возможно, предшествовало технико-экономическое обоснование, или концептуальная фаза анализа проекта. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификация (документирование требований) и проверка правильности.
Этапы - описания и анализа предметной области, построения логических моделей данных, алгоритмов, их взаимодействия и представления пользователю. Инструменты – возможности, технологии, методики работы. Классификация программных продуктов по: 1) областям применения – офисные, графические, системы управления (объектами и субъектами), экспертные и др.; 2) интерфейсу пользователя – текстовой, графический, мальтимедийный; 3)уровню защиты и надежности; 3) времени реакции на запрос; 4) операционной среде; 5) типу входных, выходных, обрабатываемых данных; и др.
Диаграммы UML и цепочка построения диаграммы классов. Rational Rose – инструмент реализующий методологию UML. Другие визуальные инструменты реализующие подобные задачи Описание функциональности разработки – диаграммы вариантов использования (требования и ограничения), детализация функций – диаграммы последовательности действий (требования и ограничения), описание взаимодействия и взаимосуществования элементов разработки – кооперативные диаграммы (требования и ограничения).
Методики проектирования моделей представления информации и алгоритмов. Составление словаря предметной области – текстуальное описание, выделение существенных признаков и их идентификация, таблицы - характеристики сущностей, выявление по частотным характеристикам использования. Методы декомпозиции и структурирования.
58.Перспективы инструментальных средств
Следует обратить внимание на необходимость создания принципиально новых инструментов, а не излишней шлифовке давно существующих. В ряде случаев шлифовка подобна улучшению молотка путем раскрашивания его ручки хохломской росписью.
Воздействие сети Интернет на развитие систем программирования также велико. Перспективными направлениями развития систем программирования в Интернете являются:
проектирование и реализация инструментария, обеспечивающего кросс-платформенную разработку приложений на языках Java, С и C++ в средах ОС Unix и Windows NT;
разработка инструментария для эффективного написания программ, поддерживающих распределенные вычисления;
разработка высокопроизводительных систем программирования;
разработка средств отладки Интернет-приложений;
разработка инструментария с высоким уровнем абстракции для проектирования интерфейсов.
Упомянем и возможности, которые предлагает Интернет для доставки систем программирования до пользователя.
Пусть нам потребовался высокопроизводительный оптимизирующий компилятор с языка программирования C++ для SPARC-архитектуры. Два его наиболее удачных варианта.
Профессиональный коммерческий C++ компилятор компании Sun Microsystems Inc.
Свободно распространяемый под General Public License (GPL) лицензией C++
Интернет содержит достаточное количество ресурсов и для образовательных целей. Конечно, особый интерес для ВУЗов представляют свободно распространяемые программы. Многие учебные заведения используют язык Pascal для первоначального обучения программированию. В Интернете можно найти свободно распространяемые компиляторы с языка Pascal:
Free Pascal
GNU Pascal
Среди других доступны компиляторы с языков С, C++, Eiffel, Lisp, Clos, FORTRAN и многие другие.

Приложенные файлы

  • docx 8832343
    Размер файла: 969 kB Загрузок: 0

Добавить комментарий