Характеристика CASE-технологии

Размещено на http://www.allbest.ru/

Содержание

1. Какими принципами следует руководствоваться при выборе АБС

2. Характеристика CASE-технологии

Литература

1. Какими принципами следует руководствоваться при выборе АБС

Автоматизированная банковская система (АБС) - это форма организационного управления банком на базе широкого применения новых информационных технологий.

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

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

1. Функциональная полнота. Это одна из главнейших характеристик АБС. Сложные АБС могут содержать десятки тысяч различных автоматизируемых функций и банковских операций. Функциональная полнота подразумевает наличие в программном изделии необходимого и достаточного числа компонентов для выполнения заданных функций с учетом возможности системы наиболее полно соответствовать информационным потребностям банка, охватывая все виды его деятельности.

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

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

3. Масштабируемость системы. Способность системы адаптироваться к расширению предъявляемых требований и возрастанию объемов решаемых задач: числа обслуживаемых автоматизированных рабочих мест, обрабатываемых документов, а также быстроты реакции, общей производительности и пр., при добавлении к ней вычислительных ресурсов.

4. Открытость - способность интеграции с любыми внешними открытыми приложениями через стандартные интерфейсы межпрограммного взаимодействия, поддержка современных мировых стандартов в области информационных технологий (WfMC, XML, COM/ DECOM, J2EE), наличие готовых индустриально поддерживаемых шлюзов к наиболее распространенным офисным и бизнес-приложениям, прозрачная интеграция со стандартными пользовательскими интерфейсами, такими как Windows Explorer и Internet Browser.

5. Настраиваемость системы. Это ее мобильность, динамичность, подвижность. Настраиваемость предполагает, что те или иные значимые параметры не жестко заданы, а могут быть адаптированы к потребностям и условиям конкретного банка.

6. Централизованное управление системой. Все основные настройки делает квалифицированный технолог АБС, а сотрудники банка могут сразу приступить к работе с программой. Автоматизированную банковскую систему, имеющую такую архитектуру, можно максимально быстро и качественно подготовить к эксплуатации. Это дает возможность оперативно изменять условия выполнения любой oпeрации, что очень важно при создании новых банковских продуктов.

7. Единая база данных, обеспечивающая многопользовательскую работу. Рекомендуется использование распределенных баз данных на основе промышленных СУБД (MS SQL Server, Oracle, Informix, DB2) В этих СУБД встроены и являются неотъемлемой частью:

Ш транзакционный механизм;

Ш средства разграничения доступа;

Ш средства поддержания ссылочной целостности и непротиворечивости данных.

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

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

9. Безопасность. Поддерживается: средствами разделения прав доступа, интегрированными с системой безопасности ОС (имеющей до семи уровней доступа к документам); механизмом назначения прав как по ролевому, так и по персональному признаку и возможностью изменения прав доступа к документу в процессе его жизненного цикла. Требования безопасности включают в себя также возможность интеграции с открытыми средствами криптографической защиты, аутентификации и электронной подписи.

Автоматизированная банковская система должна соответствовать следующим принципам.

1. Принцип динамических рабочих мест пользователей. Рабочее место пользователя АБС компонуется (настраивается) динамически и определяется как адрес (имя) пользователя с назначенным ему набором документов, этапов обработки документов, предоставляемых прав. Пользователь, входя со своим именем в систему с произвольного компьютера, работает с доступными ему документами. Если для пользователя (или его подразделения) изменяется набор документов, с которыми он работает, то его рабочее место соответствующим образом перенастраивается. Таким образом, настройка всех динамических рабочих мест системы производится как перед началом функционирования системы, так и по мере необходимости в процессе функционирования. При этом идентификатору конкретного пользователя (который может быть и групповым, т.е. идентификатором подразделения банка) назначаются конкретные документы и этапы их обработки.

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

3. Принцип совместного использования on-line- и off-line-технологии обработки документов. Технология on-line позволяет обрабатывать документы (разносить проводки) в реальном режиме времени в момент автоматической генерации документами операций (проводок). Off-line технология дает возможность обрабатывать документы автономно например на рабочем месте пользователя генерировать проводки' позже через систему электронного документооборота отправлять их в ядро операционного дня для разнесения по счетам. Соблюдение данного принципа означает, что рабочее место пользователя можно динамически настроить (в зависимости от доступности ядра операционного дня с сервером базы данных счетов) на любую из этих технологий.

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

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

Ш документы, отправленные от одного рабочего места к другому (в зависимости от его нахождения), могут автоматически либо сразу передаваться в локальные сети на это рабочее место, либо попадать в систему электронного документооборота и транспортироваться на любое расстояние;

