Четвертый этап - компонентный подход и CASE-технологии (с середины 90-х годов XX в.
до нашего времени). Компонентный подход предполагает построение программного обеспечения
из отдельных компонентов физически отдельно существующих частей программного
обеспечения, которые взаимодействуют между собой через стандартизованные двоичные
интерфейсы. В отличие от обычных объектов объекты-компоненты можно собрать в динамически
вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных
текстов) и использовать в любом языке программирования, поддерживающем соответствующую
технологию. На сегодня рынок объектов стал реальностью, так в Интернете существуют узлы,
предоставляющие большое количество компонентов, рекламой компонентов забиты журналы. Это
позволяет программистам создавать продукты, хотя бы частично состоящие из повторно
использованных частей, т.е. использовать технологию, хорошо зарекомендовавшую себя в области
проектирования аппаратуры.
Компонентный подход лежит в основе технологий, разработанных на базе COM (Component
Object Model - компонентная модель объектов), и технологии создания распределенных
приложений CORBA (Common Object Request Broker Architecture - общая архитектура с
посредником обработки запросов объектов). Эти технологии используют сходные принципы и
различаются лишь особенностями их реализации.
Технология СОМ фирмы Microsoft является развитием технологии OLE I (Object Linking and
Embedding - связывание и внедрение объектов), которая использовалась в ранних версиях
|
|
|
Windows для создания составных документов. Технология СОМ определяет общую парадигму
взаимодействия программ любых типов: библиотек, приложений, операционной системы, т. е.
позволяет одной части программного обеспечения использовать функции (службы),
предоставляемые другой, независимо от того, функционируют ли эти части в пределах одного
процесса, в разных процессах на одном компьютере или на разных компьютерах (рис. 1.7).
Модификация СОМ, обеспечивающая передачу вызовов между компьютерами, называется DCOM
(Distributed COM - распределенная СОМ).
По технологии СОМ приложение предоставляет свои службы, используя специальные
объекты - объекты СОМ, которые являются экземплярами классов СОМ. Объект СОМ так же, как
обычный объект включает поля и методы, но в отличие от обычных объектов каждый объект СОМ
может реализовывать несколько интерфейсов, обеспечивающих доступ к его полям и функциям.
Это достигается за счет организации отдельной таблицы адресов методов для каждого интерфейса
(по типу таблиц виртуальных методов). При этом интерфейс обычно объединяет несколько
однотипных функций. Кроме того, классы СОМ поддерживают наследование интерфейсов, но не
|
|
|
поддерживают наследования реализации, т. е. не наследуют код методов, хотя при необходимости
объект класса-потомка может вызвать метод родителя.
Каждый интерфейс имеет имя, начинающееся с символа «I» и глобальный уникальный
идентификатор IID (Interface IDentifier). Любой объект СОМ обязательно реализует интерфейс
ILJnknown (на схемах этот интерфейс всегда располагают сверху). Использование этого
интерфейса позволяет получить доступ к остальным интерфейсам объекта.
Объект всегда функционирует в составе сервера - динамической библиотеки или
исполняемого файла, которые обеспечивают функционирование объекта. Различают три типа
серверов:
• внутренний сервер - реализуется динамическими библиотеками, которые подключаются к
приложению-клиенту и работают в одном с ними адресном пространстве - наиболее эффективный
сервер, кроме того, он не требует специальных средств;
• локальный сервер — создается отдельным процессом (модулем, ехе), который работает на
одном компьютере с клиентом;__
• удаленный сервер - создается процессом, который работает на другом компьютере.
Например, Microsoft Word является локальным сервером. Он включает множество объектов,
|
|
|
которые могут использоваться другими приложениями.
Для обращения к службам клиент должен получить указатель на соответствующий интерфейс.
Перед первым обращением к объекту клиент посылает запрос к библиотеке СОМ, хранящей
информацию обо всех, зарегистрированных в системе классах СОМ объектов, и передает ей имя
класса, идентификатор интерфейса и тип сервера. Библиотека запускает необходимый сервер,
создает требуемые объекты и возвращает указатели на объекты и интерфейсы. Получив указатели,
клиент может вызывать необходимые функции объекта.
Взаимодействие клиента и сервера обеспечивается базовыми механизмами СОМ или DCOM,
поэтому клиенту безразлично местонахождение объекта. При использовании локальных и
удаленных серверов в адресном пространстве клиента создается proxy-объект - заместитель
объекта СОМ, а в адресном пространстве сервера СОМ - заглушка, соответствующая клиенту.
Получив задание от клиента, заместитель упаковывает его параметры и, используя службы
операционной системы, передает вызов заглушке. Заглушка распаковывает задание и передает его
объекту СОМ. Результат возвращается клиенту в обратном порядке.
На базе технологии СОМ и ее распределенной версии DCOM были разработаны
|
|
|
компонентные технологии, решающие различные задачи разработки программного обеспечения.
OLE-automation или просто Automation (автоматизация) — технология создания
программируемых приложений, обеспечивающая программируемый доступ к внутренним
службам этих приложений. Вводит понятие диспинтерфейса (dispinterface) - специального
интерфейса, облегчающего вызов функций объекта. Эту технологию поддерживает, например,
Microsoft Excel, предоставляя другим приложениям свои службы.
ActiveX - технология, построенная на базе OLE-automation, предназначена для создания
программного обеспечения как сосредоточенного на одном компьютере, так и распределенного в
сети. Предполагает использование визуального программирования для создания компонентов -
элементов управления ActiveX. Полученные таким образом элементы управления можно
устанавливать на компьютер дистанционно с удаленного сервера, причем устанавливаемый код
зависит от используемой операционной системы. Это позволяет применять элементы управления
ActiveX в клиентских частях приложений Интернет.
Основными преимуществами технологии ActiveX, обеспечивающими ей широкое
распространение, являются:
• быстрое написание программного кода - поскольку все действия, связанные с организацией
взаимодействия сервера и клиента берет на программное обеспечение СОМ, программирование
сетевых приложений становится похожим на программирование для отдельного компьютера;
• открытость и мобильность - спецификации технологии недавно были переданы в Open Group
как основа открытого стандарта;
• возможность написания приложений с использованием знакомых средств разработки,
например, Visual Basic, Visual C++, Borland Delphi, Borland C++ и любых средств разработки на
Java;
• большое количество уже существующих бесплатных программных элементов ActiveX (к
тому же, практически любой программный компонент OLE совместим с технологиями ActiveX и
может применяться без модификаций в сетевых приложениях);__
• стандартность - технология ActiveX основана на широко используемых стандартах Internet
(TCP/IP, HTML, Java), с одной стороны, и стандартах, введенных в свое время Microsoft и
необходимых для сохранения совместимости (COM, OLE).
MTS (Microsoft Transaction Server - сервер управления транзакциями) технология,
обеспечивающая безопасность и стабильную работу распределенных приложений при больших
объемах передаваемых данных.
MIDAS (Multitier Distributed Application Server - сервер многозвенных распределенных
приложений) - технология, организующая доступ к данным разных компьютеров с учетом
балансировки нагрузки сети.
Все указанные технологии реализуют компонентный подход, заложенный в СОМ. Так, с точки
зрения СОМ элемент управления ActiveX - внутренний сервер, поддерживающий технологию
OLE-automation. Для программиста же элемент ActiveX - «черный ящик», обладающий
свойствами, методами и событиями, который можно использовать как строительный блок при
создании приложений.
Технология CORBA, разработанная группой компаний ОМС (Object Management Group -
группа внедрения объектной технологии программирования), реализует подход, аналогичный
СОМ, на базе объектов и интерфейсов CORBA. Программное ядро CORBA реализовано для всех
основных аппаратных и программных платформ и потому эту технологию можно использовать
для создания распределенного программного обеспечения в гетерогенной (разнородной)
вычислительной среде. Организация взаимодействия между объектами клиента и сервера в
CORBA осуществляется с помощью специального посредника, названного VisiBroker, и другого
специализированного программного обеспечения. Отличительной особенностью современного этапа развития технологии программирования,
кроме изменения подхода, является создание и внедрение автоматизированных технологий
разработки и сопровождения программного обеспечения, которые были названы CASE-
технологиями (Computer-Aided Software/System Engineering - разработка программного
обеспечения/программных систем с использованием компьютерной поддержки). Без средств
автоматизации разработка достаточно сложного программного обеспечения на настоящий момент
становится трудно осуществимой: память человека уже не в состоянии фиксировать все детали,
которые необходимо учитывать при разработке программного обеспечения. На сегодня
существуют CASE-технологии, поддерживающие как структурный, так и объектный (в том числе
и компонентный) подходы к программированию.
Появление нового подхода не означает, что отныне все программное обеспечение будет
создаваться из программных компонентов, но анализ существующих проблем разработки
сложного программного обеспечения показывает, что он будет применяться достаточно широко
2. жизненные модели по
Модели жизненного цикла ПО[править]
Водопадная (каскадная, последовательная) модель[править]
Основная статья: Модель водопада
Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью:
1. Формирование требований;
2. Проектирование;
3. Реализация;
4. Тестирование;
5. Внедрение;
6. Эксплуатация и сопровождение.
Преимущества:
· Полная и согласованная документация на каждом этапе;
· Легко определить сроки и затраты на проект.
Недостатки:
В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы[2]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем[3].
Итерационная модель[править]
Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью[4].
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения[3].
По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»[4].
Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже»[3].
Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).
Спиральная модель[править]
Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются:
· риск превышения сроков и стоимости проекта;
· необходимость выполнения ещё одной итерации;
· степень полноты и точности понимания требований к системе;
· целесообразность прекращения проекта.
Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID[3].
Отличительной особенностью спиральной модели является специальное внимание, уделяемое рискам, влияющим на организацию жизненного цикла, и контрольным точкам. Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:
1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. Перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. Разрыв в квалификации специалистов разных областей.
Дата добавления: 2019-02-12; просмотров: 457; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!