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

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

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

 

 

1.3 Варианты использования системы

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

- смотреть общее расписание

- смотреть график мастеров

- получить личное расписание

- ввести новую запись

- выбрать дату

- выбрать сотрудника

- ввести информацию с клавиатуры

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

 

Рис 1.1 Диаграмма вариантов использования  системы

 

1.4 Сбор требований

 

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

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

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

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

Работа программы осуществляется в операционной системе Windows 2000/NT/XP/Vista.

Различают четыре основных этапа процесса разработки требований (рисунок 1.2):

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

Рис. 1.2 Этапы процесса разработки требований

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

1.5 Аттестация требований

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

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

1. Проверка правильности требований.
2. Проверка на непротиворечивость.
3. Проверка на полноту.
4. Проверка на выполнимость.

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

1. Обзор требований.
2. Прототипирование.
3. Генерация тестовых сценариев.
4. Автоматизированный анализ непротиворечивости.

Наиболее наглядным для заказчика  системы является прототипирование.

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

Следующим шагом аттестации требований является непосредственное создание прототипов.

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

Прототип основной формы данного модуля представлен на рисунке 1.3.

Рис. 1.3 Прототип основной формы главного модуля

 

1.6 Выбор методологии проектирования программного обеспечения информационной системы.

 

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

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

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

 

 

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1 Архитектурное проектирование

 

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

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

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

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

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

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

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

Основными программными архитектурами, реализуемыми в настоящее время  являются:

• файл-серверная;
• клиент-серверная;
• многоуровневая.

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

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

Исходя из этих рассуждений при  проектировании архитектуры АИС за основу была принята технология клиент-сервер.

 

2.2 Проектирование интерфейса  информационной системы

 

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

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

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

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