Краткое содержание предметных областей

Обновлено: 30.06.2024

Учебные предметы: Речь и альтернативная коммуникация.

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

Учебные предметы:Математические представления

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

Учебные предметы:Окружающий природный мир, Человек, Домоводство, Окружающий социальный мир.

Основные задачи реализации содержания:

Окружающий природный мир.

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

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

Окружающий социальный мир.

Формирование первоначальных представлений о мире, созданном человеком: о доме, школе, о расположенных в них и рядом объектах, о транспорте и т.д. Усвоение правил безопасного поведения в помещениях и на улице. Представления об окружающих людях: овладение первоначальными представлениями о социальной жизни, о профессиональных и социальных ролях людей. Развитие межличностных и групповых отношений. Накопление положительного опыта сотрудничества и участия в общественной жизни. Формирование представлений об обязанностях и правах ребенка. Представление о своей стране (Россия).

Учебные предметы:Музыка и движение, Изобразительная деятельность.

Основные задачи реализации содержания:

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

Изобразительная деятельность (лепка, рисование, аппликация).

Накопление впечатлений и формирование интереса к доступным видам изобразительного искусства. Формирование простейших эстетических ориентиров, (красиво – некрасиво)в практической жизни, и их использование в организации обыденной жизни и праздника. Освоение доступных средств изобразительной деятельности: лепка, рисование, аппликация; использование различных изобразительных технологий. Развитие способности к совместной изобразительной деятельности. Накопление опыта самовыражения в процессе изобразительной деятельности.

Учебные предметы: Речь и альтернативная коммуникация.

Учебные предметы:Математические представления

Учебные предметы:Окружающий природный мир, Человек, Домоводство, Окружающий социальный мир.

Основные задачи реализации содержания:

Окружающий природный мир.

Окружающий социальный мир.

Учебные предметы:Музыка и движение, Изобразительная деятельность.

Основные задачи реализации содержания:

Изобразительная деятельность (лепка, рисование, аппликация).

Целью данной курсовой работы является построение и реализация базы данных защиты распределенной базы данных от несанкционированного доступа.

Основными задачами, поставленными в ходе работы, являлись:

§ сбор, анализ и сортирование документов с целью описания предметной области;

§ отбор необходимых документов для создания базы данных;

§ выявление сущностей инфологической модели и моделирование связей между ними.

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

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

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

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

Системный анализ предметной области

Краткая характеристика предметной области

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

Суть модели файлового сервера состоит в том, что один из компьютеров в сети считается файловым сервером и предоставляет услуги по обработке файлов другим компьютерам. Файл-сервер работает под управлением сетевой операционной системы и играет роль компонента доступа к информационным ресурсам. На других компьютерах в сети функционирует приложение, в котором функции представления информации и логика прикладной обработки совмещены. Обращение за сервисом управления данными происходит через среду передачи с помощью операторов языка SQL или вызовом функций библиотеки API (Application Programming Interface – интерфейс прикладного программирования). Основное достоинство такой модели состоит в большом обилии готовых СУБД, имеющих SQL-интерфейсы, и существующих инструментальных сердств, обеспечивающих быстрое создание программ клиентской части. Средства разработки чаще всего поддерживают графический интерфейс пользователя в MS Windows, стандарт интерфейса ODBC и средства автоматической генерации кода.

Недостатки модели файл-сервер:

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

во время работы приложений обычно по сети передаются целые БД);

узкий спектр операций манипуляции с данными;

отсутствие надежных средств безопасности доступа к данным (защита только на уровне файловой системы).

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

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

СУБД, используемая в качестве сервера базы данных, обладает более совершенными средствами обработки данных

Так как обработка запросов осуществляется на сервере базы данных, а не на рабочей станции, рабочая станция называется клиентом сервера базы данных. При работе в режиме клиент-сервер серверная часть системы управления базами данных устанавливается на файл-сервере, а клиентская часть — на рабочей станции. В ряде случаев клиентская и серверная части являются отдельными компонентами одной СУБД (например, Oracle или SQLbase). В других случаях в качестве клиентской части используются настольные СУБД или специальные системы разработки приложений клиент/сервер (например, PowerBuilderили SQLWindows), а в качестве сервера базы данных — мощная СУБД типа Oracle или SQL Server.

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

