Файл: Разработка сайта праздничного агентства ПРАЗДНИК.pdf

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

2 Проектирование задачи

2.1 Алгоритм решения задачи

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

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

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

Цель создания сайта:

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

Целевая аудитория:

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

Необходимые ресурсы:

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

Определение сроков:

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

2.2 Логическое моделирование

К моделям логического уровня относятся:

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

Логическая модель данных – это схема, которая показывает причинно-следственные связи между:

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

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

Логическая модель разработанного веб-сайта приведена на рисунке 2.1.

Рисунок 2.1 – Логическая модель разрабатываемого сайта

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

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

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

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

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

Рисунок 2.2 – Диаграмма деятельности

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

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

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

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

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

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

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

Рисунок 2.3 – Диаграмма вариантов использования

2.3 Выбор и обоснование инструментов разработки

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

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

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

Достойный уважения Web-дизайн включает разработку страниц, доступных для пользователей с ограниченными возможностями, в частности по зрению и слуху. Консорциум World Wide Web объявил об инициативе Web Accessibility Initiative (WAI), которая ставит целью сделать Web более доступным для всех пользователей. Однако успех данной инициативы зависит от участия в ней рядовых разработчиков, которые могут (или не могут) создать Web-сайты в соответствии с поставленными задачами.

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

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

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

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

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

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

Исходя из этого, следует, что из трех машин класса Pentium, необходимо выбрать одну: