Корзина (0)---------

Корзина

Ваша корзина пуста

Корзина (0)---------

Корзина

Ваша корзина пуста

Структурная схема пакета (описание программных модулей)

 Структурная схема пакета (описание программных модулей)
Описание
Отзывы (699)

Описание

Не нашли подходящую работу?Оцените стоимость ее написания!

Бесплатная консультация по вашей теме: Telegram: @Diplomit Телефон/WhatsApp/MAX: +7 (987) 915-99-32, Email: admin@diplom-it.ru

Современные информационные системы слишком велики по объему, поэтому для лучшей управляемости систем в них применяются группировки высших порядков. Классы, созданные на этапе проектирования, группируются в подсистемы. Каждая подсистема имеет набор интерфейсов, которые обеспечивают ее существование и использование. Подсистемы нижнего уровня называются сервисными, они представляют собой минимальную самодостаточную единицу.
На базе проектной модели создается модель реализации. Классы модели проектирования переходят в программные модули модели реализации, а подсистемы модели проектирования трассируются в пакеты модели реализации. При этом один пакет содержит одну подсистему, и лишь в исключительных случаях объединяет несколько. Как правило, в рамках диплома по прикладной информатике выпускник проектирует и реализует не всю информационную систему (эта задача слишком объемна), а некоторую ее подсистему. Поэтому в пояснительной записке требуется представить структурную схему пакета для той подсистемы, которая была спроектирована дипломником.
Наиболее грамотно представлять структурную схему пакета в виде модели реализации. Модель реализации состоит из компонентов, в число которых входят: исполняемые модули (программы, которые можно запустить), файлы (содержат исходные тексты программ или данные), библиотеки (статические или динамически компонуемые), таблицы (элементы реляционной БД) и документы (хранящиеся в электронном виде). Компонент – это физически заменяемая часть системы, которая использует некоторые интерфейсы и обеспечивает реализацию некоторой функциональности. Компоненты должны быть взаимозаменяемыми. Разработчик может заменить один компонент на другой, более совершенный, если новый компонент использует и предоставляет те же интерфейсы, что и старый.
Подсистемы должны быть плотными, их содержимое должно быть сильно связано. Между собой подсистемы должны быть связаны слабо, что обеспечивает их минимальную зависимость друг от друга. Таким образом обеспечивается высокая степень автономности подсистемы. Все сказанное справедливо и для пакета. Если дипломник пришел к выводу, что для решения поставленной перед ним задачи требуется спроектировать две подсистемы или более, а потом объединить их в единый пакет, то такая необходимость должна быть аргументирована в пояснительной записке.
При защите дипломной работы наибольший интерес представляют те компоненты модели реализации, которые являются программными модулями, поскольку именно эти компоненты были написаны непосредственно дипломником (другие компоненты могли быть сгенерированы автоматически или интегрированы в систему). Именно этим компонентам следует уделить наибольшее внимание при описании структурной схемы пакета.
Принято выделять 3 вида исполняемых модулей:
• Модули, предназначенные непосредственно для ввода, обработки, хранения и выдачи информации;
• Модули, выполняющие вспомогательные функции;
• Управляющие модули, обеспечивающие интерфейс с пользователем и обеспечивающие вызов других модулей.
Каждый из программных модулей следует описать, указав его идентификатор и функциональное назначение. Описание наиболее значимых программных модулей может быть выполнено в отдельном разделе пояснительной записки, при необходимости для них составляются блок-схемы.
После того, как с помощью модели реализации описана структурная схема пакета, следует построить дерево вызова процедур и программ. Это дерево может быть представлено либо в графической форме с использованием, например, условных обозначений языка UML, либо в виде таблицы. Оно должно давать представление о порядке взаимодействия отдельных компонентов и о том, какая информация передается из одного компонента в другой.
Для иллюстрации работы системы следует привести несколько тестовых примеров. Тестовые наборы необходимо сгенерировать для нормальных, граничных и экстремальных условий функционирования системы. Граничными называются такие наборы входных параметров, которые встречаются редко или имеют особые алгоритмы обработки (например, в параметре даты задать 29 февраля). Экстремальными называются наборы входных параметров, являющиеся некорректными (например, дата 30 февраля). При формировании тестовых наборов необходимо не только задать множество входных параметров, но и указать ожидаемый результат, чтобы его можно было сравнить с результатом полученным системой. Порядок работы системы при выполнении тестовых заданий можно описать вербально, основываясь на построенном дереве процедур и функций.
Описание структурной схемы пакета завершает проектную часть пояснительной записки.

Вчера 13:22

Я в полном восторге! Заказала здесь диплом по психологии (тема была очень узкая, связанная с тревожностью у студентов) для МУ им. Витте. Сомневалась до последнего. Автор сработал блестяще! Не просто собрал теорию, а грамотно составил программу эмпирического исследования, предложил релевантные методики. Работа была глубокой и действительно научной. При защите комиссия отметила практическую значимость и качественный анализ данных. Рекомендую всем студентам-психологам, кто хочет сэкономить нервы и время!

8 октября 2025 07:39

Обратился в компанию для разработки выпускной квалификационной работы по бизнес-информатике. ВУЗ — МИРЭА, тема касалась анализа ИТ-инфраструктуры и предложений по ее оптимизации. Работу выполнили в оговоренные сроки. Текст был структурирован, содержал не только теоретическую часть, но и грамотно проработанный аналитический раздел с расчетами. Все требования вуза (включая оформление) были соблюдены. Внес пару правок по практической главе — исполнитель отреагировал оперативно. Работа защищена на хорошо. В целом, услуга соответствует заявленной стоимости. Рекомендую.

6 октября 2025 14:42

Работа была сложная, на стыке нескольких областей. Требовалось не просто описать технологию, а спроектировать архитектуру решения и разработать план его внедрения с расчетом экономической эффективности. Меня привлекло то, что со мной работал не один автор, а команда (куратор, технический специалист по блокчейну и экономист). Результат превзошел ожидания: был предоставлен детальный технический проект, написанный с использованием профессиональной нотации (UML), проведен SWOT-анализ внедрения и рассчитан срок окупаемости. Для защиты подготовили яркую презентацию и тезисы. Работа получила высокую оценку за комплексный подход.

6 октября 2025 04:19

Тема про аудит безопасности. Всё четко, по делу, без воды. Спасибо.

6 октября 2025 03:49

Сроки поджимали, до защиты оставалось меньше месяца. Обратился сюда как в последнюю инстанцию. Менеджер сразу предупредил о возможной доплате за срочность, но подключил самого опытного автора по 1С. Коммуникация была на высоте: автор выходил на связь в любое время суток, согласовывал каждый раздел. Работа была выполнена за 3 недели. Она включала не только теорию по ERP-системам, но и детальное описание конфигурации под конкретный бизнес-кейс, что было ключевым требованием в «Синергии». Несмотря на спешку, оформление было идеальным. Сдал без проблем, спасибо за ответственность.

Все отзывы
С этим товаром также покупают
0Избранное
товар в избранных
0Сравнение
товар в сравнении
0Просмотренные
0Корзина
товар в корзине
Мы используем файлы cookie, чтобы сайт был лучше для вас.