Виртуальные методы

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

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

Билет № 25. Абстрактные методы и классы

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

Абстрактный метод создается с помощью модификатора abstract. Он не имеет тела и, следовательно, не реализуется базовым классом, а производные классы должны его обязательно переопределить. Абстрактный метод автоматически является виртуальным, однако использовать спецификатор virtual не нужно. Более того, если вы попытаетесь использовать два спецификатора одновременно, abstract и virtual, то компилятор выдаст сообщение об ошибке.

Если класс содержит один или несколько абстрактных классов, то его также нужно объявить как абстрактный, используя спецификатор abstract перед class. Поскольку абстрактный класс полностью не реализован, то невозможно создать экземпляр класса с помощью операции new. Например, если класс Demo определен как абстрактный, то попытка создать экземпляр класса Demo повлечет ошибку:

Demo a = new Demo();

Однако, можно создать массив ссылок, используя этот же абстрактный класс:

Demo [] Ob=new Demo[5];

Если производный класс наследует абстрактный, то он должен полностью переопределить все абстрактные методы базового класса или также быть объявлен как абстрактный. Таким образом, спецификатор abstract наследуется до тех пор, пока в производном классе не будут реализованы все абстрактные методы.

Билет №27. Стандартные интерфейсы .Net.

Стандартные интерфейсы .Net

В библиотеке классов .Net определено множество стандартных интерфейсов, задающих желаемую функциональность объектов. Например, интерфейс IComparable задает метод сравнения объектов по принципу больше и меньше, что позволяет переопределить соответствующие операции в рамках класса, наследующего интерфейс IComparable. Реализация интерфейсов IEnumerable и IEnumerator дает возможность просматривать содержимое объекта с помощью оператора foreach.

Можно создавать собственные классы, реализующие стандартные интерфейсы, что позволит использовать объекты этих классов стандартными способами.

Более подробно рассмотрим стандартный интерфейс IComparable.

Интерфейс IComparable определен в пространстве имен System и содержит единственный метод CompareTo, возвращающий результат сравнения двух объектов – текущего и переданного ему в качестве параметра:

interface IComparable

{

int CompareTo(object obj);

}

Реализация данного метода должна возвращать:

1. 0 – если текущий объект и параметр равны;

2. отрицательное число, если текущий объект меньше параметра;

3. положительное число, если текущий объект больше параметра.

Используя собственную реализацию метода CompareTo можно перегрузить операции отношения. Напомним, что операции отношения должны перегружаться парами: < и >, <= и >=, == и !=.

Билет №28. Структуры.

Структуры

Классы, как вы уже знаете, являются ссылочными данными. Это означает, что к экземплярам классов можно обратиться только через ссылку. В С# реализован тип данных, аналогичный классу, но который в отличие от классов является размерным типом. Таким типом является структура.

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

1. определять конструктор по умолчанию, поскольку он определен неявно и присваивает всем своим элементам значения по умолчанию (нули соответствующего типа);

2. определять деструктор, поскольку это бессмысленно.

Синтаксис структуры:

[атрибуты][спецификаторы] struct имя_структуры [: интерфейсы]

{

тело_структуры

}

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

Интерфейсы, реализуемые структурой, перечисляются через запятую.

Тело структуры может содержать: константы, поля, конструкторы, методы, свойства, индексаторы, операторные методы, вложенные типы и события.

При описании структуры задавать значение по умолчанию можно только для статических полей. Остальным полям с помощью конструктора по умолчанию будут присвоены нули для полей размерных типов и null для полей ссылочных типов.

Параметр this интерпретируется как значение, поэтому его можно использовать для ссылок, но не для присваивания.

Так как структуры не могут участвовать в иерархии, то для ее членов недопустимо использовать спецификаторы protected и protected internal. Методы структур не могут быть абстрактными и виртуальными. А переопределяться могут только те методы, которые унаследованы от базового класса object.

Экземпляр структуры, как и экземпляр класса, создаются с помощью оператора new, но это не обязательно. Если оператор new не используется, то структура все равно создается, но не инициализируется. Если при объявлении структуры не был вызван конструктор, то поля нужно инициализировать вручную:

