Симулятор файлового менеджера

Введение

 

 

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

Целью разработки проекта «Программный симулятор формирования каталога файлов» является создание программного приложения.

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

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

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

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

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

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

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

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

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

Приложение будет содержать текст программы.

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

 

1 Постановка задачи

 

1.1 Организационная сущность задачи

 

 

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

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

В файловой системе каталог файлов требуется организовать как бинарное дерево. Для каждого файла в каталоге будут содержаться следующие сведения:

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

Общие задачи, которые требуется  разработать в программном средстве:

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

Разработать интерфейс пользователя и справочную систему приложения.

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

 Total Commander (ранее WinCmd) — файловый менеджер для Windows, наподобие Проводника Windows. Однако Total Commander использует иной подход: у него две постоянных панели бок о бок, как в хорошо известной DOS-оболочке (NC).

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

 

 

1.2 Информационная модель

 

 

Чтобы было легче представить, что  должен выполнять в будущем программный  продукт, следует создать его  модель. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных. Нотация ERD была впервые введена П. Ченном (Chen) и получила дальнейшее развитие в работах Баркера.

Первый шаг моделирования  – извлечение информации и выделение сущностей.

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

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

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

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

Связь (Relationship) – поименованная  ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.

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

Последним шагом моделирования  является идентификация атрибутов.

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

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

У сущности «Файл» можно выделить следующие атрибуты:

• имя;
• дата создания;
• количество обращений.

У сущности «Каталог» можно выделить следующие атрибуты:

• имя;
• дата создания;
• количество обращений.

Схема Баркера-Ченна представлена на рисунке 1.

 

 

 

 

 

 

 

 

 

Рисунок 1 – Схема Баркера-Ченна

 

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

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

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

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

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

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

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

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

– создания элемента;

– удаление элемента;

– удаление по определенным критериям;

– предоставление справочной информации;

– возможность поиска файлов.

Диаграмма вариантов использования  представлена в графической части на листе 1.

Математическую модель, проектируемая система не имеет.

 

 

1.3 Входные данные

 

 

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

 

 

1.4 Выходные данные

 

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

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

 

 

2 Вычислительная система

 

2.1 Используемые технические  средства

 

 

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

- процессор Phenom x4 2,3 Гц;

- оперативная память DDR II 800 2048 Mb;

- жёсткий диск HDD Hitachi 1024 Gb 16mb cache;

- видеокарта ATI Sapphire Radeon HD 4850 512mb\256bit;

- материнская плата Gigabyte-P45;

- клавиатура Logitech;

- мышь.

 

 

2.2 Инструменты разработки

 

 

Инструментами разработки будут являться:

• операционная система Windows Vista Ultimate;
• среда Visual Studio 2008;
• язык программирования С#;
• CASE-среда Rational Rose 2000.

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