7 Вопрос(Моделирование предметной области информационной системы. Понятие жизненного цикла баз данных и информационных систем).

В основе проектирования ИС лежит моделирование предметной обла­сти. Для того чтобы получить адекватный предметной области проект ИС в виде системы правильно работающих программ, необходимо иметь це­лостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы. При этом под моделью предметной области понимается некоторая система, имитирую­щая структуру или функционирование исследуемой предметной области и отвечающая основному требованию — быть адекватной этой области.

Предварительное моделирование предметной области позволяет со­кратить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирова­ния предметной области велика вероятность допущения большого коли­чества ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроек­тирование системы. Вследствие этого все современные технологии проектирования ИС основываются на использовании методологии моде­лирования предметной области.

К моделям предметных областей предъявляются следующие требо­вания:

• формализация, обеспечивающая однозначное описание структуры предметной области;

• понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

• реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;

• обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей. Для реализации перечисленных требований, как правило, строится

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

Структурный аспект предполагает построение:

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

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

• структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;

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

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

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

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

Язык моде­лирования — это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графи­ческих объектов, используемых в модели. Нотация является синтаксисом языка моделирования. Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно форма­лизованного и однозначного определения проектных решений, подлежа­щих реализации в виде программных комплексов, образующих целост­ную систему программного обеспечения. 

Графическое изображение нередко оказывается наиболее емкой формой представления информации. При этом проектировщики должны учитывать, что графические методы документирования не могут полно­стью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации программ ЭВМ. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и в осо­бенности к программированию.

Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС.

Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:

• время решения задач;

• стоимостные затраты на обработку данных;

• надежность процессов;

  • косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рента­бельность и т.д.

Для расчета показателей эффективности, как правило, используют­ся статические методы функционально-стоимостного анализа (ABC) и динамические методы имитационного моделирования.

В основе различных методологий моделирования предметной обла­сти ИС лежат принципы последовательной детализации абстрактных ка­тегорий. Обычно, модели строятся на трех уровнях: на внешнем уровне (определении требований), на концептуальном уровне (спецификации тре­бований) и внутреннем уровне (реализации требований). Так, на внешнем уровнемодель отвечает на вопрос, что должна делать система, то есть оп­ределяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств. На концепту­альном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компо­нентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе? С позиции жизненного цикла ИС описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проек­тирования.

Жизненный цикл базы данных

Процесс проектирования, реализации и поддержания системы базы данных называется жизненным циклом базы данных (ЖЦБД). Процедура создания системы ЖЦБД состоит из следующих этапов: 1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация: ·   какие прикладные программы используются, и какие функции они выполняют; ·   какие файлы связаны с каждым из этих приложений; ·   какие новые приложения и файлы находятся в процессе работы. Данная информация помогает определить, как используется информация приложений, определить будущие требования к системе БД.Информация этого этапа документируется в виде обобщенной модели данных. 2. Проверка осуществимости. Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.: ·   технологическая осуществимость – есть ли технология для реализации запланированной БД? ·   операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД? ·   экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду? 3. Определение требований включает выбор целей БД, выяснение информационных требований к системе итребований к оборудованию и программному обеспечению. Таким образом, на данном этапе сбора данных и определения требований создаётся общая информационная модель, выражающаяся в следующих задачах: ·   Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы. ·   Определение пользовательских требований: документация в виде обобщённой информации (комментарии, отчёты, опросы, анкеты и т. д.); фиксация функций системы и определение прикладных систем, которые будут выполнять эти требования. Данные представляются в виде соответствующих документов. ·   Определение общих требований к оборудованию и программному обеспечению, связанных с поддержанием желаемого уровня быстродействия. (Выяснение количества пользователей системы, числа входных сообщений в день, количество распечаток). Данная информация используется для выбора типов компьютеров и СУБД, объёма дисков, количества принтеров. Данные этого этапа излагаются в отчёте, содержащем примерные конфигурации оборудования и программного обеспечения.  ·   Разработка плана поэтапного создания системы, включающий выбор исходных приложений. 4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации. Основным выходным документом является единая инфологическая модель (или схема БД на концептуальном уровне). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса. 5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы. 6.  Оценка и усовершенствование схемы БД. Включает опрос пользователей с целью выяснения функциональных неучтенных потребностей. При необходимости вносятся изменения, добавление новых программ и элементов данных по мере изменения и расширения потребностей.

Жизненный цикл информационных систем