Ш система электронного документооборота одинаковым образом маршрутизирует (транспортирует) электронное документы любого типа в системе «Банк-клиент», в том числе платежные поручения клиентов. Она маршрутизирует автоматически созданные ядром банковской системы электронные документы (например, выписки по счетам), торговые транзакции по карточным счетам, генерированные торговым терминалом в магазине, электронные документы, пришедшие из внешних систем (например, из системы SWIFT);

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

Принципы автоматизации деятельности банка

При внедрении новых информационных технологий банкам важно разработать стратегию автоматизации, придерживаться существующих функциональных требований к АБС. Есть принципы, которые позволяют оценить, правильно ли проводится автоматизация в банке.

1) Принцип единства информационного пространства - (возможность оперировать любыми данными, формирующимися в процессе функционирования АБС, и любыми функциями, выполняемыми системой). Путями обеспечения единства информационного пространства являются: использование единых баз и хранилищ данных, технологии "клиент-сервер", глобальных телекоммуникационных сетей. Важной характеристикой является выбор Операционной системы и СУБД, от этого зависит производительность АБС.

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

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

4) Принцип открытости - соответствие международным стандартам, принятым в секторе автоматизации:

Ш способность взаимодействовать с различными внешними системами;

Ш переносимости программных средств на другие аппаратные средства, гибкости настройки модулей, возможности их адаптации к потребностям и условиям конкретного банка (система должна автоматизировать подготовку отчетности для ЦБ и налоговых служб, а также иметь возможность группировать в один отчет информацию, обрабатываемую в разных модулях АБС).

Ш масштабируемости - возможности расширения и усложнения функциональных модулей системы.

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

6) Принцип взаимодействия - состоит в обеспечении одновременной работы большого числа пользователей и способности функционировать на компьютерах, расположенных в разных подразделениях банка, отделениях и филиалах в режиме реального времени (on-line). Многопользовательский режим работы обеспечивается применением технологии "клиент-сервер", использование локальных и глобальных сетей, единых распределенных или централизованных баз данных.

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

8) Принцип безопасности - предусматривает защищенность системы от случайного или преднамеренного вмешательства в процесс функционирования системы, а также от попыток хищения, модификации или разрушения ее компонентов. Безопасность АБС достигается обеспечением трех характеристик:

7) целостность информации, т.е. при функционировании системы информация может быть изменена только теми пользователями, которые имеют на это права;

8) доступность информации допущенному пользователю в любое время;

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

2. Характеристика CASE-технологии

Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств. Таким образом, CASE-технологии не могут считаться самостоятельными, они только обеспечивают, как минимум, высокую эффективность их применения, а в некоторых случаях и принципиальную возможность применения соответствующей методологии. Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано на методологиях структурного (в основном) или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. В последнее время стали появляться CASE-системы, уделяющие основное внимание проблемам спецификации и моделирования технических средств.

В рамках программной инженерии CASE-средства представляют собой основную технологию, используемую для создания и эксплуатации систем ПО. Под CASE-средством (в соответствии с международным стандартом ISO/IEC 14102:1995(Е)) понимается программное средство, поддерживающее процессы жизненного цикла ПО (определенные в стандарте ISO/IEC 12207:1995), включая анализ требований к системе, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, управление конфигурацией ПО и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют среду разработки ПО ИС. автоматизированный банковский интегрированный проектирование

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

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

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

Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:

· мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

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

· использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

Ш графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

Ш средства разработки приложений, включая языки 4GL и генераторы кодов;

Ш средства конфигурационного управления;

Ш средства документирования;

Ш средства тестирования;

Ш средства управления проектом;

Ш средства реинжиниринга.

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

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

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

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

Графические средства (диаграммеры) обеспечивают:

Ш создание иерархически связанных диаграмм, в которых сочетаются графические и текстовые объекты;

Ш создание и редактирование объектов в любом месте диаграммы;

Ш создание, перемещение и выравнивание групп объектов, изменение их размеров, масштабирование;

Ш сохранение связей между объектами при их перемещении и изменении размеров;

Ш автоматический контроль ошибок и др.

Важность контроля ошибок на стадиях формирования требований и проектирования обусловлена тем, что на более поздних стадиях их выявление и устранение обходятся значительно дороже. В CASE-средствах обычно реализуются следующие виды контроля:

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

v контроль полноты и состоятельности диаграмм: все элементы диаграмм должны быть идентифицированы и отражены в репозитории. Например, для DFD контролируются неименованные или несвязанные потоки данных, процессы и хранилища данных;

