Добавлен: 25.10.2023
Просмотров: 135
Скачиваний: 4
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
Занятие 1. Создать Диаграмму вариантов использования, поясняющую основной прецедент “Заказ товаров”.
Занятие 2. Построение диаграммы прецедентов в StarUML.
Занятие 4. Построение диаграммы классов. Построение диаграммы с атрибутами и операциями.
Занятие 5. Построение диаграммы классов с отношениями. Построение диаграммы пакетов.
Занятие 6. Создать диаграмму деятельности.
Занятие 7. Работа с диаграммой последовательности операции.
Занятие 8. Построение диаграммы кооперации.
Занятие 9. Построение диаграммы состояний.
Занятие 10. Анализ диаграмм UML.
Занятие 11. Построение диаграммы SADT.
Занятие 12. Построение диаграмм DFD.
Занятие 13. Построение структурной схемы.
Занятие 14. Построение блок-схем.
Занятия 15-19. Проектирование базы данных.
Занятия 20-23. Реализация физической модели базы данных ИС.
Занятия 24-29. Разработка серверного приложения ИС.
Занятия 30-35. Разработка клиентского приложения ИС.
Занятие 36. Концепция маршрутизации. Коммутируемые сети. Конфигурация коммутатора.
4. Проектирование базы данных:
- концептуальное проектирование базы данных – создание концептуальной модели данных, то есть информационной модели. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Чаще всего концептуальная модель базы данных включает в себя: описание информационных объектов, или понятий предметной области и связей между ними; описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними;
- логическое проектирование базы данных – создание логической модели данных; создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных логическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
- физическое проектирование базы данных – создание схемы базы данных для конкретной СУБД, создание описания СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным, разработка средств защиты данных), создание индексов и т.д.;
5. Разработка приложений:
- проектирование транзакций (группа инструкций SQL (набор команд), исполняемых как единое целое);
- проектирование пользовательского интерфейса;
6. Реализация;
7. Загрузка данных;
8. Тестирование;
9. Эксплуатация и сопровождение:
- анализ функционирования и поддержка исходного варианта БД;
- адаптация, модернизация и поддержка переработанных вариантов.
Проектирование баз данных – процесс создания схемы базы данных и определения необходимых ограничений целостности (соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам).
Основные задачи проектирования баз данных:
- Обеспечение хранения в БД всей необходимой информации.
- Обеспечение возможности получения данных по всем необходимым запросам.
- Сокращение избыточности и дублирования данных.
- Обеспечение целостности базы данных.
Занятия 20-23. Реализация физической модели базы данных ИС.
Физическая модель данных описывает данные средствами конкретной СУБД. Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД, например, при помощи индексов, декларативных ограничений целостности, триггеров, хранимых процедур. При этом опять-таки решения, принятые на уровне логического моделирования определяют некоторые границы, в пределах которых можно развивать физическую модель данных. Точно также, в пределах этих границ можно принимать различные решения. Например, отношения, содержащиеся в логической модели данных, должны быть преобразованы в таблицы, но для каждой таблицы можно дополнительно объявить различные индексы, повышающие скорость обращения к данным. Многое тут зависит от конкретной СУБД.
Если физическая модель данных реализована средствами реляционной СУБД, то отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.
Собственно база данных и информационная система. И, наконец, как результат предыдущих этапов появляется собственно сама база данных. База данных реализована на конкретной программно-аппаратной основе, и выбор этой основы позволяет существенно повысить скорость работы с базой данных. Например, можно выбирать различные типы компьютеров, менять количество процессоров, объем оперативной памяти, дисковые подсистемы и т.п. Очень большое значение имеет также настройка СУБД в пределах выбранной программно-аппаратной платформы.
Но опять решения, принятые на предыдущем уровне - уровне физического проектирования, определяют границы, в пределах которых можно принимать решения по выбору программно-аппаратной платформы и настройки СУБД. Таким образом, ясно, что решения, принятые на каждом этапе моделирования и разработки базы данных, будут сказываться на дальнейших этапах. Поэтому особую роль играет принятие правильных решений на ранних этапах моделирования.
Рис.16 Пример физической модели БД
Занятия 24-29. Разработка серверного приложения ИС.
Сервер – это специализированный компьютер или же специальное оборудование, которое используется для выполнения каких-либо узкоспециализированных функций, требующих больших вычислительных мощностей. Выполнение узкоспециализированных функций сервера обусловлено использованием специального серверного программного обеспечения.
Иногда вместо термина сервер вы можете услышать словосочетание выделенный компьютер, опять же, это потому, что функции сервера в компьютерной сети отличаются от функций других машин. В лучшем случае человек работает с серверной машиной только один раз – когда настраивает сервер, далее работа серверного компьютера (опять же, в идеальном случае) происходит автономно без вмешательства человека.
У нас сейчас не стоит цель детально погружаться в масштабируемость и сборку серверных компьютеров, и уж тем более сейчас не стоит цель давать рекомендации по сборке серверных машин различного назначения, так как это довольно специфичная и довольно узкая тематика. Сейчас нам нужно понимать, что сервер – это специально выделенный компьютер для каких-то определённых функций (хотя это не всегда так), зачастую при недостатке бюджета сервер может выполнять сразу несколько функций.
Также стоит заметить, что обычно управление сервером осуществляют не рядовые пользователи, а специально обученные и подготовленные системные администраторы, в задачу которых входит обслуживание серверных компьютеров.
Серверное приложение – это специализированная программа, которая принимает запросы клиентов, обрабатывает их и дает ответы на эти вопросы. Для того чтобы лучше понять, что такое серверное приложение, вам нужно понимать, что модель взаимодействия клиент-сервер предназначена для того, чтобы разделить нагрузку и функционал между клиентскими приложениями и серверными, поэтому приложение клиент и серверное приложение могут работать на одном компьютере и при этом взаимодействовать друг с другом.
В качестве примеров серверных приложений можно привести:
-
любой HTTP сервер, например, сервер Apache или lighttpd; -
сервер баз данных MySQL; -
готовые сборки для веб-разработчика, такие как Denwer или локальный сервер AMPPS.
Серверное приложение выполняет определённый набор функций, который ограничен его назначением. Например, веб-сервер должен принимать HTTP запросы от клиента, анализировать их, проверяя полученные HTTP методы и поля заголовков, затем выполнять действия, указанные в запросе и отчитываться клиенту о результатах своей работы при помощи специального HTTP сообщения, которое получило название ответ.
А, например, серверное приложение MySQL должно анализировать SQL запрос, полученный от клиента, обработать его, организовать доступ к файловой системе и вернуть результат запроса клиенту.
Но, помимо того, что у серверного приложения есть определённая роль или функция, нам стоит отметить то, что взаимодействие между клиентской программой и серверным приложением происходит по сетевому протоколу (даже если оба приложения установлены на один компьютер, например, по протоколу HTTP). Сейчас мы не будем давать полную классификацию серверных приложений и не будем вдаваться в специфику тех или иных приложений. Нам важно понимать, что серверные приложения выполняют строго определённую роль и в архитектуре клиент-сервер являются поставщиками услуг для клиентов.
На самом примитивном уровне абстракции приложение, ориентированное на работу с сервером состоит из следующих архитектурных слоев:
-
Ядро приложения, которое включает в себя компоненты системы, не доступные для взаимодействия с пользователем. -
Графический пользователь интерфейс -
Компоненты повторного использования: библиотеки, визуальные компоненты и другое. -
Файлы окружения: AppDelegate, .plist и т. д. -
Ресурсы приложения: графические файлы, звуки, необходимые бинарные файлы.