первый – это сведение количества таких конфликтов к минимуму и

второй – разработка четкого алгоритма их разрешения.

Низкая конкуренция (случай 1)	Высокая конкуренция (случай 2)
Блокировка записи	Запись данных в переменные
Чтение записи	Чтение переменных
Полноэкранное редактирование
Запрос на сохранение данных
Сохранение данных	Блокировка записи
--	Запись данных из переменных в БД
Снятие блокировки с записи

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

При втором варианте продожительность блокировки не зависит от поведения пользователя. Это время будет определяться только продолжительностью записи данных. Во время редактирования данные продолжают оставаться доступными для других пользователей. Хорошо ли это? Отлично, мы достигли потрясающей гибкости! Но в то же время получили массу забот, так как во время редактирования данных одним пользователем их может изменить и другой. При таком подходе есть риск, что после того, как первый пользователь успешно модифицирует запись, ее тут же освежит и второй работник, который в глаза не видел обновленных первым абонентом сети данных. Ведь у него на экране были данные из БД до их изменения первым пользователем.

Для решения этих проблем в СУБД предлагается использовать буферизацию данных. Рассмотрим типичный набор блокировок:

отсутствие буферизации.

пессимистическая буферизация записи;

оптимистическая буферизация записи;

пессимистическая буферизация таблицы;

оптимистическая буферизация таблицы.

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

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

Рис.1 Функции для работы с буферизованной таблицей

OLDVAL() – возвращает первоначальное значение поля, которое было модифицировано, но не обновлялось.

CURVAL() – возвращает значение поля непосредственно с диска или из удаженного источника.

TABLEUPDATE() – фиксирует изменения, внесенные в буферизованную запись либо в буферизованную таблицу или курсор.

TABLEREVERT() – сбрасывает изменения, внесенные в буферизованную запись либо в буферизованную таблицу или курсор и восстанавливает содержимое по данным OLDVAL().

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

RECNO() - возвращает номер текущей записи в текущей или заданной таблице

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

Если вы решили управлять блокировкой вручную, то придерживайтесь следующего алгоритма:

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

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

если ресурсы блокированы, попробуйте еще раз, но при этом следует избегать слишком частых попыток. Кроме чрезмерной загрузки сети это ни к чему не приведет.

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

Пользователь 1	Пользователь 2
Попытка блокировать запись 1	Попытка блокировать запись 4
Попытка блокировать запись 4	Попытка блокировать запись 1
Если попытка неудачна, ждлем освобождения ресурсов	Если попытка неудачна, ждлем освобождения ресурсов
Ждем, ждем, ждем …	Ждем, ждем, ждем …

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

Ряд команд и функций автоматически обеспечивают снятие блокировки:

Закрытие таблицы

Завершение транзакции

Завершение сеанса работы с СУБД

Фиксация изменений, внесенных в буферизованную запись или таблицу

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

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

Интерфейс прикладного программирования ODBC API предоставляет общие методы доступа SQL как к реляционным, так и к нереляционным (ISAM) источникам данных.

В ANSI SQL входит интерфейс на уровне вызовов (CLI - call-level interface), который используется ODBC для обеспечения доступа и работы с данными во многих системах управления базами данных. Интерфейс CLI соответствует требованиям, установленным в 1991 году группой SQL Access Group, которые определяют общий синтаксис SQL и интерфейса API. Иметь общий метод доступа к источникам данных удобно потому, что тогда база данных на сервере становится прозрачной для приложений, которые написаны в соответствии с некоторым заданным уровнем совместимости ODBC.

Интерфейс ODBC API реализован как набор расслоенных DLL-функций для Windows. Динамическая библиотека ODBC.DLL - это основная библиотека управления драйверами ODBC, которая вызывает специализированные драйверы для разных поддерживаемых системой баз данных. Каждый драйвер совместим со своим уровнем CLI и относится к одной из двух категорий: одноуровневые или многоуровневые драйверы.