Так как структуры являются размерными типами, то присваивание одной структуры другой создает копию экземпляра структуры. Этот факт является важным отличием структуры от класса.

Билет №29. Классификация ИС.

Информационная система (ИС) в целом - автоматизированная система, предназначенная для организации, хранения, пополнения, поддержки и представления пользователям информации в соответствии с их запросами.

Классификация по архитектуре

По степени распределённости:

• настольные (desktop), или локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере;

• распределённые (distributed) ИС, в которых компоненты распределены по нескольким компьютерам.

Распределённые ИС разделяют на:

• файл-серверные ИС (ИС с архитектурой «файл-сервер»). В файл-серверных ИС база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях.

• клиент-серверные ИС (ИС с архитектурой «клиент-сервер»). В клиент-серверных ИС база данных и СУБД находятся на сервере, а на рабочих станциях находятся клиентские приложения.

Клиент-серверные ИС разделяют на:

• В двухзвенных (англ. two-tier) ИС всего два типа «звеньев»: сервер баз данных, на котором находятся БД и СУБД,и рабочие станции, на которых находятся клиентские приложения. Клиентские приложения обращаются к СУБД напрямую.

• В многозвенных (англ. multi-tier) ИС добавляются промежуточные «звенья»: серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями. Типичный пример применения многозвенности — современные веб-приложения, использующие базы данных. В таких приложениях помимо звена СУБД и клиентского звена, выполняющегося в веб-браузере, имеется как минимум одно промежуточное звено — веб-сервер с соответствующим серверным программным обеспечением.

Классификация по степени автоматизации

• автоматизированные: информационные системы, в которых автоматизация может быть неполной (то есть требуется постоянное вмешательство персонала);

• автоматические: информационные системы, в которых автоматизация является полной, то есть вмешательство персонала не требуется или требуется только эпизодически.

Классификация по охвату задач (масштабности)

• Персональная ИС предназначена для решения некоторого круга задач одного человека.

• Групповая ИС ориентирована на коллективное использование информации членами рабочей группы или подразделения.

• Корпоративная ИС в идеале охватывает все информационные процессы целого предприятия, достигая их полной согласованности, безызбыточности и прозрачности. Такие системы иногда называют системами комплексной автоматизации предприятия.

Классификация по характеру обработки данных

• информационно-справочные, или информационно-поисковые ИС, в которых нет сложных алгоритмов обработки данных, а целью системы является поиск и выдача информации в удобном виде;

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

Классификация по сфере применения

Поскольку ИС создаются для удовлетворения информационных потребностей в рамках конкретной предметной области, то каждой предметной области (сфере применения) соответствует свой тип ИС.

• Экономическая информационная система — информационная система, предназначенная для выполнения функций управления на предприятии.

• Медицинская информационная система — информационная система, предназначенная для использования в лечебном или лечебно-профилактическом учреждении.

• Географическая информационная система — информационная система, обеспечивающая сбор, хранение, обработку, доступ, отображение и распространение пространственно-координированных данных (пространственных данных).

Билет №30. Основные стадии создания ИС. Этап обследования предприятия. Этап обработки результатов обследования.

Основные стадии создания АИС

• Обследование предприятия

• Обработка полученной информации

• Формирование ТЗ на систему

• Составление концептуального проекта

• Реализация системы

Этап обследования предприятия

