1.3 Выбор средств разработки программного обеспечения
В настоящее время существует огромное количество программных продуктов, позволяющих в сжатые сроки эффективно и качественно разработать программный комплекс для различных предметных областей.
К ним относятся такие программные средства, как Delphi, Visual C++, С Builder, Visual Basic, Java Builder;
Использование средств этого типа оправдано, когда необходимо в сжатые сроки создать приложение с удобным и понятным графическим интерфейсом.
Приняв во внимание вышеперечисленные аргументы, для разрабатываемого программно-методического комплекса целесообразно использовать средства типа RAD.
Для функционирования программного комплекса, необходима также некоторая программная среда, в простейшем случае представленная операционной системой. В более сложных случаях, когда система работает с большим количеством данных, которые необходимо поддерживать в актуальном состоянии, должна присутствовать некоторая СУБД.
Для правильного и обоснованного выбора RAD-средства необходима оценка продуктов по определенным критериям экспертами. Получить оценку продуктов можно из специальных источников. Но эта оценка дается, учитывая специфику разработки приложения. Более или менее рациональный выбор средства разработки приложения можно сделать только в контексте конкретного проекта или конкретной организации, ведущей разработку.
Поэтому для правильной оценки средств разработки приложения нужна оценка экспертов, ознакомленных со спецификой разрабатываемого приложения, с вопросами его дальнейшей модификации и сопровождения. Ввиду невозможности получить такую оценку от признанных экспертов и не достаточной серьезности разрабатываемого приложения, решил в качестве экспертов принять студентов группы и других лиц, занимающихся разработкой программ.
Во внимание принимались различные критерии для оценки качества программного продукта, в частности такие, которые учитывают аспекты разрабатываемого программного продукта:
Доступность программных средств разработки и реализации;
Cоответствие выбираемых программных средств уровню подготовленности программиста;
Возможности программных средств для разработки профессиональных приложений и сложных программных систем;
Оценка качества средств с точки зрения надежности, производительности, удобства работы и трудоемкости их эксплуатации;
Перспективность и жизнеспособность фирм изготовителей программных средств, возможность обновления и наличия новых версий продуктов при модернизации программно-технической среды;
Возможность перехода от однопользовательского варианта (для отладки и локального применения) к сетевому, для средств разработки и средств эксплуатации, а также его сложность;
Стыковка с широким спектром других СУБД и возможности переноса БД для данного программного средства на другие СУБД;
Возможность подключения к корпоративным сетям и Интернет/Интранет, поддержка постоянно развивающихся WEB технологий;
Модульный принцип построения, степень ее универсальности.
Наличие документации на русском языке, справочных систем, документации в печатном и электронном исполнении, возможности консультаций;
Простота языка программирования;
Скорость работы приложения;
Скорость компиляции приложения;
Наличие интегрированного отладчика;
Обработка исключительных ситуаций;
Методика определения подходящего программного продукта заключается в следующем.
Сначала выбирается несколько доступных и известных программных продуктов. Мною для рассмотрения были выбраны Delphi 5.0, Visual C++ 6.0 и Visual Basic. Каждому критерию назначил вес, исходя из целей проектирования таким образом, что сумма весов всех критериев равнялась 1.
Потом по каждому из параметров критерия давалась оценка программному продукту по десятибалльной шкале, и считалась интегральная оценка по каждому программному продукту по формуле 1.1.
В качестве экспертов, который ставили экспертную оценку, выступали студенты пятого курса группы ИТ98-1
Вычисления по формуле (1.1) сведены в таблицу 1.2.
Как видно из таблицы 1.2 наиболее подходящим средством для разработки программного комплекса является Delphi 5.0.
Таблица 1.2 - Сравнение программных продуктов
1.4 Техническое задание 1.4.1 Введение
Программный комплекс предназначен для создания курса обучения дисциплине и для обучения дисциплине.
1.4.2 Основания для разработки
Разработка программного комплекса ведется на основании задания на дипломную работу, утвержденное приказом ректора Донбасской машиностроительной академии по ГОСТ 19.101-77.
Тема дипломной работы – «Программно – методический комплекс для мультимедийного представления учебной информации».
Спецчасть разработки – «Разработка программного обеспечения для интерфейса оболочки комплекса и примера информационного наполнения»
1.4.3 Назначение разработки
Программный комплекс предназначен для создания большого числа обучающих дисков по разным дисциплинам. Включает интерфейс для создания курса обучения и оболочку для обучения.
1.4.4 Требования к программному изделию 1.4.4.1 Требования к функциональным характеристикам
Программный комплекс должен выполнять следующие функции:
Предоставлять возможность ввода лекций и другого учебного материала с рисунками, видео и звуковым сопровождением;
Предоставлять возможность изменения курса;
Предоставлять возможность проходить курс(обучаться);
Предоставлять возможность контролировать полученные знания;
Предоставлять возможность поиска по всему курсу.
1.4.4.2 Требования к надежности
Программный комплекс должен устойчиво функционировать и не приводить к зависанию операционной системы в аварийных ситуациях.
Контроль формируемого учебного материала возложен на пользователя, который создает учебный курс.
1.4.4.3 Условия эксплуатации
Температура окружающего воздуха, влажность и другие параметры микроклимата должны соответствовать требованиям к помещениям, оборудованным персональными ЭВМ.
Для создания учебного курса необходим человек – преподаватель или пользователь, который будет заводить материал. Человек должен обладать навыками работы с персональной ЭВМ, оснащенной операционной системой Windows.
1.4.4.4 Требования к составу и параметрам технических средств
Для нормального функционирования программного комплекса необходима персональная ЭВМ со следующими характеристиками:
Объем оперативной памяти не менее 32 мегабайт;
Процессор не ниже Pentium 166, мышь, клавиатура;
Наличие свободного места на жестком диске в размере не менее 5 мегабайт;
Дисковод на 3,5’’;
Монитор SVGA.
1.5.4.5 Требования к информационной и программной совместимости
Программа должна функционировать под операционной системой Windows. Должна быть установлена программа BDE Administrator для работы с базами. Исходные коды программы должны быть написаны на языке Object Pascal в среде разработки Delphi 5.0. Информация должна вводиться непосредственно через GUI. Результат визуализации информации должен быть представлен в хорошо воспринимаемом виде.
1.4.4.6 Требования к программной документации
Предварительный состав программной документации установлен в соответствии с ГОСТ 19.101-77. Ниже перечислен список программных документов и их содержание.
Текст программы – запись программы с необходимыми пояснениями и комментариями.
Описание программы – сведения о логической структуре и функционировании программы.
Программа и методика испытаний – требования, подлежащие проверке при испытании программы, также порядок и методы контроля.
Техническое задание – настоящий документ.
Пояснительная записка – результаты исследования структур представления информации, общее описание функционирования программы, а также обоснование принятых технических и технико-экономических решений.
1.4.5 Стадии и этапы разработки
Стадии и этапы разработки должны соответствовать ГОСТ 19.101-77 и состоять из следующих пунктов.
1 Техническое задание – черновое определение требований к программному комплексу и программной документации.
2 Эскизный проект – разработка структур представления информации в программном комплексе, разработка структуры классов, необходимых для реализации поставленного алгоритма. Формулировка методов реализации вложенности в программном комплексе, разработка структуры программы.
3 Технический проект – уточнение структуры классов и методов представления информации. Детальное уточнение метода реализации вложенности. Разработка структуры программы.
4 Рабочий проект – разработка программы, разработка программной документации, испытание программы.
1.4.6 Порядок контроля и приемки
Разработанное программное обеспечение должно соответствовать требованиям заказчика и отвечать всем поставленным функциональным требованиям. Программа должна быть протестирована на возможность возникновения исключительных ситуаций и должна быть сделана соответствующая рецензия.
1.5 Разработка математической модели
Очень важным этапом при создании электронного учебника является выбор материалов для обучения и стрктура представления этих материалов.
Предлагаются следующие шаги для составления курса обучения:
Методическая разработка темы обучающей программы.
Анализом результатов специальных модельных экспериментов разработать модель главы для профильного учебника.
Определить требования к программному продукту, с помощью которого можно педагогам образовательных учреждений создавать электронные учебники для профильной школы с учетом уровня подготовки педагогов к использованию компьютера.
Разработать пакет программных средств, предназначенный для разработки электронных средств учебного назначения: информационных и экспертных систем, электронных учебников, специальных средств для изучения учащихся.
Предложить технологию разработки электронных учебников для профильного обучения с помощью пакета.
Разработать ряд учебников и провести эксперименты по их проверке с учащимися и педагогами.
На основе анализа электронных средств, созданных педагогами и специальных исследований разработать новый проект программных средств для создания электронных учебников.
При разработке учебника необходимо учитывать: интересы учащихся, их психологически особенности, отношение к предмету и педагогу, возможности учащихся выполнить творческие задания и ориентация на него, затруднения школьников в изучении предмета и виды помощи, которые они предпочитают.
Этапы разработки электронного учебника можно представить в виде схемы, изображенной на рисунке 1.2.
В учебнике требуется уделить специальное внимание мотивации обучающихся к изучению каждой темы. Общими моментами в данной плоскости являются: возможности применения математики в соответствующей предметной области, необходимость сдачи экзаменов.
Возможность накопить опыт творческой деятельности в разных предметных областях, знакомство с интересными применениями ЭВМ.
Учебник должен обеспечить возможность ученику выбрать не только уровень, на котором будет изучать учебный материал темы, но и разный способ изучения темы (не менее двух способов). При этом ученик должен осознать, что он и только он отвечает за свой выбор уровня изучения темы.
Рисунок 1.2 - Этапы разработки ЭУ
Учебник призван защитить обучаемых от перегрузки. В частности, этому служит раздел домашних заданий по новому материалу (в нем представлены минимальное число задания, которые будут предложены на дом и при выполнении которых студенту вновь предстоит выбирать уровень сложности).
В учебнике должен быть специальный тренажер, обращаясь к которому по своей инициативе ученик может не только отработать алгоритмы решения основных типов задач, но и учиться: отказываться от известного метода решения задач и находить другие методы, составлять задачи, искать и исправлять ошибки в решении задач, проводить анализ ситуаций разными способами и др.
В учебнике должен быть раздел личного мониторинга, предназначенный для учащихся, которые до проведения контрольной работы хотят оценить результаты своей работы над темой и своевременно внести необходимые коррективы, хотят узнать прогноз результата выполнения контрольной и получить указание от компьютера, каким образом можно его улучшить.
Предусмотрены различные виды помощи ученикам. Особенно важным является включение специальной экспертной системы, которая предназначена не только для оказания помощи ученикам в решении конкретных задач на уроке или дома, но и ориентирована на передачу опыта автора учебника с разными элементами учебника.
Раздел творческих заданий, в котором предлагаются возможные проекты для нужд учебного заведения и для участия в конференциях и конкурсах, проводимых как внутри учебного заведения, так и вне его.
Важно, чтобы учебник можно было существенно изменять и дополнять на основе не только разработок автора учебника, учителя, который его использует, но и учащимися вместе с учителем на основе проектов, выполненных учениками и с учетом особенностей образовательного учреждения и профиля класса. Вот одна иллюстрация: учебник по математике для гуманитарных классов может быть переведен учащимися на те иностранные языки, которые изучают учащиеся. В этом случае новые ученики, использующие дополненный вариант электронного учебника, получают новый возможный вариант изучения темы – изучать тему на иностранном языке.
Существенно, чтобы обучающиеся знакомились с опытом выполнения каких-то работ, которые являются важными для профиля класса, которые вызывают известные затруднения учащихся и которые выполнены их сверстниками. Это достигается за счет включения в учебник разделов, в которых представлены разные варианты выполнения одних и тех же заданий учениками, изучавшими материал с помощью электронного учебника (к примеру, на рефлексию или систематизацию, на составление задач и др.) и анализ выполнения, выполненные учениками и автором электронного учебника.
Исходя из вышеперечисленного предлагается структура материалов, приведенная на рисунке 1.3.
1.6 Разработка компонентов программного комплекса 1.6.1 Разработка логической модели программного комплекса
Одним из способов при описании логической модели программного комплекса является структурный анализ.
Сущность структурного подхода заключается в декомпозиции (разбиении) системы на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов . В качестве двух базовых принципов используются следующие:
Принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
Принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из
них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:
Принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
Рискнок 1.3- Структура материалов
Принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
Принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
Принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
DFD (Data Flow Diagrams) диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь";
На уроках біології. [Електронний ресурс]. Режим доступу: http: // www. nenc.gov.ua / index.php? id=79. – Заголовок з титул. екрана. АНОТАЦІЇ Сліпчук І.Ю. Методика навчання біології учнів 8-9 класів з використанням комп’ютерних технологій. – Рукопис. Дисертація на здобуття наукового ступеня кандидата педагогічних наук за спеціальністю 13.00.02 – теорія та методика навчання (біологія). – Наці ...
Сферы интеллектуальной деятельности, принесло с собой совершенно новые представления о возможностях обработки информации, новые приемы и формы работы, новый уровень информационной обеспеченности общества. В этом смысле есть все основания говорить о наступлении эры компьютерных технологий как о новом витке цивилизации. Кстати, выражение "компьютерная цивилизация" действительно есть, оно реально...
Согласно классической классификации принципов программирования было выделено процедурное и декларативное программирование, а также их разновидности: императивное, функциональное, объектно-ориентированное, логическое, экспертных систем и на основе индукции . Эти принципы до определенного момента применялись в рамках идеологии построения целевых информационных систем, предназначенных решать определенный спектр задач. Впоследствии, постоянный рост потребностей человечества в глобальном общении заставило изменить идеологию принципов программирования.
Представлены многими платформами, которые постоянно дополняются более новыми и узко специализированными.
Для программных продуктов глобального информационного общества характерны высокие требования к их коммуникативных составляющих. Это обусловило переход от создания монолитных решений для создания компонентов, допускающих свое повторное использование в различных средах и программных приложениях.
Идеология разработки в ИТ
Изменение идеологии в разработке программных систем была отмечена ведущими представителями IT индустрии, появлением качественно нового поколения программных продуктов. Некоторые производители программных систем информируют рынок о принадлежности продукции к открытой идеологии, наделяя их характерными внешними признаками. В частности, для продуктов фирмы Microsoft, выпущенных с начала 21 века, характерно окончание названия. Net (читается как Dot Net). Опираясь именно на эти решения, в дальнейшем будет проведено рассмотрение сущности идеологии открытого программирования.
Одной из практических реализаций идеологии открытого программирования является, реализованная в последних версиях Microsoft Visual Studio, открытость для языков программирования. Она заключается в использовании многоязычного среды разработки. То есть, в среду разработки приложений Visual Studio последних версий, вместе с языками программирования, включенных фирмой Microsoft (Visual C + +, Visual C , J . Net, Visual Basic. Net), могут добавляться любые языки программирования, компиляторы которых создаются другими фирмами -производителями. На сегодняшний день, таких расширений среды Visual Studio сделано уже достаточно много, практически, они существуют для всех известных языков (Fortran, Cobol, Component Pascal, Oberon и др.).
Открытость среды не означает полной свободы. Все разработчики компиляторов, при введении нового языка в среду разработки, должны придерживаться установленных правил и ограничений. Главное ограничение, которое, одновременно, можно считать и достоинством, заключается в том, что все языки, которые включаются в среду разработки Visual Studio, должны использовать единый каркас — Framework.Net.
Каркас приложений
Понятие каркаса приложений — Framework Applications появляется в литературных источниках со второй половины 90-х годов прошлого столетия в описаниях применения Visual Studio, начиная с четвертой версии. Роль каркаса приложений Visual C + + в ранних версиях Visual Studio выполняла библиотека классов MFC (Microsoft Foundation Classes). Библиотека классов MFC изначально представляла собой иерархически организованную коллекцию классов, в которую входили классы, способные создавать архитектуру новых приложений. Выбирая тип приложения, разработчик получал нужную функциональную платформу, образовывалась и поддерживалась объектами классов каркаса.
Например, когда разработчик выбирал из возможных типов приложений архитектуру «Документ-Представление», то в его приложение автоматически встраивались класс Document, ответственный за структуру документа и класс View — ответственный за его визуальное представление. Класс Form, вместе с другими классами, которые реализовывали элементы управления, обеспечивали унифицированный интерфейс приложений.
В течение последующих лет, роль каркаса в построении приложений существенно возросла за счет расширения его возможностей до уровня Framework.NET. Сегодня, каркас Microsoft Framework.NET является платформой для создания, развертывания и запуска приложений. Она предоставляет высокопроизводительное, основанное на стандартах многоязыковую среду, которая позволяет интегрировать существующие приложения с приложениями и сервисами следующих поколений.
Благодаря применению единого каркаса Framework.Net достигаются следующие преимущества:
- возможность использования компонентов, разработанных на разных языках;
- возможность разработки нескольких частей одного приложения на различных языках программирования;
- возможность бесшовной отладки многоязычного приложения;
- возможность создать класс на одном языке, а его потомки — другие языки.
Единый каркас стимулирует сближение языков программирования, позволяя вместе с тем, сохранять их индивидуальность и преимущества, которые они имеют. Благодаря единому каркаса, в некоторой степени решается проблема языкового барьера в мире программистов.
Каркас Framework.Net
В ходе эволюции каркаса происходит естественный процесс его отделения от среды разработки — Framework.Net становится надстройкой над операционной системой. В 2001 году Европейская ассоциация производителей компьютеров (ECMA) приняла компоненты каркаса в качестве стандарта. В следствие чего, каркас Framework.Net получает возможность развиваться для применения на операционных платформах, отличных от Windows.
Сегодня, каркас Framework.Net становится свободно распространяемым технологическим решением. Это существенно расширяет сферу его применения. Производители различных программных продуктов предпочитают ориентировать свои разработки на применение каркаса Framework.Net с целью обеспечения возможности выполнения кодов на различных операционных платформах.
В составе каркаса Framework.Net можно выделить две основные компоненты:
Статический — FCL (Framework Class Library) — библиотека классов каркаса.
Динамический — CLR (Common Language Runtime) — общеязыковой среды выполнения.
Библиотека классов FCL является результатом эволюции библиотеки классов MFC, благодаря которому каркас Framework.Net стал единственной средой для различных языков программирования. Поэтому, на каком бы языке программирования не велась разработка, она использует классы одной общей библиотеки. Большинство классов библиотеки, образующих общее ядро, используются всеми языками каркаса. Таким образом достигается унификация следующих реализаций:
- интерфейса приложений, независимо от языка, на котором они разрабатываются;
- взаимодействия с коллекциями и другими контейнерами данных;
- доступа к различным типам внешних источников данных.
Кроме того, библиотека классов FCL содержит ряд статических компонентов, обеспечивающих открытость программирования в среде Visual Studio. Среди них следует выделить: встроенные примитивные типы данных, структурные типы данных, компоненты поддержки архитектурного разнообразия приложений, пространства имен.
Встроенные примитивные типы данных . Важной частью библиотеки FCL стали классы, описывающие примитивные типы данных. Типы каркаса охватывают всю множество типов данных, встречающихся в языках программирования. Типы данных языка программирования проецируются на соответствующие типы каркаса. Например, тип данных, известный в языке Visual Basic как Integer, а в языке C как int, проецируется на тип данных FCL Int32. В каждом языке программирования, вместе с «родными» для языка названиями типов данных, разрешается использовать имена типов, принятыми в каркасе. Как следствие, все языки среды разработки могут пользоваться единой системой встроенных типов данных, обеспечивающая взаимодействие компонентов, написанных на разных языках.
Структурные типы данных . Частью библиотеки стали не только простые встроенные типы данных, но и структурные типы, описывающих организацию сложных структур данных: сроки, массивы, списки, записи. Это также способствует унификации и реальному сближению языков программирования.
Компоненты поддержки архитектурного разнообразия приложений . В среде разработки существует широкий набор возможных архитектурных типов приложений. Помимо традиционных Windows-приложений и консольных приложений, существует возможность создания платформ для Web-приложений. Большое внимание уделяется возможности создания повторно используемых компонентов — разрешается строить библиотеки классов, библиотеки элементов управления. Компиляторы языков, поставляемых различными фирмами для создания проектов, могут использовать как библиотеку FCL, так и собственную библиотеку классов.
Пространства имен . Количество классов библиотеки FCL достигла значительного уровня (несколько тысяч), поэтому возникла потребность в способе их структуризации. Логичным образом классы с близкой функциональностью объединяются в группы, называемые пространством имен (Namespace). Основным пространством имен библиотеки FCL является пространство System, содержащая, наряду с классами, другие — вложенные пространства имен. Например, примитивный тип Int32 непосредственно вложен в пространство имен System, и его полное имя, включающее имя пространства — System.Int32. В пространство System вложенный целый ряд других пространств имен, используемых при создании приложений.
Переход к идеологии открытого программирования в каркасе Framework.Net реализован во многом благодаря его динамической компоненте — общеязычной исполнительной среде CLR. Решения своих задач исполнительная среда осуществляет, основываясь на следующих составляющих: управляемый модуль, виртуальная машина, метаданные, сборник мусора, обработчик исключений, события и общие спецификации.
Управляемый модуль . С помощью управляемого модуля и управляемого кода реализуется основная концепция исполнительной среды каркаса — двухэтапная компиляция. Управляемый модуль — это перемещаемый исполняемый файл или РЕ-файл (Portable Exeable). РЕ-файлы представляют собой модули, содержание которых формируется компиляторами языков программирования на промежуточной языке — IL (Intermediate Language). В зависимости от типа проекта, РЕ-файл может иметь расширение exe, dll, mod или mdl.
Несмотря на то, что РЕ-файл с расширением exe, он выполняется операционной системой не совсем так, как привычный exe-файл. При его запуске он распознается, как специальный промежуточный файл, и передается исполнительному среде для обработки. Исполнительная среда начинает работать с кодом, в котором не осталось ни специфики начальной языка программирования. Код на промежуточной языке начинает выполняться под управлением исполнительной среды.
Виртуальная машина . Результат работы исполнительной среды каркаса можно рассматривать как своеобразную виртуальную машину. Эта машина транслирует участка промежуточного кода, подаваемого на исполнение, у команды реального процессора, который в действительности и выполняет код. Основу виртуальной машины составляют трансляторы JIT (Just In Time Compiler), которые и выполняют трансляцию промежуточного кода в командный код той вычислительной машины, где установлено и функционирует исполнительная среда.
Microsoft в своей разработке использовал опыт виртуальной машины Java. Он получил широкое признание, улучшив процесс за счет того, что в отличие от Java, промежуточный код не интерпретируется исполнительной средой, а компилируется с учетом всех особенностей вычислительной платформы. Благодаря этому, существует возможность создавать более производительные приложения. Кроме того, исполнительная среда, работая с промежуточным кодом, осуществляет достаточно эффективную оптимизацию программного кода и, что немаловажно, его защиту.
Метаданные . Перемещаемый исполнительный РЕ-файл является самодокументируемым файлом, т.е. содержит вместе с программным кодом метаданные, которые его описывают. Файл начинается с манифеста, включающий описание всех классов, которые в нем хранятся, их свойств, методов, всех аргументов этих методов, то есть всю необходимую для CLR информацию. Поэтому, кроме РЕ-файла не требуется никаких дополнительных файлов и записей в реестре — вся необходимая информация берется из самого файла.
Сборник мусора (Garbage Collector). Под сборкой мусора понимается освобождение оперативной памяти, занятой объектами, которые стали лишними и не используются в дальнейшей работе приложения. Во многих языках программирования (классическим примером является язык C / C + +) память освобождает сам программист, в явной форме программируя команды как на создание, так и на удаление объектов. Чтобы предотвратить неизбежным ошибкам программиста при работе с памятью, удаление неиспользуемых объектов, т.е. сборка мусора, стала частью исполнительной среды.
Обработчик исключений . В случаях, когда при вызове некоторой функции (процедуры) оказывается, что она не может корректно выполнить свою работу, исполнительная среда выбрасывает исключение. Выбрасывание исключений наилучшим образом согласовывает процесс программирования с исполнительной средой. В процессе разработки программных систем, организация перехвата выброшенных исключений и их последующая обработка, представляет собой основной рекомендуется реакции программы на нестандартные ситуации.
События . В исполнительной среды существует свое видение того, что является типом каждого объекта. Для этого используется формальное описание общей системы типов CTS — Common Type System. Согласно этому описанию, каждый тип, кроме методов и свойств, может содержать еще и события. При возникновении событий в процессе работы с тем или иным объектом определенного типа, направляются сообщения, которые могут получать и использовать другие объекты. Механизм обмена сообщениями основан на делегатах — функциональном типе.
Общие спецификации . Как уже отмечалось, каркас Framework.Net обеспечивает межъязычное взаимодействие. Чтобы классы, разработанные на разных языках, могли использоваться в рамках одного приложения, то есть их разноязычные потомки могли взаимодействовать, они должны удовлетворять некоторым ограничениям. Эти ограничения задаются набором общеязычной спецификации — CLS (Common Language Specification). Класс, удовлетворяющий спецификациям CLS, называется CLS-совместимым. Он доступен для использования в других языках, классы которых могут быть клиентами или наследниками совместного класса.
Настоящая статья посвящена технологиям разработки приложений и тенденциям их развития в условиях перехода большинства отечественных и зарубежных компаний от стихийной автоматизации отдельных областей их деятельности к единым интегрированным решениям.
Разработка приложений в современных ИТ-проектах
Современный период развития средств автоматизации и информатизации отечественных предприятий можно охарактеризовать как время массового перехода от стихийной автоматизации отдельных областей деятельности компаний к единым интегрированным решениям, охватывающим все аспекты их существования. Это не могло не отразиться на составе и объеме наиболее часто выполняющихся ИТ-проектов и на методах их выполнения.
Особенности современных ИТ-проектов
Если еще пять-семь лет назад были широко распространены проекты, связанные с заказной разработкой уникальных приложений (и несколько реже - решений на основе готовых компонентов, предназначенных для конкретной предметной области) и выполняемые силами эрудированных программистов широкого профиля, владеющих и смежными специальностями (например, умеющих администрировать локальные сети и СУБД), то сегодня в первую очередь заказываются проекты внедрения готовых бизнес-приложений и ERP-систем, в рамках которых нередко выполняются проекты по разработке решений на базе все тех же готовых бизнес-приложений. Причиной этого является, с одной стороны, осознание руководителями большинства компаний того факта, что, как бы их компания ни претендовала на уникальность в своей маркетинговой стратегии, по существу и ее производство, и отдельные аспекты ее деятельности являются вполне типовыми, а с другой стороны - осознание производителями бизнес-приложений неуникальности бизнес-процессов большинства компаний и создание ими широкого спектра типовых решений с одновременным предоставлением услуг по их внедрению, сопровождению и обновлению своими силами или силами партнеров.
Переход к разделению труда в проектах по разработке ПО
Подобная ситуация не могла не отразиться на кадровом составе ИТ-компаний, среди которых в последнее время преобладают системные интеграторы (иногда имеющие свой отдел разработки, но специализирующиеся в основном на комплексных проектах, включающих не только разработку приложений), а компаний, специализирующихся исключительно на разработке приложений, немного. В последних полным ходом идет процесс специализации, разделившей группу разработчиков на бизнес-аналитиков, системных аналитиков, программистов, технических писателей и руководителей проектов. При этом нередко системный аналитик не умеет программировать, бизнес-аналитик не руководит проектами, а руководитель проекта занимается только организационной работой и не интересуется ни архитектурой приложения, ни тем более предметной областью. Это отражает факт перехода от малотиражного производства эксклюзивного программного обеспечения к массовому промышленному производству типовых решений, востребованных современными пользователями.
Изменение требований к приложениям
Говоря о проектах по разработке приложений и о связанных с разработкой приложений частях комплексных ИТ-проектов, следует заметить, что сегодня наиболее актуальным становится создание корпоративных решений на основе не только СУБД, но и других продуктов - офисных приложений, GIS- и CAD-систем, средств бизнес-анализа, специализированных серверных продуктов, систем управления предприятием и других бизнес-приложений. Требования к защищенности создаваемых решений также заметно отличаются от тех, что существовали еще три года назад. Наконец, одной из важных тенденций является рост интереса к приложениям для мобильных устройств и приложений, способных работать автономно и при необходимости синхронизироваться с информационной системой предприятия.
Из иных тенденций, проявившихся в последнее время в области разработки корпоративных решений, следует отметить растущую потребность компаний в средствах бизнес-анализа, входящих в состав имеющихся решений или существующих в виде отдельных инструментов. Несмотря на то что создание приложений с применением бизнес-аналитики затруднено из-за того, что сегодня вопросы стандартизации доступа к данным многомерных хранилищ и языка запросов к ним остаются актуальными, в руках разработчиков уже имеется достаточно средств решения подобных задач для наиболее популярных аналитических платформ как от поставщиков самих аналитических платформ (например, Oracle, Microsoft и Hyperion), так и от компаний, специализирующихся на инструментах анализа данных (Cognos, ProClarity и Business Objects). Кроме того, средства бизнес-анализа (Business Intelligence and Report Tools, BIRT) доступны и для платформы Eclipse, занимающей сейчас половину рынка средств разработки Java-приложений.
Вовлечение заказчика в процесс разработки
Оценка вклада разработчиков приложений в успех бизнеса компании-заказчика, равно как и оценка качества самого процесса разработки и его результата всегда являлась спорным вопросом и поводом для непонимания и конфликтов. Однако в последнее время появились методы оценки зрелости процессов разработки и рекомендации, основанные на модели Capability Maturity Model Integration (CMMI), а также ряд методологий разработки приложений, предоставляющий заказчику приложения возможность контролировать ход процесса разработки. Модель CMMI позволяет оценить и усовершенствовать процессы разработки приложений и воспользоваться удачными примерами постановки подобных процессов, и наличие оценки того или уровня зрелости согласно этой модели у компании-разработчика в известной мере является гарантией качества конечного результата процесса разработки продукта в этой компании.
Семейство методологий разработки приложений под общим названием Agile methodologies (включающее, в частности, методологию экстремального программирования, о которой мы писали несколько месяцев назад) предоставляет «рецепты» для ежедневного управления проектной командой, включая, наряду с прочими, принцип разработки, управляемой тестированием (Test-Driven Development, TDD), зарекомендовавший себя в качестве средства получения высококачественного кода. Особенностью данного семейства методологий является вовлеченность заказчика в процесс разработки с тем, чтобы он мог его контролировать на всех этапах.
Самые популярные архитектуры и платформы
Архитектура, ориентированная на сервисы
Одна из современных тенденций развития ИТ-инфраструктуры современных предприятий и архитектур корпоративных приложений - переход к архитектуре, ориентированной на сервисы (Service Oriented Architecture, SOA). Данная архитектура предполагает создание и внедрение распределенных приложений и служб, основанных на применении различных технологий, например веб-служб (так, подобные технологии широко поддерживаются платформой Eclipse и средствами разработки от Borland и Microsoft).
Наиболее популярные платформы
Одна из наиболее заметных тенденций последнего времени проявляется в унификации платформ, для которых создается большинство приложений, и выделении среди них двух лидеров - Windows/Microsoft .NET и Java/J2EE. Это во многом обусловлено способностью указанных платформ обеспечить возможность создания приложений, степень защиты данных в которых, равно как и возможности создания пользовательских интерфейсов и обеспечения доступа к сервисам и данным, отвечают современным требованиям. Впрочем, указанная тенденция уже давно ни для кого не нова.
Отметим также, что ввиду бурного роста интереса корпоративных заказчиков к разработкам для мобильных устройств средства разработки данной категории приложений и сами мобильные платформы становятся все более популярными среди разработчиков.
Рост популярности мобильных платформ
Сегодня мобильные приложения разрабатываются примерно для полутора десятков платформ. Согласно проведенному в конце прошлого года исследовательской компанией Evans Data Corp. опросу нескольких сотен разработчиков мобильных приложений, основными лидерами в этой области являются.NET Compact Framework и Java 2 Mobile Edition (J2ME), а также другие платформы Microsoft для мобильных устройств и Embedded Linux (рис. 1).
Рис. 1. Популярность мобильных платформ среди разработчиков (источник - Developers’ Choice Wireless Platforms. Definitive Rankings of Wireless Platform by Developers Worldwide - Evans Data Corp., September 2005)
Тем не менее, согласно тому же опросу, в плане удовлетворения разработчиков качеством инструментов и уровнем поддержки сообщества разработчиков первое место сейчас занимает платформа Nokia Series 60. По прогнозам той же Evans Data Corp., на рынке мобильных платформ ожидается рост доли Embedded Linux.
Что касается средств разработки приложений, для платформы Windows Mobile инструменты от Microsoft существуют уже в течение нескольких лет. Инструменты компании Borland доступны для платформ.NET Compact Framework, Symbian и J2ME. Кроме того, имеются некоторые инструменты разработки мобильных приложений компании Sybase, а также ряда других производителей.
Инструменты для разработчиков сегодня
Узкая специализация разработчиков привела к активному развитию в течение последних пяти лет так называемых средств поддержки жизненного цикла приложений, предназначенных для больших коллективов разработчиков. К подобным средствам относятся средства управления требованиями, моделирования бизнес-процессов, приложений и данных, тестирования и оптимизации приложений, управления коллективной работой, контроля версий, управления изменениями. Производят такие инструменты многие ведущие поставщики ПО: IBM, Computer Associates, Borland, Microsoft, Oracle и ряд других.
В последнее время пристальное внимание инструментам подобного назначения стали уделять многие компании, ранее специализировавшиеся на создании сред разработки (в частности, IBM, Computer Associates, Borland, Microsoft, Oracle и Sybase). Потребность во взаимной интеграции всех этих «тяжелых» инструментов привела к созданию целых платформ для ролевой разработки программного обеспечения и управления жизненным циклом приложений - такие платформы сейчас производятся компаниями Borland, IBM, Microsoft и рядом других.
Как правило, применение подобных инструментов требует рассмотрения процесса разработки программного обеспечения как производственного процесса и соответственно создания и внедрения методик управления этим процессом, сходных с методиками управления процессами материального производства. Внедрение подобных методик зачастую осуществляется путем реализации отдельных (и не дешевых!) ИТ-проектов по внедрению в компаниях - разработчиках интегрированных платформ разработки приложений с целью автоматизации и оптимизации процессов, сопровождающих разработку, включая постановку задач, управление требованиями, достижение соответствия стандартам качества.
Бесплатные версии коммерческих инструментов
Если вспомнить, что происходило с инструментами для разработки в последние два года, можно заметить, что в последнее время весьма активно проявилась тенденция выпуска ведущими производителям средств разработки их бесплатных версий (причем с неплохими функциональными возможностями) с целью привлечь внимание разработчиков к потенциалу и возможностям полнофункциональных продуктов и платформ, для которых они предназначены. В частности, компания Borland уже примерно три года выпускает бесплатные версии некоторых своих средств разработки. Корпорацией Microsoft недавно было выпущено семейство продуктов Express, включающее несколько инструментов для разработки приложений Windows Forms и ASP .NET. Корпорация Oracle, в свою очередь, также предоставила свободный доступ разработчиков к инструменту Oracle JDeveloper 10g.
Инструменты с открытым кодом
Наблюдается еще одна тенденция, характерная для современного рынка средств разработки, - активный рост популярности платформ и инструментов с открытым исходным кодом, в развитие которых сейчас инвестируется немало средств коммерческими компаниями, в том числе такими известными производителями платформ, как IBM, Novell и Oracle. Среди наиболее ярких примеров следует отметить активное развитие среды Eclipse - универсальной открытой платформы разработки, совместимой с множеством языков, платформ развертывания и технологий, а также проекта Mono реализации части платформы.NET для операционной системы Linux (для последней сейчас активно выпускаются компиляторы и иные инструменты).
Начало проекту Eclipse было положено в 1998 году корпорацией IBM, поставившей перед собой цель создания интегрированной среды Java-разработки нового поколения, расширяемой за счет встраиваемых в нее интегрируемых инструментов, силами нескольких поставщиков Java-инструментов. С этой целью корпорация IBM в конце 2001 года предоставила сообществу Open Source часть исходного кода своего средства разработки Java-приложений WebSphere Studio Workbench и сформировала консорциум Eclipse (включавший представителей компаний Borland, IBM, MERANT, QNX Software Systems, Rational Software, Red Hat, SuSE, TogetherSoft и Webgain) для управления дальнейшим развитием этой среды разработки, преобразованный в дальнейшем в независимую некоммерческую организацию Eclipse Foundation, насчитывающую сегодня 115 членов.
Сегодня, по прошествии пяти лет с момента ее создания, платформа Eclipse стала настолько популярна, что начала вытеснять с рынка широко применявшиеся коммерческие инструменты (например, некоторые средства Java-разработки). Сегодня доля рынка средств разработки Java-приложений, занимаемая Eclipse, составляет примерно 50%. При этом в течение предыдущего года явно наблюдалась тенденция превращения Eclipse из среды Java-разработки в платформу интеграции инструментов для всего жизненного цикла разработки приложений - недавно в рамках консорциума Eclipse были начаты такие проекты, как создание графической среды моделирования, инструментов для архитектуры, ориентированной на сервисы, а также выпущены обновленные версии инструментов тестирования, бизнес-анализа, средств создания web-приложений.
Что касается собственно средств разработки приложений, на основе платформы Eclipse сейчас созданы среды разработки для PHP, Fortran, Macromedia Flex; планируется выпуск ряда инструментов для разработки приложений для встроенных и мобильных платформ. Для платформы Eclipse существуют и коммерческие средства разработки компаний IBM, Borland и SAP.
Самые популярные среды разработки
Согласно опросу 1200 разработчиков, проведенному в июне этого года исследовательской компанией Evans Data Corp., наиболее широко используемой средой разработки оказалась Microsoft Visual Studio .NET (рис. 2).
Рис. 2. Частота использования сред разработки (источник - Developers’ Choice IDE Scorecard - Evans Data Corp., June 2006)
По данным того же опроса, наиболее популярной в плане функциональности средой разработки приложений оказалась IBM Rational Application Developer, признанная участниками опроса лучшей в качестве инструмента моделирования и сборки приложений и обладающей лучшим набором примеров (рис. 3).
Результаты данного опроса отражают уже упомянутые тенденции преобладания двух наиболее популярных платформ (Windows/Microsoft .NET и Java/J2EE - практически все популярные среды разработки предназначены для этих платформ) и роста популярности средств и платформ разработки с открытым кодом (о чем свидетельствует присутствие Eclipse в пятерке самых популярных сред разработки).
Итак, современные тенденции развития технологий разработки приложений включают уменьшение доли разработки приложений в ИТ-проектах, постепенный переход от малотиражного производства эксклюзивного программного обеспечения к массовому промышленному производству типовых решений, все более активное применение средств поддержки жизненного цикла разработки приложений (включая проекты внедрения интегрированных платформ для разработки приложений). В последнее время также усилился интерес к созданию приложений для мобильных платформ. Характерной тенденцией последних лет является также появление высококачественных инструментов с открытым кодом. Не исключено, что названные тенденции сохранятся еще в течение как минимум нескольких лет.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ
ДОНЕЦКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ
Кафедра прикладной математики и теории систем управления
РЕФЕРАТ
«Информатика и программирование»
„ Передовые технологии и популярные средства разработки программного обеспечения ”
Доложилa:
студентка группы 2-В
М.А. Матиишина
Преподаватель: к.е.н., с.н.с.
С. Н. Мичкивский
Донецк 2013
Введение
1. История
2. Основные особенности методологии RAD
2.1 CASE средства
2.2 Применение объектно-ориентированных методов
2.3 Среды разработки, использующие принципы RAD
2.4 Когда применяется RAD.
3. Жизненный цикл методологии RAD
3.1 Фаза анализа и планирования требований
3.2 Фаза проектирования
3.3 Фаза построения
3.4 Фаза внедрения
Заключение
Введение
На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользователей (чему в значительной степени способствовал прогресс в области вычислительной техники, а также появление удобного графического интерфейса пользователя в системном программном обеспечении) потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области программного обеспечения -- инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке программного обеспечения средств автоматизации практически всех этапов жизненного цикла информационных систем. Например, технология Rapid Application Development (RAD).
программный обеспечение ориентированный жизненный
1. История
Концепция RAD стала ответом на неуклюжие методы разработки программ 1970-х и начала 1980-х годов, такие как «модель водопада» (англ. Waterfall model). Эти методы предусматривали настолько медленный процесс создания программы, что зачастую даже требования к программе успевали измениться до окончания разработки. Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца. А в 1991 году Мартин опубликовал известную книгу, в которой детально изложил концепцию RAD и возможности её применения. В настоящее время RAD становится общепринятой схемой для создания средств разработки программных продуктов. Именно средства разработки, основанные на RAD, имеют наибольшую популярность среди программистов.
2 . Основные особенности методологии RAD
Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений -- RAD (Rapid Application Development). Данная методология охватывает все этапы жизненного цикла современных информационных систем.
RAD -- это комплекс специальных инструментальных средств быстрой разработки прикладных информационных систем, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений.
Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:
· небольшой команде программистов (обычно от 2 до 10 человек);
· тщательно проработанный производственный график работ, рассчитанный на сравнительно короткий срок разработки (от 2 до 6 мес.);
· итерационная модель разработки, основанная на тесном взаимодействии с заказчиком -- по мере выполнения проекта разработчики уточняют и реализуют в продукте требования, выдвигаемые заказчиком.
При использовании методологии RAD большое значение имеют опыт и профессионализм разработчиков. Группа разработчиков должна состоять из профессионалов, имеющих опыт в анализе, проектировании, программировании и тестировании программного обеспечения.
Основные принципы методологии RAD можно свести к следующему:
· используется итерационная (спиральная) модель разработки;
· полное завершение работ на каждом из этапов жизненного цикла не обязательно;
· в процессе разработки информационной системы необходимо тесное взаимодействие с заказчиком и будущими пользователями;
· необходимо применение CASE-средств и средств быстрой разработки приложений;
· необходимо применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
· необходимо использование прототипов, позволяющее полнее выяснить и реализовать потребности конечного пользователя;
· тестирование и развитие проекта осуществляются одновременно с разработкой;
· разработка ведется немногочисленной и хорошо управляемой командой профессионалов;
· необходимы грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
2.1 Средства автоматизации разработки программ (CASE-средства)
В основных принципах методологии RAD, появляется такое понятие как CASE средства. Так вот, средства автоматизации разработки программ (CASE-средства)-- инструменты автоматизации процессов проектирования и разработки программного обеспечения для системного аналитика разработчика ПО и программиста. Первоначально под CASE-средствами понимались только инструменты для упрощения наиболее трудоёмких процессов анализа и проектирования, но в дальнейшем CASE-средства стали определять как программные средства для поддержки процессов жизненного цикла ПО.
Появлению CASE-технологии и CASE-средств предшествовали исследования в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т.д. Кроме того, появлению CASE-технологии способствовали и такие факторы, как:
* подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;
* широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;
* внедрение сетевой технологии, предоставившей возможность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте.
2.3 Применение объектно-ориентированных методов
Что касается RAD средств, то они дали возможность реализовывать совершенно иную по сравнению с традиционной технологию создания приложений.
Информационные объекты формируются как некие действующие модели (прототипы), чье функционирование согласовывается с пользователем, а затем разработчик может переходить непосредственно к формированию законченных приложений, не теряя из виду общей картины проектируемой системы.
Возможность использования подобного подхода в значительной степени является результатом применения принципов объектно-ориентированного проектирования, Применение объектно-ориентированных методов позволяет преодолеть одну из главных трудностей, возникающих при разработке сложных систем -- колоссальный разрыв между реальным миром (предметной областью описываемой проблемы) и имитирующей средой.
Использование объектно-ориентированных методов позволяет создать описание (модель) предметной области в виде совокупности объектов -- сущностей, объединяющих данные и методы обработки этих данных (процедуры). Каждый объект обладает своим собственным поведением и моделирует некоторый объект реального мира. С этой точки зрения объект является вполне осязаемой вещью, которая демонстрирует определенное поведение.
В объектном подходе акцент переносится на конкретные характеристики физической или абстрактной системы, являющейся предметом программного моделирования. Объекты обладают целостностью, которая не может быть нарушена. Таким образом, свойства, характеризующие объект и его поведение, остаются неизменными. Объект может только менять состояние, управляться или становиться в определенное отношение к другим объектам.
Широкую известность объектно-ориентированное программирование получило с появлением визуальных средств проектирования, когда было обеспечено слияние (инкапсуляция) данных с процедурами, описывающими поведение реальных объектов, в объекты программ, которые могут быть отображены определенным образом в графической пользовательской среде. Это позволило приступить к созданию программных систем, максимально похожих на реальные, и добиваться наивысшего уровня абстракции. В свою очередь, объектно-ориентированное программирование позволяет создавать более надежные коды, так как у объектов программ существует точно определенный и жестко контролируемый интерфейс.
При разработке приложений с помощью инструментов RAD используется множество готовых объектов, сохраняемых в общедоступном хранилище. Однако обеспечивается и возможность разработки новых объектов. При этом новые объекты могут разрабатываться как на основе существующих, так и «с нуля».
Инструментальные средства RAD обладают удобным графическим интерфейсом пользователя и позволяют на основе стандартных объектов формировать простые приложения без написания кода программы. Это является большим преимуществом RAD, так как в значительной степени сокращает рутинную работу по разработке интерфейсов пользователя (при использовании обычных средств разработка интерфейсов представляет собой достаточно трудоемкую задачу, отнимающую много времени). Высокая скорость разработки интерфейсной части приложений позволяет быстро создавать прототипы и упрощает взаимодействие с конечными пользователями.
Таким образом, инструменты RAD позволяют разработчикам сконцентрировать усилия на сущности реальных деловых процессов предприятия, для которого создается информационная система. В итоге это приводит к повышению качества разрабатываемой системы.
Применение принципов объектно-ориентированного программирования позволило создать принципиально новые средства проектирования приложений, называемые средствами визуального программирования. Визуальные инструменты RAD позволяют создавать сложные графические интерфейсы пользователя вообще без написания кода программы. При этом разработчик может на любом этапе наблюдать то, что закладывается в основу принимаемых решений.
Визуальные средства разработки оперируют в первую очередь со стандартными интерфейсными объектами -- окнами, списками, текстами, которые легко можно связать с данными из базы данных и отобразить на экране монитора. Другая группа объектов представляет собой стандартные элементы управления -- кнопки, переключатели, флажки, меню и т.п., с помощью которых осуществляется управление отображаемыми данными. Все эти объекты могут быть стандартным образом описаны средствами языка, а сами описания сохранены для дальнейшего повторного использования.
В настоящее время существует довольно много различных визуальных средств разработки приложений. Но все они могут быть разделены на две группы -- универсальные и специализированные.
Среди универсальных систем визуального программирования сейчас наиболее распространены такие, как Borland Delphi и Visual Basic. Универсальными мы их называем потому, что они не ориентированы на разработку только приложений баз данных -- с их помощью могут быть разработаны приложения почти любого типа, в том числе и информационные приложения. Причем программы, разрабатываемые с помощью универсальных систем, могут взаимодействовать практически с любыми системами управления базами данных. Это обеспечивается как использованием драйверов ODBC или OLE DB, так и применением специализированных средств (компонентов).
2.4 Среды разработки, использующие принципы RAD
· Borland Delphi
· Borland C++ Builder
· Microsoft Visual Studio
· Macromedia Flash
· Macromedia Authorware
· Macromedia Director
· Visual DataFlex
Быстрая разработка приложений Rapid Application Development (RAD) - это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех месяцев путем использования инкрементного прототипирования с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях -обследование организации, выработка требований к системе. Причины популярности RAD вытекают из тех преимуществ, которые обеспечивает эта технология.Наиболее существенными из них являются:
§ высокая скорость разработки;
§ низкая стоимость;
§ высокое качество.
Визуальные инструменты RAD позволяют максимально сблизить этапы создания информационных систем; анализ исходных условий, проектирование системы, разработка прототипов и окончательное формирование приложений становятся сходными, так как на каждом этапе разработчики оперируют визуальными объектами.
Логика приложения, построенного с помощью RAD, является событийно-ориентированной. Это означает следующее: каждый объект, входящий в состав приложения, может генерировать события и реагировать на события, генерируемые другими объектами. Примерами событий могут быть: открытие и закрытие окон, нажатие кнопки, нажатие клавиши клавиатуры, движение мыши, изменение данных в базе данных и т. п.
Разработчик реализует логику приложения путем определения обработчика каждого события -- процедуры, выполняемой объектом при наступлении соответствующего события. Например, обработчик события «нажатие кнопки» может открыть диалоговое окно. Таким образом, управление объектами осуществляется с помощью событий.
Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPDATE), могут реализовываться в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность базы данных при операциях удаления, вставки и обновления, а также автоматическую генерацию первичных ключей.
2.5 Когда применяется RAD
Применение технологии RAD целесообразно, когда: требуется выполнение проекта в сжатые сроки (90 дней). Быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня. Если система проектируется долго, то весьма высока вероятность, что за это время существенно изменятся фундаментальные положения, регламентирующие деятельность организации, то есть, система морально устареет еще до завершения ее проектирования.
Интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта. Проект большой, но поддается разделению на более мелкие функциональные компоненты. Если предполагаемая система велика, необходимо, чтобы ее можно было разбить на мелкие части, каждая из которых обладает четкой функциональностью. Они могут выпускаться последовательно или параллельно (в последнем случае привлекается несколько RAD групп).·
ПО не обладает большой вычислительной сложностью. Современные средства быстрой разработки windows-при-ложений, так называемые rad-средства (rad расшифровывается как rapid application development), обладают в той или иной степени почти всеми возможностями реализации в приложениях подобных интерфейсных элементов. Многие из них позволяют осуществлять доступ к базам данных, в том числе и к серверным БД. borland delphi, на взгляд автора, является в этом отношении наиболее простым и удобным в использовании средством.
RAD-технология не является универсальной, то есть ее применение целесообразно не всегда. Например, в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется и более эффективной может быть иерархическая разработка (каскадный метод). То же касается проектов, ПО, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объем пользовательского интерфейса невелик.
3 . Жизненный цикл методологии RAD
При использовании методологии быстрой разработки приложений жизненный цикл информационной системы состоит из четырех фаз:
· фаза анализа и планирования требований;
· фаза проектирования;
· фаза построения;
· фаза внедрения.
3 .1 Фаза анализа и планирования требований.
На фазе анализа и планирования требований выполняются следующие работы:
· определяются функции, которые должна выполнять разрабатываемая информационная система;
· определяются наиболее приоритетные функции, требующие разработки в первую очередь;
· проводится описание информационных потребностей;
· ограничивается масштаб проекта;
· определяются временные рамки для каждой из последующих фаз;
· в заключение, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на имеющихся аппаратных и программных средствах.
Если реализация проекта принципиально возможна, то результатом фазы анализа и планирования требований будет список функций разрабатываемой информационной системы с указанием их приоритетов и предварительные функциональные и информационные модели системы.
3 .2 Фаза проектирования
На фазе проектирования необходимым инструментом являются CASE-средства, используемые для быстрого получения работающих прототипов приложений.
Прототипы, созданные с помощью CASE-средств, анализируются пользователями, которые уточняют и дополняют те требования к системе, которые не были выявлены на предыдущей фазе. Таким образом, на данной фазе также необходимо участие будущих пользователей в техническом проектировании системы.
При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог или отчет (это позволяет устранить неясности или неоднозначности). Затем определяются требования разграничения доступа к данным.
После детального рассмотрения процессов определяется количество функциональных элементов разрабатываемой системы. Это позволяет разделить информационную систему на ряд подсистем, каждая из которых реализуется одной командой разработчиков за приемлемое для RAD-проектов время (порядка полутора месяцев). С использованием CASE-средств проект распределяется между различными командами -- делится функциональная модель.
На этой же фазе происходит определение набора необходимой документации.
Результатами данной фазы являются:
· общая информационная модель системы;
· функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
· точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
· построенные прототипы экранов, диалогов и отчетов.
Одной из особенностей применения методологии RAD на данной фазе является то, что каждый созданный прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация. При традиционном подходе использовались средства прототипирования, не предназначенные для построения реальных приложений, поэтому разработанные прототипы не могли быть использованы на последующих фазах и просто «выбрасывались» после того, как выполняли задачу устранения неясностей в проекте.
3 .3 Фаза построения
На фазе построения выполняется собственно быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных ранее моделей, а также требований нефункционального характера. Разработка приложения ведется с использованием визуальных средств программирования. Формирование программного кода частично выполняется с помощью автоматических генераторов кода, входящих в состав CASE-средств. Код генерируется на основе разработанных моделей.
На фазе построения также требуется участие пользователей системы, которые оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом.
Завершается физическое проектирование системы, а именно:
· определяется необходимость распределения данных;
· производится анализ использования данных;
· производится физическое проектирование базы данных;
· определяются требования к аппаратным ресурсам;
· определяются способы увеличения производительности;
· завершается разработка документации проекта.
Результатом данной фазы является готовая информационная система, удовлетворяющая всем требованиям пользователей.
3 .4 Фаза внедрения
Фаза внедрения в основном сводится к обучению пользователей разработанной информационной системы.
Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, еще на этапе проектирования системы.
Приведенная схема разработки информационной системы не является универсальной. Вполне возможны различные отклонения от нее. Это связано с зависимостью схемы выполнения проекта от начальных условий, при которых начинается разработка (например, разрабатывается совершенно новая система или на предприятии уже существует некоторая информационная система). Во втором случае существующая система может либо использоваться в качестве прототипа новой системы, либо интегрироваться в новую разработку в качестве одной из подсистем.
Заключение
Несмотря на все свои достоинства, методология RAD тем не менее (как, впрочем, и любая другая методология) не может претендовать на универсальность. Ее применение наиболее эффективно при выполнении сравнительно небольших систем, разрабатываемых для вполне определенного предприятия.
При разработке же типовых систем, не являющихся законченным продуктом, а представляющих собой совокупность типовых элементов информационной системы, большое значение имеют такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Это связано с тем, что типовые системы обычно централизованно сопровождаются и могут быть адаптированы к различным программно-аппаратным платформам, системам управления базами данных, коммуникационным средствам, а также интегрироваться с существующими разработками. Поэтому для такого рода проектов необходим высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD неприменима не только для создания типовых информационных систем, но и для построения сложных расчетных программ, операционных систем или программ управления сложными инженерно-техническими объектами -- программ, требующих написания большого объема уникального кода.
Методология RAD не может быть использована для разработки приложений, в которых интерфейс пользователя является вторичным, то есть отсутствует наглядное определение логики работы системы. Примерами таких приложений могут служить приложения реального времени, драйверы или службы.
Совершенно неприемлема методология RAD для разработки систем, от которых зависит безопасность людей, -- например, систем управления транспортом или атомных электростанций. Это обусловлено тем, что итеративный подход, являющийся одной из основ RAD, предполагает, что первые версии системы не будут полностью работоспособны, что в данном случае может привести к серьезнейшим катастрофам.
Список источников
1. http://ru.wikipedia.org
2. http://www.inforazrabotky.info
3. http://brain.botik.ru
4. http://promidi.by.ru
5. http://www.citforum.ru
6. Трофимов С.А. CASE-технологии: практическая работа в Rational Rose.
7. http://vk.com/away.php?to=https%3A%2F%2Fdrive.google.com%2Ffolderview%3Fid%3D0B4QYrT5wARvMdUttbnJ4N1F0bFk%26usp%3Dsharing&post=-58064243_12
Размещено на Allbest.ru
...Подобные документы
Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.
презентация , добавлен 19.09.2016
Понятие, сущность и структура жизненного цикла программного обеспечения, описание технологии его проектирования, разработки и сопровождения. Сущность и основные положения международного стандарта ISO/IEC 12207. Перечень основных принципов методологии RAD.
реферат , добавлен 30.11.2010
Современные методологические проблемы разработки и внедрения программного обеспечения ERP систем. Основные концептуальные подходы к методологии разработки и внедрения программного обеспечения. Исследование методологии ASAP: ее сильные и слабые стороны.
дипломная работа , добавлен 29.04.2011
Технология конструирования программного обеспечения, надежно и эффективно работающего в реальных компьютерах. Модель быстрой разработки приложений (Rapid Application Development) как один из примеров применения инкрементной стратегии конструирования.
реферат , добавлен 24.06.2009
Базовые основы разработки программного обеспечения: его классический жизненный цикл, макетирование, стратегии конструирования, модели качества процессов разработки. Применение параллельных алгоритмов и CASE-системы, критерии оценки их эффективности.
курсовая работа , добавлен 07.04.2015
Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.
курсовая работа , добавлен 26.09.2014
Понятие технологии разработки программы. Основа проектирования программного обеспечения. Модели жизненного цикла, возникшие исторически в ходе развития теории проектирования программного обеспечения. Спиральная (spiral), каскадная и итерационная модели.
презентация , добавлен 11.05.2015
Основная идея методологии и принципы RAD-разработки информационных систем, ее главные преимущества. Причины популярности, особенности применения технологии. Формулировка основных принципов разработки. Среды разработки, использующие принципы RAD.
презентация , добавлен 02.04.2013
Оценка финансовой, стратегической ценности и уровня рисков проекта. Классификация проектов: "свой" заказчик, продукт под заказ, тиражируемый продукт, аутсорсинг. Организация процесса разработки программного обеспечения, методологии его проектирования.
презентация , добавлен 07.12.2013
Стадии разработки программного средства. Средства, методологии и методы его разработки. Оценка надежности и качества проекта. Обоснование необходимости разработки программы. Тестирование как процесс выполнения тестовой программы с намерением найти ошибки.