Одноуровневые драйверы предназначены для использования при работе с теми источниками данных, которые не могут быть обработаны ANSI SQL. Обычно это локальные базы данных на персональных компьютерах, такие как dBase, Paradox, FoxPro и др. Драйверы, соответствующие этим базам данных, переводят грамматику ANSI SQL в инструкции низкого уровня, которые непосредственно обрабатывают составляющие базу данных файлы.

Многоуровневые драйверы используют сервер СУРБД для обработки SQL-предложений и предназначены для работы в среде клиент-сервер. Помимо обработки ANSI SQL, они также могут поддерживать и собственную грамматику конкретной СУРБД, поскольку ODBC может без трансляции передавать SQL-предложения источникам данных (механизм "passthrough").

Драйверы ODBC для баз данных типа клиент-сервер реализованы для Oracle, Informix, Microsoft и Sybase SQL Server, Rdb, DB2, Ingres, HP/Image и Any SQL.

Существует 4 важных этапа (шага) процедуры запроса данных через API.

Шаг 1 - установление соединения. Первый шаг состоит в размещении указателей (handle) среды ODBC, которые выделяют оперативную память под ODBC драйверы и библиотеки. Затем происходит выделение памяти для указателей соединения, и соединение устанавливается.

Шаг 2 - выполнение предложения SQL. Выделяется указатель предложения, локальные переменные связываются со столбцами в SQL-выражении (это необязате~ьное действие), и выражение представляется на разбор главному ODBC драйверу для обработки.

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

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

Технология ODBC разрабатывалась как общий, независимый от источников данных, способ доступа к данным. Также ее применение должно было обеспечить переносимость приложений на различные базы данных без переработки самих приложений. В этом смысле технология ODBC уже стала промышленным стандартом, ее поддерживают практически все производители СУБД и средств разработки.

Однако универсальность стоит дорого. Если при разработке приложений одним из основных критериев является переносимость на различные СУБД, то использование ODBC является оправданным. Для увеличения производительности и эффективности приложения активно применяют специфические для данной СУБД расширения языка SQL, используют хранимые на сервере процедуры и функции. В этом случае теряется роль ODBC как общего метода доступа к данным. Тем более, что для разных СУБД драйверы ODBC поддерживают разные уровни совместимости. Поэтому многие производители средств разработки помимо поддержки ODBC поставляют "прямые" драйверы к основным СУБД.

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

Аннотация: Определение предметной области. Анализ предметной области: анализ осуществимости, бизнес-моделирование. Формирование и документирование требований к проекту.

4.1. Определение предметной области

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

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

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

4.2. Анализ предметной области (анализ осуществимости, бизнес - моделирование)

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

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

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

Функциональная область действия определяет услуги, предоставляемые системой, и вначале до конца неизвестны. В определении услуг системы может помочь список "Действующее лицо/Цель", в котором перечислены все цели пользователя, поддерживаемые системой. При его разработке в первую графу вписываются имена основных действующих лиц, т.е. тех, кто имеет цели, во вторую графу - цель каждого действующего лица, а в третью - приоритет или предположение о том, в какую версию войдет эта услуга. Формы списков приведены на рисунке.

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

Анализ предметной области является основой для анализа осуществимости проекта и определения образа (концепции) продукта и границ проекта.

Анализ осуществимости

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

Отвечает ли система бизнес-целям организации-заказчика и организации-разработчика?
Можно ли реализовать систему, используя известные технологии и не выходя за пределы заданной стоимости и заданного времени?
Можно ли объединить систему с другими уже эксплуатируемыми системами?

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

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

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

Постановку бизнес-задачи надо обсуждать с Заказчиком, или будущим Владельцем системы.

Вопросы, которые ему стоит задать, это:

Почему вообще пошла речь о создании системы?
В чём Вы видите её назначение?
Какие бизнес-возможности она должна реализовать?
Какие проблемы должна решить?

В качестве "Стандарта" на вопросы такого рода смотрите шаблон документа " Stakeholder Request", например, из RUP . Бизнес-требования может выразить Заказчик или Эксперты предметной области . Они обычно фиксируются в виде списка из 10-30 ключевых свойств продукта - в качестве шаблона см. Vision из RUP .

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

