Разработка АИС «управление наружной рекламой

Рис. 10. Средний показатель ежемесячного количества заказов за истекший год

     На  данном графике точками перелома линии являются средние значения общего количества заказов за месяц. Если взять среднее значение двенадцати точек (одна точка для каждого месяца), то можно обозначить темпы роста производства, а также финансовый рост фирмы, зависящий от объемов производства. На данном графике темп роста составляет 141%.

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

     Данное  программное средство должно обладать следующими возможностями:

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

     2.4 Архитектура АРМ «Клиент – менеджер. Наружная реклама»

     Прежде  чем приступать к разработке АРМ  «Клиент-менеджер. Наружная реклама», необходимо определить основные требования, которым она должна удовлетворять.

     Итак, программа должна:

• обладать функциями для работы с базами данных;
• иметь интерфейс в стиле операционной системы Microsoft Windows 9x, привычный пользователям.

     Удобным способом разработки программы является разбиение ее  на взаимодействующие  друг с другом самостоятельные модули. Это поможет ускорить процесс создания и отладки программы, так как программисту в этом  случае не придётся концентрировать внимание на всём коде, пытаясь охватить содержание создаваемой программы целиком, потому, что он будет работать с ее отдельными, относительно небольшими частями[8].

     2.4.1. Информационно-логическая модель и структура базы данных

     При  создании будущего программного средства необходимо определить состав данных, которыми будет оперировать программный продукт. Эта работа была проведена в первой главе. Так для того, чтобы спроектировать АРМ «Клиент-менеджер. Наружная реклама» понадобятся следующие сведения:

1. информация о заказчике:
1. ФИО заказчика;
2. адрес заказчика;
3. телефон заказчика;
4. паспортные данные (в том случае, если заказчик – частное лицо),
5. номер и серия лицензии или сертификата (в случае, когда заказчик зарегистрирован, как предприниматель без образования юридического лица или зарегистрирован, как юридическое лицо).
2. вид оплаты заказа;
3. используемые материалы;
4. информация об изделии:
1. наименование изделия;
2. размеры изделия;
5. цвета, используемые при изготовлении изделия;
6. материалы, используемые при изготовлении изделия;
7. сумма заказа;
8. информация о заказе:

1. дата заказа;
2. срок изготовления заказа;
3. дата утверждения оригинал-макета.

     Исходя  из информационной модели, строится архитектура программного средства. Архитектуру можно изобразить в виде диаграммы (рис. 12). Внутреннее устройство программного средства показывает следующаяя диаграмма (рис. 13). Как видно из данной диаграммы программное средство разбито на 8 подсистем:

1. подсистема хранения данных;
2. подсистема запроса данных и доступа к ним;
3. подсистема обновления полученных данных;
4. подсистема выбора данных о клиентах;
5. подсистема изменения данных;
6. подсистема вывода информации на дисплей;
7. подсистема печати;
8. подсистема контроля действий пользователя;

     Для обеспечения возможности свободного добавления новых и удаления ненужных предметов необходимо позаботиться о независимости предметов друг от друга. Этого можно достичь, если хранить вопросы к тестам и данные о лабораторных работах по различным предметам отдельно от остальных сведений. То есть, на каждый предмет должна быть заведена своя база данных, содержащая таблицы с тестами и списком лабораторно-практических заданий. Такой подход к хранению материала позволит, при необходимости, просто подключать к системе требуемые базы. При этом будет возможно заполнение этих баз данных как с помощью средств, предоставляемых разрабатываемой системой, так и стандартными средствами, предоставляемыми существующими СУБД[9].

     На  рисунке 11 с помощью ER-диаграммы [10] графически изображена схема базы данных АРМ «Клиент-менеджер. Наружная реклама», на которой отчетливо показаны связи между таблицами.

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

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

     Процесс уменьшения избыточности информации в базе данных называется нормализацией. В теории нормализации баз данных разработаны достаточно формализованные подходы по разбиению данных, обладающих сложной структурой, среди нескольких таблиц. Эти вопросы детально освещаются в специальной литературе [13-17].

     Таблицы базы данных АРМ «Клиент-менеджер. Наружная реклама» приведены к третьей  нормальной форме [18]. Это подтверждается выполнением следующих требований:

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

Рис. 11. ER-диаграмма базы данных АРМ «Клиент-менеджер. Наружная реклама»

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

     Перед построением контекстной  DFD-диаграммы были проанализированы внешние события (внешние объекты), оказывающие влияние на функционирование системы. Эти объекты взаимодействуют с ИС путем информационного обмена с ней[19].

     Типы  данных, используемые при организации  таблиц базы данных, подробно рассмотрены  в следующем разделе.

     Начальная контекстная диаграмма изображена на рис. 12.

     2.4.2. Потоки данных

     Наиболее  распространенным средством моделирования  данных являются диаграммы (DFD). С их помощью определяются важные для предметной области объекты и отношения друг с другом (связи)[20].

     Модель  системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно[21].

Рис 12. Контекстная диаграмма потоков данных – «Клиент-менеджер» 1 уровень.

Рис 13. Контекстная диаграмма потоков данных – «Клиент-менеджер» 2 уровень.

     2.5. Выбор среды программирования

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

     При программной реализации необходимо учитывать множество факторов, влияющих на жизнеспособность создаваемого приложения. В рамках выбранной объектно-ориентированной методологии проектирования и реализации ПО естественным является выбор объектно-ориентированного языка программирования. К ним можно отнести C++, Java, SmallTalk, Object Pascal. Но не только язык программирования определяет выбор. В настоящее время решающим при выборе средства разработки является то, насколько эффективно данный инструмент позволяет создавать приложения, смогут ли созданные выбранным средством разработки приложения соответствовать критериям, предъявляемым пользователем и аппаратным обеспечением[22].

     Объектно-ориентированное  программирование и порожденное  им объектно-ориентированное проектирование - это новый подход к построению сложных (и не очень сложных) программ и систем. В отличие от процедурного программирования, господствующего до появления ООП, в объектно-ориентированном программировании главной, отправной точкой является  не процедура, не действие, а  объект. Такой подход является достаточно естественным. Поскольку в реальном мире мы имеем дело именно с объектами (людьми, предметами, техническими устройствами), взаимодействующими друг с другом [23].

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

     К основным критериям, предъявляемым к современным приложениям, относятся:

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

     Современным стандартом, удовлетворяющим перечисленным  требованиям, является RAD (Rapid Application Development).

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

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

     Для написания программного средства «Редактор  диаграмм» была выбрана среда  программирования C++ Builder 6.0.

     C++Builder разработанный корпорацией Borland, является, на сегодняшний день, наиболее совершенной средой разработки и мощной системой визуального объектно-ориентированного программирования (ООП), поддерживающий технологию RAD (Rapid Application Development - быстрая разработка приложений), основанной на языке С++.

     C++ Builder 6.0 предоставляет все необходимые средства для создания и управления эффективными, 32-разрядными приложениями и компонентами. Его средства и объектно-ориентированный язык делают данный пакет идеальным для разработки современных, масштабируемых, многоуровневых приложений, которые объединяют архитектуру «клиент-сервер» и Internet.