Жизненный цикл информационных систем – это период их создания и использования, охватывающий различные состояния, начиная с момента возникновения необходимости в такой системе и заканчивая моментом ее полного выхода из употребления у пользователей. Жизненный цикл информационных систем включает в себя четыре стадии: предпроектную, проектировочную, внедрение, функционирование. От качества проектировочных работ зависит эффективность функционирования системы, поэтому каждая стадия разделяется на ряд этапов и предусматривает составление документации, отражающей результаты работ. На предпроектной стадии можно выделить следующие этапы: 1) Сбор материалов для проектирования – предусматривает разработку и выбор варианта концепции системы, выявление всех характеристик объекта и управленческой деятельности, потоков внутренних и внешних информационных связей, состава задач и специалистов, которые будут работать в новых технологических условиях, уровень их подготовки, как будущих пользователей системы. 2) анализ материалов и формирование документации – составление задания на проектирование, утверждение технико-экономического обоснования. Стадия проектирования делится на: 1) Этап технического проектирования – формируются проектные решения по обеспечивающей и функциональной частям информационной системы, моделирование производственных, хозяйственных, финансовых ситуаций, осуществляется постановка задачи и блок-схемы и их решение. 2) Этап рабочего проектирования – осуществляется разработка и доводка системы, корректировка структуры, создание различной документации: на поставку, на установку технических средств, инструкции по эксплуатации, должностные инструкции. Стадия внедрения информационной системы предполагает: 1) Подготовку к вводу в эксплуатацию – на этом этапе производится установка технически средств, настройка системы, обучение персонала, пробное использование. 2) Проведение опытных испытаний всех компонентов системы перед запуском. 3) Сдача в промышленную эксплуатацию, которая оформляется актом сдачи-приемки работ. На этапе функционирования информационной системы в рабочем режиме не исключается корректировка функций и управляющих параметров. Также осуществляется оперативное обслуживание и администрирование.

8 вопрос(ХарактеристикаCASE-средств моделирования предметных областей ИС.ПрограммыBP-win, ER-win как средства CASE-проектирования и их основные характеристики).

CASE-средства. Общая характеристика и классификация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Программы BP-win, ER-win как средства CASE-проектирования

AllFusionERwinDataModeler (ERwin) CASE-средство для проектирования и 

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

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

AllFusionERwinDataModeler (ERwin) позволяет наглядно отображать сложные структуры данных. Удобная в использовании графическая среда AllFusionERwinDataModeler упрощает разработку базы данных и автоматизирует множество трудоёмких задач, уменьшая сроки создания высококачественных и высокопроизводительных транзакционных баз данных и хранилищ данных. Данное решение улучшает коммуникацию организации, обеспечивая совместную работу администраторов и разработчиков баз данных, многократное использование модели, а также наглядное представление комплексных активов данных в удобном для понимания и обслуживания формате.

AllFusionProcessModeler 7 (ранее BPwin) - инструмент для моделирования, анализа, документирования и оптимизации бизнес-процессов. AllFusionProcessModeler 7 можно использовать для графического представления бизнес-процессов. Графически представленная схема выполнения работ, обмена информацией, документооборота визуализирует модель бизнес-процесса. Графическое изложение этой информации позволяет перевести задачи управления организацией из области сложного ремесла в сферу инженерных технологий.

AllFusionProcessModeler 7 (BPwin) помогает четко документировать важные аспекты любых бизнес-процессов: действия, которые необходимо предпринять, способы их осуществления и контроля, требующиеся для этого ресурсы, а также визуализировать получаемые от этих действий результаты. AllFusionProcessModeler 7 повышает бизнес-эффективность ИТ-решений, позволяя аналитикам и проектировщикам моделей соотносить корпоративные инициативы и задачи с бизнес-требованиями и процессами информационной архитектуры и проектирования приложений. Таким образом, формируется целостная картина деятельности предприятия: от потоков работ в небольших подразделениях до сложных организационных функций.

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

9 вопрос(Формирование сводок и документов с использованием баз данных информационных систем. Поиск и отбор информации в базе данных. Процесс прохождения пользовательского запроса. Структурированный язык запросов SQL. Характеристика, основные операторы языка SQL. Языки запросов. Подготовка отчетов. Упорядочение и группировка данных в отчете).

Для отбора информации из базы данных используется оператор SELECT языка SQL Оператор SELECT - это своего рода фильтр, который накладывается на базу данных, и таким образом круг поиска сужается до строк и столбцов С помощью оператора SELECT можно формировать разнообразные запросы к базе данных - от самого простого до сложного Формат оператора SELECT выглядит:

SELECT *

[FROM Имена таблиц]

[WHERE Условие отбора строк таблицы]

[GROUP BY Ключ сортировки]

[COMPUTE Функция генерации итоге]

[FOR BROWSE Разрешение на использование таблицы]

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

Директива FROM оператора SELECT используется для определения таблиц, из которых нужно выбирать строки и столбцы Ниже приведен пример оператора SELECT с директивой FROM, в которой указана таблица Ost t, т.е. данные буду отбираться только из таблицы Ost:

SELECT *

FROM Ost

В директиве FROM можно указывать несколько таблиц, как в следующем примере:

SELECT * FROM Ost, Klient

В этом примере в директиве FROM указаны две таблицы Ost и KUent (имена таблиц отделяются запятыми), из которых будут выбраны все строки и столбцы

Язык SQL позволяет выбирать таблицы из различных баз данных, базы данных и ее владелец в этом случае указываются слева через точку от имени таблицы В следующем примере приведены запрос к таблице Pay из базы данных МуСотрапу, владельцем которой является пользователь Dbo:

SELECT *

FROM МуСотрапуDboPay

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

SELECT'H_Rach, Nazva, Suma

FROM Ost

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

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

SELECT Отдел

FROM Сотрудники

GROUP BY Отдел