Каковы основные понятия предметной области, их определения и взаимосвязи? Результат можно оформить в виде глоссария и/или концептуально-семантической модели предметной области.
На основании каких правил - международных, федеральных, муниципальных, районных и т.д. законов, указов, стандартов, спецификаций, регламентов и т.д. - происходит то, что происходит в предметной области? Результат оформляете в виде структурированного списка или прикрепляете к элементам концептуальной модели.
Что реально (какие процессы, события, факты) происходит и в какой последовательности, взаимосвязи? Результат оформляете в виде сценариев описания бизнес-процессов (что достаточно универсально) или диаграмм SADT ( IDEF0 , IDEF3, DFD ) / ARIS (eEPC и т.д.) / UML (Business Use-case Diagram (BUC) + Activity Diagram + Sequence Diagram ). Это один из сложнейших этапов.
Какими свойствами обладает каждое из выделенных понятий - структурными и поведенческими? Результат описывается в виде таблиц с атрибутами Концептуальных сущностей или Детальной концептуальной моделью - ER - IDEF1X / UML Class Diagram ( BOM ).

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

На какую систему будет похожа создаваемая?
С какими системами и как давно вы работаете?
Какое у вас образование?
Каковы ваши ожидания от системы - что и как она должна делать, какие задачи помогать решать, как должна выглядеть?
Какие шаги необходимо предпринять для решения каждой задачи?
В каком случае вы будете считать, что система "Хороша"?

Результаты анкетирования/интервьюирования обычно представляют в виде пользовательских историй ( User Story , Agile) или Пользовательских сценариев (Use-case), также возможно их диаграммное представление средствами диаграмм потока работ (IDEF3), ARIS , Activity/State UML Diagram . Подробнее про работу с Пользователями могут рассказать специалисты по Проектированию взаимодействия, интерфейсам и эргономике.

Системные требования нужно выяснять у IT-специалистов Заказчика, если таковые имеются, из специфики контекста использования системы, опыта построения аналогичных систем (у IT-Экспертов-Архитекторов) и Специалистов по отдельным аспектам системы, значимым для данного проекта (Юристы, Эргономисты, и т.д.) и Заказчика:

Будет ли система единичной или тиражируемой?
В каких странах она будет работать?
Насколько важна информация, хранящаяся, обрабатываемая и передающаяся системой?
Каков возможный ущерб от потери той или иной информации?
Сколько пользователей будет работать с системой сегодня, завтра, через год?

Переработанный результат оформляется в виде Системных требований ( Software Requirement Specification , стандарт IEEE-STD-830-1998, или ТЗ ГОСТ 34-602-89 или неформально в виде Supplementary Specificaion из RUP ).

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

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

Оптимальный подбор предоставляемых средств определяет все остальное

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

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

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

4.3. Формирование и документирование требований к проекту

Для всех проектов разработки программного обеспечения, кроме самых тривиальных, важно иметь единственный "руководящий документ", в котором определяются:

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

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

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

Описываются среда функционирования, объект и субъект управления, цели и задачи управления.

Информационная система позволяет печатать данные о путешествии на типографском бланке – нет необходимости заполнять бланк от руки, намного облегчается ведение и анализ клиентской базы, упрощается работа и расчеты с клиентами. Данные клиента и информация о путешествии вносятся в базу и используются для оформления всех необходимых документов: путевок, заявок, договоров, памяток и т.д. При этом значительно уменьшается вероятность ошибок при заполнении документов (например, ошибок в ФИО туристов или их паспортных данных). Информационная система позволяет легко собирать и анализировать статистические данные о количестве и характере путешествий туристов, качестве работы менеджеров агентства, популярности туристических маршрутов, отелей и т.д.

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

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

Выбор и описание автоматизируемых функций

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

Перечень автоматизируемых функций

Для автоматизации были выбраны следующие типовые бизнес-процессы:

1) Учет клиентов;

2) Учет туроператоров;

3) Оформление заказа.

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

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

Данная функция предназначена для учета контрагентов туристического агентства.

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

Данная функция вести единую базу заказов клиентов в рамках одного туристического агентства.

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

Ожидается значительное сокращение времени и трудоемкости оформления заказов, а также печати всех необходимых документов (Договор, тур-1 и т.д.) с уже заполненными данными клиентов.