v сквозной контроль диаграмм одного или различных типов на предмет их состоятельности по уровням - вертикальное и горизонтальное балансирование диаграмм. При вертикальном балансировании диаграмм одного типа выявляются несбалансированные потоки данных между детализируемой и детализирующей диаграммами. Горизонтальное балансирование определяет несоответствия между DFD, ERD, структурами данных и спецификациями процессов. Так, при балансировании DFD-ERD контролируется соответствие каждого хранилища данных на DFD сущности или отношению на ERD.

Идеальное объектно-ориентированное CASE-средство должно содержать четыре основных блока: анализ, проектирование, разработка и инфраструктура.

Основные требования к блоку анализа:

v возможность выбора выводимой на экран информации из всей совокупности данных, описывающих модели;

v согласованность диаграмм при хранении их в репозитарии;

v внесение комментариев в диаграммы и соответствующую документацию для фиксации проектных решений;

v возможность динамического моделирования в терминах событий;

v поддержка нескольких нотаций (хотя бы три нотации - Г.Буча, И. Джекобсона и ОМТ).

Основные требования к блоку проектирования:

v поддержка всего процесса проектирования приложения;

v возможность работы с библиотеками, средствами поиска и выбора;

v возможность разработки пользовательского интерфейса;

v поддержка стандартов OLE, ActiveX и доступ к библиотекам HTML или Java;

v поддержка разработки распределенных или двух- и трехзвенных клиент-серверных систем (работа с CORBA, DCOM, Internet).

Основные требования к блоку реализации:

Ш генерация кода полностью из диаграмм;

Ш возможность доработки приложений в клиент-серверных CASE-средствах типа Power Builder;

Ш реинжиниринг кодов и внесение соответствующих изменений в модель системы;

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

Основные требования к блоку инфраструктуры:

Ш наличие репозитория на основе базы данных, отвечающего за генерацию кода, реинжиниринг, отображение кода на диаграммах, а также обеспечивающего соответствие между моделями и программными кодами;

Ш обеспечение командной работы (многопользовательской работы и управление версиями) и реинжиниринга.

Сравнительный анализ CASE-систем показывает, что на сегодняшний день одним из наиболее приближенных к идеальному варианту CASE-средств является семейство Rational Rose фирмы Rational Software Corporation. Следует отметить, что именно здесь работают авторы унифицированного языка моделирования Г. Буч, Д. Рамбо и И. Джекобсон, под руководством которых ведется разработка нового CASE-средства, поддерживающего UML.

Выделим основные критерии оценки и выбора CASE-средств.

1. Функциональные характеристики:

ь среда функционирования: проектная среда, программное обеспечение/технические средства, технологическая среда;

ь функции, ориентированные на фазы жизненного цикла: моделирование, реализация, тестирование;

ь общие функции: документирование, управление конфигурацией, управление проектом;

2. Надежность;

3. Простота использования;

4. Эффективность;

5. Сопровождаемость;

6. Переносимость;

7. Общие критерии (стоимость, затраты, эффект внедрения, характеристики поставщика).

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

w применяемым методологиям и моделям систем и БД;

w степени интегрированности с СУБД;

w доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

ь средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

ь средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

ь средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

ь средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

ь средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

ь средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

ь средства конфигурационного управления (PVCS (Intersolv));

ь средства тестирования (Quality Works (Segue Software));

ь средства документирования (SoDA (Rational Software)).

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

ь Vantage Team Builder (Westmount I-CASE);

ь Designer/2000;

ь Silverrun;

ь ERwin+BPwin;

ь S-Designor;

ь CASE.Аналитик.

Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.

Литература

1. В. А. Лапшинский. Локальные сети персональных компьютеров. Часть II. М., МИФИ, 2004 г.

2. Линн Хабер. Ставка на будущее. LAN MAGAZINE, октябрь 2006 г.

3. Алексей Сень, Юрий Юшков. Телекоммуникации в банковских системах. Журнал "Банковские технологии", август 2005 г.

4. Горин С.В., Тандоев А.Ю. Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки данных. "СУБД", 1995, №3.

5. Горин С.В., Тандоев А.Ю. CASE-средство S-Designor 4.2 для разработки структуры базы данных. "СУБД", 1996, №1.

6. Банк В.С., Зверев В.С. Информационные технологии в экономике, - М.: Экономистъ, 2008;

7. Советов Я.Б. Информационные технологии: учебник для вузов. - М.: Ника-центр, 2007;

8. Титоренко Г.А. Информационные технологии управления. - М.: Экономистъ, 2008;

9. Фридланд А. Информатика - толковый словарь основных терминов. - М.:, Приор, 2007;

10. Шафрин Ю. Информационные технологии, - М.: ООО «Лаборатория базовых знаний», 2008;

Размещено на Allbest.ru

...