Обследование предприятия (может проводиться два раза, первый раз по укороченной программе с целью ознакомления с объектом и выработкой концептуального (чернового) проекта АИС; второй — полное обследование производства после заключения договора и подписания технического задания (ТЗ может быть заменено специфицированным описанием будущей компьютерной системы). Работы ведутся квалифицированным персоналом, в зависимости от количества специалистов, размеров предприятия и создаваемой системы, в среднем, могут выполняться в сроки от 6 месяцев до 1 года. Так как данный этап является длительным разработку желательно вести параллельно.

На основе собранного материала можно создать пакет черновой АИС, подобрать прототип или купить макет, можно использовать готовые разработки. Часто выбирается вариант разработки комплексов задач. На данном этапе необходимо выяснить:

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

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

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

Этап обработки результатов обследования

Цель данного этапа получить комплексное представление о предприятии, объекте, получить формальное описание, уточнить перечень и количество задач и функций, выполняемых подразделениями, составить схему документа оборота, составить схему информационных связей (модель), производственных структур, служб материально-технического снабжения, складов, составить схему движения материального потока. Если предприятие состоит из отдельных финансовых объектов составить схему финансового оборота. На этом же этапе можно подготовить предварительные схемы информационных связей для ограниченного количества финансовых задач (бух. учет, движение материальных средств, планирование производства и т.д.). Подготовить материалы для технико-экономического обоснования (ТЭО) проекта. Выработать и подготовить положение по необходимым изменениям структуры объекта, по функциям подразделений, по ликвидации параллельных информационных потоков, т.е. надо подробно описать структуру организации предприятия и утвердить у руководства. К проведению данной работы привлекаются высоко квалифицированные специалисты, их можно использовать по различным направлениям или по иерархическому принципу.

Главная задача систематизировать весь собранный материал и на его основании составить грубую схему АИС для исследуемого объекта.

Билет №31. Формирование технического задания (ТЗ). Этап составления общей схемы (проекта ИС). Реализация системы.

Формирование технического задания (ТЗ)

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

Техническое задание должно состоять из следующих разделов:

1. Наименование;

2. Основание для создания;

3. Назначение и цель;

4. Требования к АИС;

5. Состав, содержание, ограничение работ по подготовке объекта к вводу АИС в действие;

6. Показатели эффективности АИС;

7. Порядок контроля и приемки АИС;

8. Источники разработки.

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

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

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

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

Обычно ТЗ включает экономическое обоснование — это экономические затраты на создание системы, направление за счет которого будет получен экономический эффект и его расчет.

Билет №32. Содержание работ на этапах создания ИС. Организация предпроектного обследования. Организация работ на стадии технического проектирования.

Содержание работ на этапах создания АИС

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

Внедрение разработанной системы - это процесс постепенного перехода от существующей системы обработки данных к новой, автоматизированной.

Организация предпроектного обследования

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

На этой стадии исследуются экономические показатели работы предприятия или учреждения, его организационная структура, информационные потоки, документооборот, методы учета и планирования. Обследование способствует определению основных параметров проектируемой системы и подразумевает сбор данных об объекте автоматизации в соответствии с конкретно выбранными методами. Важным этапом на этой стадии является анализ результатов обследования, который учитывая характер собранных данных, их объем, и, как правило, жесткие сроки, целесообразно проводить с применением ВТ. Цель такого обследования заключается в определении экономической целесообразности автоматизации и подготовке научно обоснованных, рациональных направлений по совершенствованию управления. От качества проведенного обследования зависит весь дальнейший ход проектных работ. На этой стадии можно выделить два этапа, которые завершаются подготовкой и утверждением двух документов: ТЭО и ТЗ.

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

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

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

Организация работ на стадии технического проектирования

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

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

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

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

Билет №33. Организация работ на стадии рабочего проектирования. Организация работ на стадии внедрения системы.

Организация работ на стадии рабочего проектирования

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

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

Программная документация рабочего проекта включает:

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

• Руководство оператора, в составе которого можно выделить описание его действий при запросах программы, правила организации программ на внешних носителях, тестирование.

• Эксплуатационные программы, если используется ППП, или тексты программ.

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

В состав технических инструкций, которые, как правило, являются типовыми, входят инструкции по: сбору, регистрации, контролю и передаче информации; переносу ее на машинные носители, ведению архива носителей документов; порядку передачи выходной, результатной информации. Должностные инструкции определяют права и обязанности производственного и управленческого персонала при эксплуатации АИС, регламентируют их действия в новых условиях производства.

Организация работ на стадии внедрения системы

Внедрение разработанной системы - это процесс постепенного перехода от существующей системы обработки данных к новой, автоматизированной.

Ввод в эксплуатацию проводится силами заказчика при участии разработчика и осуществляется поэтапно:

• подготовка объекта к внедрению АИС

• опытная эксплуатация отдельных задач или их комплексов

• сдача системы в промышленную эксплуатацию.

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

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

Билет №34. Средства автоматизации проектирования ИС. Основные возможности СASЕ-средств.

Максимально упростить и формализовать процессы формирования системы позволяют современные case-средства. Они основаны на применении наглядной графической техники ( схемы и диаграммы) предназначенные для описания различного рода моделей.

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

Большинство современных case-средств поддерживает методологии структурного и объектно-ориентированного анализа и проектирования ИС.

Основные функции case-средств:

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

2. Единая база данных проекта. Основа case-технологий это использование базы данных проекта (репозитория) для хранения всей информации о проекте , которая может совместно использоваться разработчиками в соответствии с их правами доступа. Содержимое репозитория включает графические объекты различных типов, отношения между их компонентами, правила использования ими обработки этих компонентов.

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

4. Маркетирование. Позволяет быстро строить макеты (прототипы) будущей системы, что позволяет заказчику на разных этапах разработки оценить насколько она приемлема для будущих пользователей.

5. Генерация документации. Вся документация по проекту генерируется автоматически на базе репозитория.

6. Верификация проекта. Обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки.

7. Автоматическая генерация программного кода.

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

Билет №35. Средства быстрой разработки приложений.

Быстрая разработка приложений (RAD- Rapid Application Development) основывается на визуализации процесса создания программного кода. Технологии RAD представляют программисту средства ускоряющие разработку программ, их модификацию и оплату. Для максимального упрощения работы используются графические инструменты, основанные на компонентной архитектуре. Каждый компонент является объектом, объединяющих в себе данные, методы и свойства для работы с ними. При этом компоненты являются объектами, которые позволяют изменять данные и свойства объектов. Свойства позволяют работать с данными также как и с членами классов, а с другой стороны скрывают за операциями чтения и записи вызовы методов, переводя операции над объектами на более высокий уровень абстракции. Для разработки и проектирования пользовательского интерфейса используются инструменты визуального проектирования( экранный редактор…), которые позволяют выполнять следующие операции: размещение компонента интерфейса в нужном месте, задание моментов времени их появления на экране, настройка связанных с ними атрибутов и событий. Эффективность визуального программирования определено наличием визуальных компонентов и их взаимодействием с традиционными средствами.

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

Билет № 36. Разработка информационных систем на основе шаблонов. Шаблоны на этапе анализа, построения архитектуры решений, кода, шаблоны тестов.

Шаблон проектирования или паттерн (англ. design pattern) в разработке программного обеспечения — повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.

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

Классификация паттернов

Архитектурные паттерны, являются наиболее высокоуровневыми паттернами, описывают структурную схему программной системы в целом. В данной схеме указываются отдельные функциональные составляющие системы, называемые подсистемами, а также взаимоотношения между ними. Архитектурные паттерны (Architectural patterns) - множество предварительно определенных подсистем со спецификацией их ответственности, правил и базовых принципов установления отношений между ними. Архитектурные паттерны предназначены для спецификации фундаментальных схем структуризации программных систем. Наиболее известными паттернами этой категории являются паттерны GRASP (General Responsibility Assignment Software Pattern). Эти паттерны относятся к уровню системы и подсистем, но не к уровню классов. Как правило, формулируются в обобщенной форме, используют обычную терминологию и не зависят от области приложения.

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

Паттерны проектирования описывают схемы детализации программных подсистем и отношений между ними, при этом они не влияют на структуру программной системы в целом и сохраняют независимость от реализации языка программирования. Паттерны GoF относятся именно к этой категории. Под паттернами проектирования объектно-ориентированных систем понимается описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте. В русскоязычной литературе обычно встречаются несколько вариантов перевода оригинального названия design patterns - паттерны проектирования, шаблоны проектирования, образцы. Здесь в основном используется первый вариант, иногда второй. Наиболее известными паттернами этой категории являются паттерны GoF (Gang of Four), названные в честь Э. Гаммы, Р. Хелма, Р. Джонсона и Дж. Влиссидеса, которые систематизировали их и представили общее описание. Паттерны GoF включают в себя 23 паттерна. Эти паттерны не зависит от языка реализации, но их реализация зависит от области приложения.

Идиомы, являясь низкоуровневыми паттернами, имеют дело с вопросами реализации какой-либо проблемы с учетом особенностей данного языка программирования. При этом часто одни и те же идиомы для разных языков программирования выглядят по-разному или не имеют смысла вовсе. Например, в C++ для устранения возможных утечек памяти могут использоваться интеллектуальные указатели. Интеллектуальный указатель содержит указатель на участок динамически выделенной памяти, который будет автоматически освобожден при выходе из зоны видимости. В среде Java такой проблемы просто не существует, так как там используется автоматическая сборка мусора. Обычно, для использования идиом нужно глубоко знать особенности применяемого языка программирования.

Паттерны реализации (Implementation patterns) - совокупность компонентов и других элементов реализации, используемых в структуре модели при написании программного кода. Эта категория паттернов делится на следующие подкатегории: паттерны организации программного кода, паттерны оптимизации программного кода, паттерны устойчивости кода, паттерны разработки графического интерфейса пользователя и др. Паттерны этой категории описаны в работах М. Гранда, К. Бека, Дж. Тидвелла и др. Некоторые из них реализованы в популярных интегрированных средах программирования в форме шаблонов создаваемых проектов. В этом случае выбор шаблона программного приложения позволяет получить некоторую заготовку программного кода.

Паттерны анализа (Analysis patterns) - специальные схемы для представления общей организации процесса моделирования. Паттерны анализа относятся к одной или нескольким предметным областям и описываются в терминах предметной области. Наиболее известными паттернами этой группы являются паттерны бизнес-моделирования ARIS (Architecture of Integrated Information Systems), которые характеризуют абстрактный уровень представления бизнес-процессов. В дальнейшем паттерны анализа конкретизируются в типовых моделях с целью выполнения аналитических оценок или имитационного моделирования бизнес-процессов.

процесса тестирования программных систем. К этой категории паттернов относятся такие паттерны, как тестирование черного ящика, белого ящика, отдельных классов, системы. Паттерны этой категории систематизировал и описал М. Гранд. Некоторые из них реализованы в инструментальных средствах, наиболее известными из которых является IBM Test Studio. В связи с этим паттерны тестирования иногда называют стратегиями или схемами тестирования.

Билет №38. Современные технологии тестирования. Основные понятия тестирования. Фазы и этапы тестирования.

Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения. С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных. Из сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам. При разработки программ тестирование занимает 40 % от суммарной трудоемкости разработки продукта.

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

Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования (– Testbed или Testbench.)

Фазы тестирования:

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

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

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

Этапы тестирования:

Каждая фаза тестирования включает в себя следующие этапы:

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

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

3. Разработка тестов (тестового кода для тестируемой системы)

4. Выполнение тестов: реализация тестовых циклов.

5. Анализ результатов.

Билет №39. Типы тестов. Разработка, управляемая тестами (Test Driven Development).

Типы тестов:

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

• Тестирование основной функциональности, когда тестированию подвергается собственно система, являющаяся основным выпускаемым продуктом

• Тестирование инсталляции включает тестирование сценариев первичной инсталляции системы, сценариев повторной инсталляции (поверх уже существующей копии), тестирование деинсталляции, тестирование инсталляции в условиях наличия ошибок в инсталлируемом пакете, в окружении или в сценарии и т.п.

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

Типы тестирования по способу выбора входных значений:

• Функциональное тестирование, при котором проверяется:

  • Покрытие функциональных требований.

  • Покрытие сценариев использования.

• Стрессовое тестирование, при котором проверяются экстремальные режимы использования продукта.

• Тестирование граничных значений.

• Тестирование производительности.

• Тестирование на соответствие стандартам.

• Тестирование совместимости с другими программно-аппаратными комплексами.

• Тестирование работы с окружением.

• Тестирование работы на конкретной платформе

Test Driven Development:

• Разработка через тестирование (Test Driven Development – TDD) - процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы.

TDD определяет следующий порядок этапов программирования:

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

• Зеленый – заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.

• Рефакторинг – удалите из написанного вами кода любое дублирование.

• Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными.