Вредоносное ПО (malware) - это назойливые или опасные программы,...
Для обеспечения сетевых коммуникаций используются сокеты. Сокет это конечная точка сетевых коммуникаций. Каждый использующийся сокет имеет тип и ассоциированный с ним процесс. Сокеты существуют внутри коммуникационных доменов. Домены это абстракции, которые подразумевают конкретную структуру адресации и множество протоколов, которое определяет различные типы сокетов внутри домена. Примерами коммуникационных доменов могут быть: UNIX домен, Internet домен, и т.д.
В Internet домене сокет - это комбинация IP адреса и номера порта, которая однозначно определяет отдельный сетевой процесс во всей глобальной сети Internet. Два сокета, один для хоста-получателя, другой для хоста-отправителя, определяют соединение для протоколов, ориентированных на установление связи, таких, как TCP.
- Создание сокета
- Привязка к локальным именам
- Установление связи
- Передача данных
- Закрывание сокетов
Создание сокета
Для создания сокета используется системный вызов socket.
S = socket(domain, type, protocol);
Этот вызов основывается на информации о коммуникационном домене и типе сокета. Для использования особенностей Internet, значения параметров должны быть следующими:
- communication domain - AF_INET (Internet протоколы).
- type of the socket - SOCK_STREAM; Этот тип обеспечивает последовательный, надежный, ориентированный на установление двусторонней связи поток байтов.
Выше был упомянут сокет с типом stream. Краткое описание других типов сокетов приведено ниже:
- Datagram socket - поддерживает двусторонний поток данных. Не гарантируется, что этот поток будет последовательным, надежным, и что данные не будут дублироваться. Важной характеристикой данного сокета является то, что границы записи данных предопределены.
- Raw socket - обеспечивает возможность пользовательского доступа к низлежащим коммуникационным протоколам, поддерживающим сокет-абстракции. Такие сокеты обычно являются датаграм- ориентированными.
Функция socket создает конечную точку для коммуникаций и возвращает файловый дескриптор, ссылающийся на сокет, или -1 в случае ошибки. Данный дескриптор используется в дальнейшем для установления связи.
Для создания сокета типа stream с протоколом TCP, обеспечивающим коммуникационную поддержку, вызов функции socket должен быть следующим:
S = socket(AF_INET, SOCK_STREAM, 0);
Привязка к локальным именам
Сокет создается без имени. Пока с сокетом не будет связано имя, удаленные процессы не имеют возможности ссылаться на него и, следовательно, на данном сокете не может быть получено никаких сообщений. Коммуникационные процессы используют для данных целей ассоциации. В Internet домене ассоциация складывается из локального и удаленного адреса и из локального и удаленного порта. В большинстве доменов ассоциация должна быть уникальной.
В Internet домене связывание сокета и имени может быть весьма сложным, но, к счастью, обычно нет необходимости специально привязывать адрес и номер порта к сокету, так как функции connect и send автоматически свяжут данный сокет с подходящим адресом, если это не было сделано до их вызова.
Для связывания сокета с адресом и номером порта используют системный вызов bind:
Bind(s, name, namelen);
Привязываемое имя (name) это строка байт переменной длины, которая интерпретируется поддерживаемым протоколом. Интерпретация может различаться в различных коммуникационных доменах.
Установление связи
Со стороны клиента связь устанавливается с помощью стандартной функции connect:
Error = connect(s, serveraddr, serveraddrlen);
которая инициирует установление связи на сокете, используя дескриптор сокета s и информацию из структуры serveraddr, имеющей тип sockaddr_in, которая содержит адрес сервера и номер порта на который надо установить связь. Если сокет не был связан с адресом, connect автоматически вызовет системную функцию bind.
Connect возвращает 0, если вызов прошел успешно. Возвращенная величина -1 указывает на то, что в процессе установления связи произошла некая ошибка. В случае успешного вызова функции процесс может работать с дескриптором сокета, используя функции read и write, и закрывать канал используя функцию close.
Со стороны сервера процесс установления связи сложнее. Когда сервер желает предложить один из своих сервисов, он связывает сокет с общеизвестным адресом, ассоциирующимся с данным сервисом, и пассивно слушает этот сокет. Для этих целей используется системный вызов listen:
Error = listen(s, qlength);
где s это дескриптор сокета, а qlength это максимальное количество запросов на установление связи, которые могут стоять в очереди, ожидая обработки сервером; это количество может быть ограничено особенностями системы.
Когда сервер получает запрос от клиента и принимает решение об установлении связи, он создает новый сокет и связывает его с ассоциацией, эквивалентной "слушающему сокету". Для Internet домена это означает тот же самый номер порта. Для этой цели используется системный вызов accept:
Newsock = accept(s, clientaddr, clientaddrlen);
Сокет, ассоциированный клиентом, и сокет, который был возвращен функцией accept, используются для установления связи между сервером и клиентом.
Передача данных
Когда связь установлена, с помощью различных функций может начаться процесс передачи данных. При наличии связи, пользователь может посылать и получать сообщения с помощью функций read и write:
Write(s, buf, sizeof(buf)); read(s, buf, sizeof(buf));
Вызовы send и recv практически идентичны read и write, за исключением того, что добавляется аргумент флагов.
Send(s, buf, sizeof(buf), flags); recv(s, buf, sizeof(buf), flags);
Могут быть указаны один или более флагов с помощью ненулевых значений, таких, как следующие:
- MSG_OOB - Посылать/получать данные, характерные для сокетов типа stream.
- MSG_PEEK - Просматривать данные без чтения. когда указывается в recv, любые присутствующие данные возвращаются пользователю, но сами данные остаются как "непрочитанные". Следующий read или recv вызванный на данном сокете вернет прочитанные в прошлый раз данные.
- MSG_DONTROUTE - посылать данные без маршрутизации пакетов. (Используется только процессами, управляющими таблицами маршрутизации.)
Закрывание сокетов
Когда взаимодействующие модули решают прекратить передачу данных и закрыть сеанс связи, они обмениваются трехсторонним рукопожатием с сегментами, содержащими установленный бит "От отправителя больше нет данных" (этот бит еще называется FIN бит).
Если сокет больше не используется, процесс может закрыть его с помощью функции close, вызвав ее с соответствующим дескриптором сокета:
Close(s);
Если данные были ассоциированы с сокетом, обещающим доставку (сокет типа stream), система будет пытаться осуществить передачу этих данных. Тем не менее, по истечении довольно таки длительного промежутка времени, если данные все еще не доставлены, они будут отброшены. Если пользовательский процесс желает прекратить любую передачу данных, он может сделать это с помощью вызова shutdown на данном сокете для его закрытия. Вызов shutdown вызывает "моментальное" отбрасывание всех стоящих в очереди данных. Формат вызова следующий:
Shutdown(s, how);
где how имеет одно из следующих значений:
- 0 - если пользователь больше не желает читать данные
- 1 - если данные больше не будут посылаться
- 2 - если данные не будут ни посылаться ни получаться
Пример функции, для установления WWW коннекции
/* MakeConnection Function allocates a socket and estabishes a connection with remote host. Default port number 80. Input: WWW server name (with port number, if it is not 80) Output: file descriptor on success -1 on error */ int MakeConnection(unsigned char* ServerName){ int s; struct sockaddr_in ssin; struct hostent* hp; int PortNum; unsigned char strHlp, *pch; /* use default port number - 80 or specific number from the server name */ strcpy(strHlp,ServerName); pch = strchr(strHlp,":"); if(pch==NULL){ PortNum = 80; }else{ pch = "\0"; pch++; PortNum = atoi(pch); if(PortNum==0){ PortNum = 80; } } /* get host by name - resolve host name into IP address */ if((hp=gethostbyname(strHlp)) == NULL) { return -1; } bzero(&ssin, sizeof(ssin)); bcopy(hp->h_addr, &ssin.sin_addr, hp->h_length); ssin.sin_family = hp->h_addrtype; ssin.sin_port = htons(PortNum); /* allocate a socket */ if((s=socket(AF_INET, SOCK_STREAM, 0))==-1) { return -1; } /* make a connection */ if(connect(s, &ssin, sizeof(ssin), 0)==-1){ return -1; } return s; /* socket descriptor */ }4 ответов
Короткий ответ заключается в том, что вы должны сделать все тяжелое поднятие себя. Вы можете получать уведомления о наличии данных для чтения, но вы не знаете, сколько байтов доступно. В большинстве протоколов IP, использующих пакеты с переменной длиной, будет заголовок с известной фиксированной длиной, добавленной к пакету. Этот заголовок будет содержать длину пакета. Вы читаете заголовок, получаете длину пакета, затем читаете пакет. Вы повторяете этот шаблон (прочитайте заголовок, затем прочитайте пакет), пока связь не будет завершена.
При чтении данных из сокета вы запрашиваете определенное количество байтов. Вызов чтения может блокироваться до тех пор, пока запрошенное количество байтов не будет прочитано, но оно может вернуть меньшее количество байтов, чем запрошено. Когда это произойдет, вы просто повторите чтение, запросив оставшиеся байты.
Здесь типичная функция C для чтения заданного количества байтов из сокета:
/* buffer points to memory block that is bigger than the number of bytes to be read */ /* socket is open socket that is connected to a sender */ /* bytesToRead is the number of bytes expected from the sender */ /* bytesRead is a pointer to a integer variable that will hold the number of bytes */ /* actually received from the sender. */ /* The function returns either the number of bytes read, */ /* 0 if the socket was closed by the sender, and */ /* -1 if an error occurred while reading from the socket */ int readBytes(int socket, char *buffer, int bytesToRead, int *bytesRead) { *bytesRead = 0; while(*bytesRead < bytesToRead) { int ret = read(socket, buffer + *bytesRead, bytesToRead - *bytesRead); if(ret <= 0) { /* either connection was closed or an error occurred */ return ret; } else { *bytesRead += ret; } } return *bytesRead; }
Итак, ответ на ваш вопрос зависит от того, используете ли вы UDP или TCP в качестве транспорта.
Для UDP жизнь становится намного проще, поскольку вы можете вызывать recv/recvfrom/recvmsg с требуемым размером пакета (скорее всего, вы отправите пакеты фиксированной длины из источника), и сделайте предположение, что если имеются данные, которые там представлены в нескольких размерах длины пакета. (I.E. Вы вызываете recv * с размером вашего отправляемого бокового пакета, и вы настроены.)
Для TCP жизнь становится немного более интересной - для целей этого объяснения я предполагаю, что вы уже знаете, как использовать функции socket(), bind(), listen() и accept() - последним является то, как вы получите файловый дескриптор (FD) вашего нового соединения.
Существует два способа ввода-вывода для блокировки сокетов, в которых вы вызываете read (fd, buf, N), и чтение находится там, и ждет, пока вы не прочитаете N байтов в buf - -блока, в котором вы должны проверить (используя select() или poll()), является ли FD доступным для чтения, а THEN - для чтения().
При работе с соединениями на основе TCP ОС не обращает внимания на размеры пакетов, поскольку считается непрерывным потоком данных, а не отдельными частями размера пакета.
Если ваше приложение использует "пакеты" (упакованные или распакованные структуры данных, которые вы просматриваете), вы должны иметь возможность вызвать read() с аргументом правильного размера и прочитать всю структуру данных из сокета в время. Единственное предостережение, с которым вам приходится иметь дело, состоит в том, чтобы помнить о том, что вы правильно заказываете данные, которые вы отправляете, в случае, если исходная и целевая системы имеют разные байтовые байты. Это относится как к UDP, так и к TCP.
Что касается программирования сокетов NIX, я настоятельно рекомендую W. Richard Stevens "Unix Network Programming, том 1" (UNPv1) и "Расширенное программирование в среде Unix" (APUE). Первый - это тома, касающийся сетевого программирования, независимо от транспорта, а последний - хорошая универсальная книга программирования, так как она применима к программированию на основе NIX. Также обратите внимание на "TCP/IP Illustrated", тома 1 и 2.
Когда вы читаете в сокете, вы рассказываете, сколько максимальных байтов читается, но если у него их не так много, оно дает вам, как многие из них есть. Вам решать разработать протокол, чтобы вы знали, есть ли у вас частичный пакет или нет. Например, в прошлом, когда вы отправляли двоичные данные переменной длины, я бы поставил int в начале, который сказал, сколько байтов ожидать. Я бы сделал чтение с запросом на количество байтов, большее, чем самый большой возможный пакет в моем протоколе, а затем я бы сравнил первый int с каким-то количеством байтов, которые я получил, и либо обработал его, либо попробовал прочитать больше, d получил полный пакет, в зависимости.
В рамках программной инженерии Case – средства представляют основную технологию, используемую для создания информационных систем.
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ЭИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО .
Наиболее трудоемкими стадиями разработки ПО являются стадии формирования требований и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение разнообразных графических моделей (диаграмм), использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает сотни различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.
6.2. ModelMaker как средство визуального проектирования концептуальной модели информационной системы
Case – средство ModelMaker – это инструмент объектно - ориентированного проектирования информационных систем. Он базируется на последних стандартах языка проектирования UML .
Утилита ModelMaker разработана голландской фирмой ModelMaker Tools. Она работает с Delphi, но в то же время неотъемлемой частью Delphi не является и устанавливается самостоятельно.
CASE – инструмент ModelMaker берет на себя значительную часть «рутинной работы» по составлению программного кода, позволяя разработчику сосредоточиться на творческой стороне этого процесса.
ModelMaker обеспечивает двунаправленную связь между моделью и исходным кодом программы. Таким образом, создав визуальную модель, например, различных классов и их взаимодействия, можно легко получить программный код, реализующий данную модель.
И наоборот, существующие Delphi – коды простым способом преобразуются (полностью или частично) в визуальные модели. При этом ModelMaker включает элементы так называемого рефакторинга – изменения местоположения классов в иерархии наследования с мгновенным переносом на исходный код, без потери созданной ранее реализации отдельных методов.
ModelMaker, как и другие CASE - средства проектирования, позволяет вести удобное документирование проекта.
ModelMaker можно запустить через главное меню Windows или непосредственно из Delphi версий 7, 10 и др.
Окно ModelMaker изображено на рисунке 24. Оно имеет главное меню, панели инструментов, страницы компонентов. В левом верхнем углу окна имеется список разделов: Classes, Units, Diagrams (Классы,
Рисунок 24 Основной экран ModelMaker
Модули, Диаграммы). При выделении каждый из них открывает собственное окно, предназначенное для создания соответствующих объектов моделирования. Так, например, раздел «Диаграммы» позволяет визуально конструировать основные типы диаграмм языка моделирования UML. К ним относятся:
Диаграммы вариантов использования (Use Case Diagram);
Диаграммы последовательности (Sequence Diagram);
Кооперативные диаграммы (Collaboration Diagram);
Диаграммы классов (Class Diagram) и другие.
Пиктограммы создания соответствующих диаграмм располагаются ниже списка разделов.
В верхней части окна располагаются вкладки компонентов. Каждая из них раскрывает набор компонентов, применяемых для моделирования информационных систем. Например, вкладка Diagram Editor предназначена для создания различных диаграмм. Для раздела «Добавить диаграмму вариантов использования» (Add Use Case Diagram) она имеет следующие пиктограммы:
Add Actor -Добавить действующее лицо,
Add Use Case -Добавить вариант использования,
Add Actor Communication -Добавить связь действующего лица,
Add Annotation -Добавить комментарий
и другие.
Принцип добавления компонентов в диаграмму аналогичен технологии визуального проектирования в Delphi интерфейсной части приложения. Также является интуитивно понятной технология редактирования диаграмм.
Таким образом, ModelMaker относительно просто позволяет словесное описание предметной области и требований, предъявляемых к будущей информационной системе, преобразовать в шаблон программного кода.
Задача решается путем создания модели проектируемой системы. Методика создания модели на языке UML заключается в последовательном построении диаграмм вариантов использования, взаимодействия и классов. При этом используется технология визуального проектирования.
Диаграмма классов, описывающая архитектуру проектируемой системы, автоматически преобразуется с помощью нескольких команд в шаблон программного кода на языке Delphi. Дальнейшее написание текста операций классов осуществляется вручную с помощью интегрированной системы Delphi.
ModelMaker также позволяет при проектировании информационной системы вести документирование всех объявляемых объектов.
Хотя информационные системы являются обычным программным продуктом, они имеют ряд существенных отличий от стандартных прикладных программ и систем .
В зависимости от предметной области информационные системы могут очень сильно различаться по своим функциям, архитектуре, реализации. Однако можно выделить ряд свойств, которые являются общими:
1. информационные системы предназначены для сбора, хранения и обработки информации. Поэтому в основе любой из них лежит среда хранения и доступа к данным;
2. информационные системы ориентируются на конечного пользователя, не обладающего высокой квалификацией в области применения вычислительной техники. Поэтому клиентские приложения информационной системы должны обладать простым, удобным, легко осваиваемым интерфейсом, который предоставляет конечному пользователю все необходимые для работы функции, но в то же время не дает ему возможность выполнять какие-либо лишние действия.
Таким образом, при разработке информационной системы приходится решать две основные задачи:
1. задачу разработки базы данных, предназначенной для хранения информации;
2. задачу разработки графического интерфейса пользователя клиентских приложений.
База данных - это, прежде всего, набор таблиц. Таблицу можно представлять себе как двумерную таблицу с характеристиками (атрибутами) какого-то множества объектов. Таблица имеет имя - идентификатор, по которому на нее можно сослаться.
Столбцы таблицы соответствуют тем или иным характеристикам объектов - полям. Каждое поле характеризуется именем и типов хранения данных. Имя поля - это идентификатор, который используется в различных программах для манипуляции данными.
Тип поля характеризует тип хранящихся в поле данных.
Каждая строка таблицы соответствует одному из объектов. Она называется записью и содержит значения всех полей, характеризующие данный объект.
При составлении таблиц баз данных важно обеспечивать непротиворечивость информации. Обычно это делается введением ключевых полей - обеспечивающих уникальность каждой записи. Ключевым может быть одно или несколько полей.
База данных обычно содержит не одну, а множество таблиц. Отдельные таблицы, конечно, полезны, но гораздо больше информации можно извлечь именно из совокупности таблиц.
В связанных таблицах обычно одна выступает как главная, а другая или несколько других - как вспомогательные, управляемые главной. Главная и вспомогательная таблицы связываются друг с другом ключом. В качестве ключа могут выступать какие-то поля, присутствующие в обеих таблицах.
Создают базы данных и обрабатывают запросы к ним системы управления базами данных - СУБД. Разные СУБД по-разному организуют и хранят базы данных. Например, Paradox и dBase используют для каждой таблицы отдельный файл.
В этом случае база данных - это каталог, в котором хранятся файлы таблиц. В Microsoft Access и InterBase несколько таблиц хранится как один файл. В этом случае база данных - это имя файла с путем доступа к нему. Системы типа клиент/сервер, такие, как серверы Sybase или Microsoft SQL, хранят все данные на отдельном компьютере и общаются с клиентом посредством специального языка, называемого SQL .
Поскольку конкретные свойства баз данных очень разнообразны, пользователю было бы весьма затруднительно работать, если бы он должен был указывать в своем приложении все эти каталоги, файлы, серверы, да и приложение часто пришлось бы переделывать при смене, например, структуры каталогов и при переходе с одного компьютера на другой. Чтобы решить эту проблему, используют псевдонимы данных.
Псевдоним (alias) содержит всю информацию, необходимую для обеспечения доступа к базе данных. Эта информация сообщается только один раз при создании псевдонима. А приложение для связи с базой данных использует псевдоним.
В этом случае приложению безразлично, где физически расположена та или иная база данных, а часто безразлична и СУБД, создавшая и обслуживающая эту базу данных. При смене каталогов, сервера и т.п. ничего в приложении переделывать не надо. Достаточно, чтобы администратор базы данных ввел соответствующую информацию в псевдоним .
При работе с базами данных часто используется кэширование всех изменений. Это означает, что все изменения данных, вставка новых записей, удаление существующих записей, то есть все манипуляции с данными, проводимые пользователем, сначала делается не в самой базе данных, а запоминаются в памяти во временной, виртуальной таблице. И только по особой команде после всех проверок правильности вносимых в таблицу данных, пользователю представляется возможность или зафиксировать все эти изменения в базе данных, или отказаться от этого и вернуться к тому состоянию, которое было до начала редактирования.
Фиксация изменений в базе данных осуществляется с помощью транзакций. Это совокупность команд, изменяющих базу данных.
На протяжении транзакции пользователь может что-то изменять в данных, но это только видимость. В действительности все изменения сохраняются в памяти. И пользователю предоставляется возможность завершить транзакцию или внесением всех изменений в реальную базу данных, или отказом от этого с возвратом к тому состоянию, которое было до начала транзакции .
Для создания базы данных, в рамках разрабатываемой программы, была выбрана СУБД Paradox.
Paradox является очень распространённым форматом для работы с базами данных самых различных языков программирования. Является "родным" для программных сред от фирмы Борланд: Delphi, СBuilder. Из этих сред работа с таблицами в формате Paradox очень простая. BDE - "родной" и самый быстрый способ доступа. Установка - автоматическая, проблема может быть только одна - на больших винчестерах программа инсталляции может неправильно определять объём свободного места и не ставится (выход - временно занять свободное место, оставив свободным только 1 гигабайт на время установки). Настройка не требуется. Практически не конфликтует с другим софтом, поддерживаются все стандартные конструкции SQL .
При разработке структуры БД было принято решение о создании четырех таблиц:
1) Таблица "Сотрудники"
2) Таблица "Отдел"
3) Таблица "Образование"
4) Таблица "Семейное положение"
Выбор концептуальной модели
Для выбора концептуальной модели данных были рассмотрены три их разновидности:
1. Семантическая модель;
2. Фреймы;
3. Модель "сущность-связь".
Семантическая модель основывается на построении семантической сети. Под семантической сетью понимают ориентированный граф, состоящий из помеченных вершин и дуг и задающий объекты и отношения предметной области. Семантические сети обладают рядом достоинств, а именно:
1. Описание объектов предметной области происходит естественным языком;
2. Все записи, поступающие в БД накапливаются в относительно однородной структуре.
Но, несмотря на эти преимущества, семантическая модель данных обладает рядом недостатков, один из которых и наиболее существенный, заключается в том, что построение реляционной модели данных на основе семантических сетей затруднено.
Фреймы выражаются структурами данных с привязанными процедурами обработки этих данных. Фреймы могут быть следующих видов: событийные, характеристики, логические предикаты . Использование фреймовой модели так же нецелесообразно, поскольку данная модель не отражает типы связей в реляционной модели данных .
Модель "сущность-связь" описывается в терминах сущность, связь, значение. Сущность - понятие, которое может быть идентифицировано. Связь - соединение сущностей. Для представления связей и сущностей введен специальный метод: ER-диаграмма . Различаются сущности трех основных классов: стержневые, ассоциативные и характеристические.
Стержневая сущность - это независимая сущность (ей свойственно независимое существование). Ассоциативная сущность или ассоциация рассматривается как связь между двумя или более сущностями типа "многие-ко-многим" или подобные им. Характеристическая сущность (или характеристика) представляет собой сущность, единственная цель которой, в рамках рассматриваемой предметной области, состоит в описании или уточнении некоторой другой сущности.
ER-диаграма - графическое представление взаимосвязей сущностей. Каждое множество сущностей представляется прямоугольником, а множество связей - ромбом. Связи могут быть трех типов: "один-к-одному", "один-ко-многим", "многие-ко-многим". Данные типы связи присущи реляционной модели, как и сущности, которым в реляционной модели соответствуют таблицы.
Вывод: в связи с тем, что модель "сущность-связь" наиболее близка по принципам организации к реляционной модели и реализация последней на основе первой наиболее удобна, то в качестве концептуальной модели выбрана модель "сущность-связь".
Обзор средств проектирования информационных систем
А.М.Вендров, Центральный банк РФ
Цель данного доклада - попытаться описать и обосновать один из возможных подходов к анализу и выбору средств проектирования информационных систем достаточно крупного масштаба (здесь намеренно не используется термин "CASE-средство", поскольку большинство известных CASE-средств в лучшем случае позволяют описать будущие приложения лишь в самом общем виде). Конечный результат выбора ни в коем случае не следует рассматривать как нечто абсолютное, он отражает лишь мнение конкретного коллектива разработчиков, утвердившееся на заданном временном интервале.Под средствами проектирования информационных систем (СП ИС) будем понимать комплекс инструментальных средств, обеспечивающих в рамках выбранной методологии проектирования поддержку полного жизненного цикла (ЖЦ) ИС, который включает в себя, как правило, стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию. Каждый этап характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. При анализе СП их следует рассматривать не локально, а в комплексе, что позволяет реально охарактеризовать их достоинства, недостатки и место в общем технологическом цикле создания ИС.В общем случае стратегия выбора СП для конкретного применения зависит от следующих факторов:·характеристик моделируемой предметной области; ·целей, потребностей и ограничений будущего проекта ИС, включая квалификацию участвующих в процессе проектирования специалистов; ·используемой методологии проектирования.
Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности ИС, создаваемых в различных областях экономики. Современные сложные ИС и проекты, обеспечивающие их создание, характеризуются, как правило, следующими особенностями:·сложность предметной области (достаточно большое количество функций, объектов, атрибутов и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов; ·наличие совокупности тесно взаимодействующих компонентов - подсистем, имеющих свои локальные задачи и цели функционирования; ·иерархическую структуру взаимосвязей компонентов, обеспечивающую устойчивость функционирования системы; ·иерархическую совокупность критериев качества функционирования компонентов и ИС в целом, обеспечивающих достижение главной цели - создания и последующего применения системы; ·отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем; ·необходимость достаточно длительного сосуществования старых приложений и вновь разрабатываемых БД и приложений; ·наличие потребности как в традиционных приложениях, связанных с обработкой транзакций и решением регламентных задач, так и в приложениях аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема; ·поддержка одновременной работы достаточно большого количества локальных сетей, связываемых в глобальную сеть масштаба предприятия, и территориально удаленных пользователей; ·функционирование в неоднородной операционной среде на нескольких вычислительных платформах; ·разобщенность и разнородность отдельных микроколлективов разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств; ·существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Методология проектирования определяется как совокупность трех составляющих:·пошаговой процедуры, определяющей последовательность технологических операций проектирования; ·критериев и правил, используемых для оценки результатов выполнения технологических операций; ·нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
На выбор СП могут существенно повлиять следующие особенности методологии проектирования:·ориентация на создание уникального или типового проекта; ·итерационный характер процесса проектирования; ·возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей; ·жесткая дисциплина проектирования и разработки при их коллективном характере; ·необходимость отчуждения проекта от разработчиков и его последующего централизованного сопровождения.
Критерии выбора
Традиционно при обсуждении проблемы выбора СП (в особенности CASE-средств) большое внимание уделялось особенностям реализации той или иной методологии анализа предметной области (E-R, IDEF0, IDEF1Х, Gane/Sarson, Yordon, Barker и др.). Безусловно, богатство изобразительных и описательных средств дает возможность на этапах стратегического планирования и анализа построить наиболее полную и адекватную модель предметной области. С другой стороны, если говорить о конечных результатах - базах данных и приложениях, то обнаруживается, что часть описаний в них практически не отражается, оставаясь чисто декларативной (на выходе мы в любом случае получим описание БД в табличном представлении с минимальным набором ограничений целостности и исполнимый код приложений, большую часть которых составляют экранные формы, не выводимые непосредственно из моделей предметной области). Опытные аналитики и проектировщики всегда с большими или меньшими трудозатратами придут к нужному конечному результату независимо от того, какая конкретно методология или ее разновидность реализована в данном инструменте. Это, конечно, не означает, что методология не важна, напротив, отсутствие или неполнота описательных средств могут с самого начала значительно затруднить работу над проектом. Однако, зачастую на первом плане оказываются другие критерии, невыполнение которых может породить гораздо большие трудности.Может создаться впечатление, что если можно сформировать необходимую аппаратную платформу из компонентов различных фирм-производителей, то так же просто можно выбрать и скомплексировать разные инструментальные средства, каждое из которых является одним из мировых лидеров в своем классе. Однако в случае инструментальных средств в настоящее время, в отличие от оборудования, отсутствуют международные стандарты на основные свойства конечных продуктов (программ, баз данных и их сопряжение). Однако, поскольку составные части проекта должны быть интегрированы в единый продукт, следовательно, имеет смысл рассматривать не любые, а только сопряженные инструментальные средства, которые в принципе могут быть ориентированы - даже внутри одного класса - на разные методологии; при этом необходимо отбирать в состав комплекса СП средства, поддерживающие по крайней мере близкие методологии, если не одну и ту же.Исходя из перечисленных выше соображений, примем в качестве основных критериев выбора СП следующие критерии:
Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее развития.Полный жизненный цикл ИС должен поддерживаться "сквозной" технологической цепочкой средств разработчика, обеспечивающей решение следующих задач:·обследование и получения формализованных знаний о предметной области (последовательный и логически связный переход от формализованного описания предметной области к ее моделям); ·декомпозиция проекта на составные части и интеграция составных частей; ·проектирование моделей приложений (логики приложений и пользовательских интерфейсов); ·прототипирование приложений; ·проектирование баз данных; ·коллективная, территориально распределенная разработка приложений с использованием различных инструментальных средств (включая их интеграцию, тестирование и отладку); ·разработка распределенных баз данных (с выбором оптимальных вариантов распределения); ·разработка проектной документации с учетом требований проектных стандартов; ·адаптация к различным системно-техническим платформам и СУБД; ·тестирование и испытания; ·сопровождение, внесение изменений и управление версиями и конфигурацией ИС; ·интеграция с существующими разработками (включая реинжиниринг приложений, конвертирование БД); ·администрирование ИС (оптимизация эксплуатационных характеристик); ·управление разработкой и сопровождением ИС (планирование, координация и контроль за ресурсами и ходом выполнения работ); ·прогнозирование и оценка трудоемкости, сроков и стоимости разработки.
Для существующих ИС должен обеспечиваться плавный переход из старой среды эксплуатации в новую с минимальными переделками и поддержкой эксплуатируемых баз данных и приложений, внедренных до начала работ по созданию новой системы.
Обеспечение целостности проекта и контроля за его состоянием.Данное требование означает наличие единой технологической среды создания, сопровождения и развития ИС, а также целостность базы проектных данных (репозитория). Единая технологическая среда должна обеспечиваться за счет использования единственной CASE-системы для поддержки моделей ИС, а также за счет наличия программно-технологических интерфейсов между отдельными инструментальными средствами, сертифицированных и поддерживаемых фирмами- разработчиками соответствующих средств. В частности, интерфейс между CASE-системой и средствами разработки приложений должен выполнять две основные функции: а) непосредственный переход в рамках единой среды от описания логики приложения, реализованного CASE-системой, к разработке пользовательского интерфейса (экранных форм); б) перенос описания БД из репозитория CASE-системы в репозиторий средства разработки приложений и обратно. Вся информация о проекте должна автоматически помещаться в базу проектных данных, при этом должны поддерживаться согласованность, непротиворечивость, полнота и минимальная избыточность проекта, а также корректность операций его редактирования. Это может быть достигнуто при условии исключения или существенного ограничения возможности актуализации репозитория различными средствами. Должны также обеспечиваться возможности для централизованного сбора, хранения и распределения информации между различными этапами проекта, группами разработчиков и выполняемыми операциями. Поддержка базы проектных данных может быть реализована собственными средствами СП или средствами целевой СУБД (второй вариант предпочтительнее, поскольку упрощается технология ведения репозитория).Невыполнение требования целостности в условиях разобщенности разработчиков и временной протяженности крупного проекта может означать утрату контроля за его состоянием.
Независимость от программно-аппаратной платформы и СУБД.Требование определяется неоднородностью среды функционирования ИС. Такая независимость может иметь две составляющих: независимость среды разработки и независимость среды эксплуатации приложений. Она обеспечивается за счет наличия совместимых версий СП для различных платформ и драйверов соответствующих сетевых протоколов, менеджеров транзакций и СУБД.Один из дополнительных факторов, который при этом следует учитывать - это способ взаимодействия с СУБД (прямой или через ODBC), поскольку использование ODBC может заметно ухудшить производительность и надежность интерфейса.
Поддержка одновременной работы групп разработчиков.Развитые СП должны обладать возможностями разделения полномочий персонала разработчиков и объединения отдельных работ в общий проект. Должна обеспечиваться одновременная работа проектировщиков БД и разработчиков приложений (разработчики приложений в такой ситуации могут начинать работу с базой данных, не дожидаясь полного завершения ее проектирования CASE-средствами).
