технология проектирования ИС. Реферат на тему _Технологии проектирования ИС_. Лекция Технологии проектирования ис 1 Основные определения
 Скачать 0.49 Mb.
|
|
пошаговое тестирование - последовательная проверка процедур и логики программ предпринимается на этапе разработки системы группой разработчиков и пользователей системы. Упор делается на проверку входов, файлов, выходов и потоков данных в организации. Пошаговая проверка, проводимая программистами, сосредотачивается на структуре программного кода; обработка тестовых операций нацелена на проверку правильности работы программы. Обрабатываются как правильные данные, так и данные, содержащие ошибки, чтобы убедиться в том, что ошибки будут обнаружены системой и правильно обработаны. Чтобы оценить результаты такого тестирования, заранее определяется желаемая реакция системы; обработка реальных операций использует не модельные, а копии реальных данных об операциях. Этот тип проверки обычно проводится пользователями системы, знающими процедуры компании и определяющими, правильно ли система себя повела при обработке. Даже программное обеспечение, купленное в готовом виде, должно быть протестировано перед установкой. Невыполнение этих требований дорого обходится организациям, доверяющим свои деньги и репутацию системам, которые не подверглись тщательной проверке. 3.5.7. Переход на новую систему Переход на новую систему - это процесс смены старой ИС на новую. Это неизбежный этап, имеющий свои особенности. Заменены или преобразованы должны быть многие элементы: программное и аппаратное обеспечение, файлы данных и процедуры. Этот процесс можно считать завершенным, когда новая ИС становится обычной работающей частью деятельности организации. При таком переходе может быть применен один из следующих подходов (рис.3.6)  Рис.3.6. Методы перехода на новую систему Прямой переход означает, что старая ИС выводится из эксплуатации сразу при появлении новой. Он применяется, когда старая ИС не представляет больше ценности или новая настолько отличается от нее в лучшую сторону, что их сравнение лишено смысла. Этот подход не связан с дополнительными затратами, но является более рискованным, чем остальные, т.к. не предусматривает подстраховки на случай выявления недостатков новой системы. Параллельный переход предусматривает совместное функционирование старой и новой систем в течение какого-то времени, пока новая ИС не докажет свою работоспособность. Такой метод связан с дублированием обработки всех данных компании и сопровождается большими затратами, однако является самым надежным. На практике компании подвергаются риску и испытывают проблемы в период перехода, поэтому данный метод пользуется большой популярностью. Последовательный переход применяется, когда возможна замена элементов (например, подсистемы учета кадров, учета материально-производственных запасов, платежей и т.д.) ИС одного за другим. Такой подход связан со специальным проектированием новой системы, возможен не для всякой старой ИС и требует разработки временных подсистем, предназначенных специально для обеспечения совместной работы старых и новых блоков. При этом процесс перехода усложняется и требует большего времени. Переход по подразделениям применяется в организациях, имеющих относительно самостоятельные и однородные подразделения (например, системы магазинов, банк со многими отделениями и т.д.), в которых предполагается устанавливать однотипные ИС, связывая их затем в единую систему. В каждом из подразделений переход может осуществляться одним из перечисленных выше методов. Преимуществами является локализация проблем перехода и возможность обучения персонала других подразделений на реально работающих системах. Недостатки - большое время перехода и необходимость создавать подсистемы для обеспечения совместной работы старых и новых ИС в разных подразделениях. С переходом на новую ИС связана еще одна проблема - преобразование данных. Довольно часто сложность и значение этой проблемы недооцениваются. Файлы данных могут потребовать модификации в трех аспектах: смены носителя. Файлы могут потребовать переноса, например, с магнитных лент на магнитные диски для обеспечения более быстрого доступа к ним. смены содержания. Например, для описания изменений в деятельности организации могут быть добавлены или удалены отдельные поля или таблицы. смены формата. Одно и то же содержание может храниться в разных форматах. Выбор формата файла связан с использующимися инструментальными средствами для разработки программ. Например, разные СУБД могут хранить свои файлы в разных форматах. Проблема преобразования данных возникает потому, что новые ИС как правило решают расширенный круг задач и применяют более современные программные и аппаратные средства. Само преобразование данных состоит из нескольких этапов: решения вопроса о том, какие файлы данных должны быть преобразованы; проверки полноты и устранение неточностей; собственно преобразования данных; проверки новых файлов на предмет корректности преобразования. Если преобразование было длительным, то новые файлы должны быть обновлены операциями, произошедшими в период преобразования. Только после этого новая ИС сможет нормально выполнять свои обязанности, однако она должна некоторое время контролироваться, чтобы убедиться в успешности преобразования данных. 3.6. Эксплуатация и обслуживание Последний шаг жизненного цикла разработки системы - ее эксплуатация и обслуживание. Чтобы убедиться, что установленная ИС удовлетворяет запланированным целям, проводится ее инспекция после внедрения, затем готовится отчет об инспектировании. Лекция 5. Базы данных В ИС одним из главных инструментов моделирования деятельности организации являются базы данных. В этом разделе обсуждается: Как ИС моделирует деятельность организации. Что нужно знать экспертам организации о разработке баз данных. 5.1. Системы управления базами данных Данные организации, которая использует ИС, являются одним из ее главных активов. Они хранятся в базах данных (БД) и предоставляются пользователям, интересующимся различными вопросами. Например, менеджер по продажам может поинтересоваться списком клиентов в табличной форме, производственный менеджер - заказами, находящимися на исполнении, высшее руководство может захотеть проанализировать структуру продаж в графической форме по регионам или магазинам. Все это различные примеры логического представления данных. И хотя существует огромное количество разных способов просмотреть данные, все же они не хранятся в форме, сразу пригодной для каждого из таких представлений. Данные хранятся в едином физическом представлении, например в индексно-последовательных файлах. Одной из задач системы управления базой данных (СУБД или database management system - DBMS) является перевод логического представления каждого пользователя в физическое представление данных, чтобы они могли просмотреть то, что хотят (рис.5.1). Часто физическое представление данных сильно отличается от того, как пользователи их получают. Например, баланс клиента, его имя и кредитная история могут храниться в разных файлах и даже на разных компьютерах. СУБД скрывает детали физического представления от пользователей, чтобы они могли сконцентрироваться на логических взаимоотношениях различных показателей.  Рис. 5.1. Функция СУБД Часто физическое представление данных сильно отличается от того, как пользователи их получают. Например, баланс клиента, его имя и кредитная история могут храниться в разных файлах и даже на разных компьютерах. СУБД скрывает детали физического представления от пользователей, чтобы они могли сконцентрироваться на логических взаимоотношениях различных показателей. Чтобы обеспечить предоставление нужных данных нужным пользователям и скрыть информацию от тех, кто ее не должен знать, в базах данных используется два механизма - авторизация пользователей (каждый, кто обращается к БД, должен назвать свое имя и свой пароль) и справочник данных (специальный служебный файл, который для каждого элемента данных содержит его описание, в том числе - кому разрешен его просмотр), который часто называют словарем данных, т.к. от его содержимого зависит, на каком языке “разговаривает” БД, как называет свои элементы. 5.1.1. Схемы баз данных Схема описывает логическую структуру БД. Существует три уровня схем: концептуальная, внешняя и внутренняя (рис.5.2) Концептуальная схема дает общий взгляд на организацию всей БД. Она перечисляет все элементы данных и отношения между ними. Внешняя схема состоит из набора логических представлений пользователей, каждое из которых называется подсхемой. Внутренняя схема представляет структуру базы данных. Она описывает, как данные на самом деле хранятся, включая информацию об указателях, индексах, длине записей и т.д. Между схемами этих уровней существует соответствие, называемое отображением. Это правила преобразования одного представления в другое. СУБД использует отображения схем для вывода и ввода данных. При создании БД для ИС эксперты организации (менеджеры, бухгалтеры) привлекаются для разработки схем концептуального и внешнего уровня. Поэтому им важно понимать разницу между этими типами схем. Например, для описания розничных продаж база данных на концептуальном уровне может содержать информацию о клиентах, продажах, кассовых операциях, продавцах и кассирах, товарах, счетах. На внешнем уровне из этой схемы может быть получено множество подсхем, каждая из которых предназначена для потребностей отдельных пользователей и должна скрывать от них данные, не относящиеся к выполнению их обязанностей. Так, внешняя подсхема для служащего, оформляющего заказы, может содержать данные о кредитных лимитах и текущих балансах клиентов, количестве товаров на складе и их ценах, но не будет включать информацию о закупочной стоимости товаров или текущих банковских счетах компании. Внешняя подсхема для служащих, обеспечивающих доставку товаров, будет содержать информацию об адресах клиентов, но не об их текущих балансах.  Рис. 5.2. Три уровня схем базы данных 5.1.2. Использование языков СУБД Любая СУБД должна обеспечивать три базовых функции - создание, изменение и запросы к базе данных. Наборы команд, которые используются для выполнения этих функций, называются соответственно языком описания данных, языком управления данными и языком описания запросов. Эти языки призваны упростить работу с БД, поскольку при работе с данными позволяют оперировать именами полей, таблиц, индексов вместо описания физического расположения этих элементов. Язык описания данных (ЯОД или data definition language - DDL) используется для построения справочника данных (1), создания или инициализации БД (2), описания логического представления для каждого пользователя (3) и определения ограничений, обеспечивающих безопасность записей и полей БД (4). Язык управления данными (ЯУД или data manipulation language - DML) используется для обслуживания БД, т.е. выполнения операций обновления, вставки, удаления записей. Язык описания запросов (ЯОЗ, или data query language - DQL) используется для выбора данных из БД, их упорядочения и предоставления в ответ на запрос пользователей. 5.1.3. Функции СУБД и ее пользователей Обычно пользователи имеют доступ к языку описания запросов. Что касается ЯОД и ЯУД, то доступ к ним предоставляется только тем служащим, которые отвечают за администрирование и программирование СУБД. Это просто означает, что изменять содержимое БД могут не все пользователи, а только ответственные за это лица. Распределение обязанностей таких привилегированных пользователей - существенная часть жизни БД. Администратор данных отвечает за разработку политики и процедур управления всеми данными организации, а не только данными, хранящимися в БД. Другими словами, администратор данных отвечает за информационные потребности организации и в частности решает, какие данные будут храниться в БД. Администратор базы данных отвечает за координацию, контроль и управление БД. Он должен беспокоиться не только о пользователях и их информационных нуждах, но и о том, как БД работает и как в ней хранятся данные. Основные обязанности администратора БД - создание логической модели БД, установка стандартов данных, одобрение изменений в структуре БД, разработка методов выбора данных в соответствии с требованиями пользователей, определение и обслуживание физической структуры БД, ведение справочника данных, разработка и реализация методов контроля для обеспечения точности и сохранности БД. Для выполнения этих задач администратор БД использует ЯОД. Прикладные программисты пишут программы, призванные взаимодействовать с БД. Они используют ЯУД для доступа и изменения содержимого БД. 5.2. Реляционные базы данных СУБД характеризуются различными логическими моделями, на которых они основаны. Модель данных - это абстрактное представление о содержимом БД. 5.2.1. Реляционная модель данных Большинство современных СУБД являются реляционными и используют реляционную модель данных, которая представляет данные в виде таблиц. Однако следует помнить, что в терминах реляционной модели описываются только концептуальная и внешняя схемы, а на внутреннем уровне данные хранятся не в таблицах. Каждая таблица представляет одну сущность (например, товар), каждая строка в таблице содержит данные об одном экземпляре этой сущности (например, о конкретном товаре). Каждый столбец таблицы соответствует одному атрибуту сущности (например цене, коду поставщика или количеству - таблица 5.1.). Реляционная модель данных накладывает ограничения на структуру таблиц, которые призваны обеспечить целостность и точность трактовки содержащихся в них данных. Некоторые из них кажутся очевидными, но они полезны на этапе моделирования данных. Таблица 5.1. Таблицы видов товаров и их поставщиков
Таблица 5.2
|