Рис. 1. Схема базы данных

Практическая работа №1

Системный анализ предметной области

Цель работы: получить представление о системном анализе предметной области.

Теоретическая часть

Процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели.

В общем случае можно выделить следующие этапы проектирования:

Системный анализ и словесное описание информационных объектов предметной области.
Проектирование инфологической модели предметной области — частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели.
Даталогичеcкое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных.
Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

Если учитывать, что между вторым и третьим этапами необходимо принять решение, с использованием какой стандартной СУБД будет реализовываться наш проект, то условно процесс проектирования БД можно представить последовательностью выполнения пяти соответствующих этапов. Рассмотрим более подробно этапы проектирования БД.

Рисунок 1 – Этапы проектирования БД

Системный анализ предметной области

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

В общем случае существуют два подхода к выбору состава и структуры предметной области:

Функциональный подход — он реализует принцип движения "от задач" и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.
Предметный подход — когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач. Конструирование предметной БД в некотором смысле кажется гораздо более заманчивым, однако трудность всеобщего охвата предметной области с невозможностью конкретизации потребностей пользователей может привести к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной.

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

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

Пример описания предметной области

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

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

Книги могут иметь одинаковые названия, но они различаются по своему уникальному шифру (ISBN).

В библиотеке ведется картотека читателей.

На каждого читателя в картотеку заносятся следующие сведения:

фамилия, имя, отчество;
домашний адрес;
телефон (будем считать, что у нас два телефона — рабочий и домашний);
дата рождения.

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

Каждый читатель может одновременно держать на руках не более 5 книг. Читатель не должен одновременно держать более одного экземпляра книги одного названия.

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

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

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

номер билета читателя, который взял книгу;
дата выдачи книги;
дата возврата.

Предусмотреть следующие ограничения на информацию в системе:

С данной информационной системой должны работать следующие группы пользователей:

При работе с системой библиотекарь должен иметь возможность решать следующие задачи:

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

Читатель должен иметь возможность решать следующие задачи:

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

Этот совсем небольшой пример показывает, что перед началом разработки необходимо иметь точное представление о том, что же должно выполняться в системе, какие пользователи в ней будут работать, какие задачи будет решать каждый пользователь. И это правильно, ведь когда строят здание, тоже заранее предполагается: для каких целей оно предназначено, в каком климате оно будет стоять, на какой почве, и в зависимости от этого проектировщики могут предложить нам тот или иной проект. Но, к сожалению, очень часто по отношению к базам данных считается, что все можно определить потом, когда проект системы уже создан. Отсутствие четких целей создания БД может свести на нет все усилия разработчиков, и проект БД получится "плохим", неудобным, не соответствующим ни реально моделируемому объекту, ни задачам, которые должны решаться с использованием данной БД.

Варианты индивидуальных заданий для выполнения семантического анализа предметно области:

ВВЕДЕНИЕ

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

Весьма актуальным является проблема переноса бухгалтерских программ, рассчитанных на малые и средние предприятия и фирмы, на новую технологию. Это обусловлено тем, что область данных программ осталась почти не тронутая новой технологией.

Система управления базами данных SQL Server 2008 предоставляет пользователям широкие возможности по разработке и сопровождению баз данных. Для этого в составе системы имеется набор графических средств (Enterprise Manager, Query Analyzer), языковых средств (язык Transact-SQL), набор хранимых процедур.

Основными задачами в процессе разработки и сопровождения баз данных в среде SQL Server 2008 являются создание, модификация и удаление баз данных, таблиц, а также объектов баз данных, таких как индексы, представления, запросы, хранимые процедуры. В пособии рассматриваются физическая и логическая организация баз данных в SQL Server 2008, структурный язык запросов Transact-SQL, шаблоны команд и примеры запросов.

Словесное описание предметной области

Описываются среда функционирования, объект и субъект управления, цели и задачи управления.

Выбор и описание автоматизируемых функций

Перечень автоматизируемых функций

Для автоматизации были выбраны следующие типовые бизнес-процессы:

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

Данная функция предназначена для учета контрагентов туристического агентства.

Данная функция вести единую базу заказов клиентов в рамках одного туристического агентства.

Читайте также: