Каждый год миллионы людей по всему миру стремятся к более здоровому образу жизни, и значительная часть этого пути связана с контролем питания. Только в 2023 году рынок приложений для здоровья и фитнеса достиг отметки в 13,7 миллиарда долларов США, при этом сегмент трекеров питания и калорий демонстрирует устойчивый рост. Это свидетельствует о колоссальной актуальности разработки программного обеспечения, способного помочь пользователям эффективно отслеживать свой рацион, поскольку такие приложения выступают не просто как цифровые инструменты, а как функциональные помощники в достижении личных целей в области здоровья и благополучия.
Введение
Настоящая курсовая работа посвящена комплексному проектированию программного обеспечения «Журнал калорий». В условиях, когда удобство и эффективность взаимодействия с цифровыми продуктами становятся ключевыми факторами успеха, особую значимость приобретают вопросы проектирования пользовательского интерфейса (UI/UX) и строгой архитектурной проработки с использованием методологий объектно-ориентированного моделирования. Цель данной работы заключается в разработке детальной структуры и сборе фактической информации, необходимой для создания курсового проекта, который не только обозначит функциональные возможности «Журнала калорий», но и представит его внутреннюю логику и взаимодействие компонентов через призму Унифицированного языка моделирования (UML).
Основными задачами курсовой работы являются:
- Анализ и систематизация теоретических основ проектирования пользовательских интерфейсов.
- Изучение принципов объектно-ориентированного моделирования и нотаций UML.
- Разработка ключевых UML-диаграмм (вариантов использования, деятельности, классов, последовательности) для приложения «Журнал калорий».
- Проектирование оптимальной структуры базы данных для хранения информации о питании, продуктах и пользователях.
- Обзор современных инструментов для UML-моделирования и прототипирования UI/UX.
В последующих главах будет последовательно раскрыта каждая из этих тем, начиная с фундаментальных принципов проектирования пользовательских интерфейсов, переходя к глубокому погружению в мир UML-моделирования и его практического применения на примере «Журнала калорий», и завершая обзором инструментария, необходимого для реализации подобных проектов.
Теоретические основы проектирования пользовательского интерфейса (UI/UX)
Создание успешного программного продукта, такого как «Журнал калорий», немыслимо без глубокого понимания того, как человек взаимодействует с машиной. Именно пользовательский интерфейс (UI) и пользовательский опыт (UX) определяют, будет ли приложение востребовано и эффективно, ведь они формируют первое и самое стойкое впечатление от продукта.
Принципы человеко-машинного взаимодействия и пользовательско-ориентированного подхода
Исследование человеко-машинных интерфейсов представляет собой увлекательную междисциплинарную область, объединяющую в себе элементы эргономики, когнитивной психологии, психологии труда, информатики, теории автоматического управления, usability engineering, технической эстетики, управления процессами и промышленного дизайна. Этот синтез знаний позволяет формировать интерфейсы, которые не просто красивы, но и максимально эффективны для выполнения поставленных задач.
Ключевым драйвером современного проектирования программного обеспечения является пользовательско-ориентированный подход. Он возник из понимания, что независимо от сложности и функциональности внутренней архитектуры системы, её реальная применимость и ценность для конечного пользователя определяются именно интерфейсом. Если интерфейс неудобен, непонятен или вызывает фрустрацию, даже самое мощное программное обеспечение останется невостребованным. Для «Журнала калорий» это означает, что удобство ввода данных о еде, наглядность статистики и простота навигации будут критически важны для формирования привычки использования и лояльности пользователей, обеспечивая, таким образом, долгосрочную успешность продукта на рынке.
Основные принципы разработки пользовательского интерфейса
Принципы разработки пользовательского интерфейса — это не просто рекомендации, это высокоуровневые концепции, которые служат фундаментом для создания интуитивных и эффективных цифровых продуктов. Для «Журнала калорий» их применение позволит обеспечить комфортное и продуктивное взаимодействие с приложением.
Рассмотрим ключевые принципы и их практическое применение:
- Контроль пользователем интерфейса: Пользователь должен чувствовать себя хозяином ситуации, иметь возможность отменять действия, возвращаться назад, управлять настройками и потоком информации. В «Журнале калорий» это может проявляться в возможности легко редактировать записи о приемах пищи, настраивать цели по калориям, выбирать единицы измерения или временно скрывать определенные данные.
- Уменьшение загрузки памяти пользователя: Интерфейс не должен заставлять пользователя запоминать большое количество информации или последовательностей действий. Вспомните, сколько раз вы забывали, как именно выполнить сложную операцию в новом приложении. Для «Журнала калорий» это означает использование узнаваемых иконок, автозаполнение полей при вводе продуктов, сохранение истории поиска и немедленное отображение результатов, чтобы пользователь мог сосредоточиться на своих целях, а не на интерфейсе.
- Последовательность пользовательского интерфейса: Элементы интерфейса и их поведение должны быть предсказуемы. Если кнопка «Сохранить» находится в одном месте, она должна быть там же и в другом аналогичном контексте. В «Журнале калорий» это подразумевает единообразие навигационных элементов, стандартизированные макеты для добавления продуктов и просмотра статистики, а также привычные паттерны взаимодействия, чтобы пользователь не тратил время на переобучение.
- Естественность интерфейса: Интерфейс не должен вынуждать пользователя существенно изменять привычные способы решения задачи. Сообщения и терминология должны соответствовать принятым в предметной области. Для приложения по учету калорий это означает использование понятных для нутрициологии терминов, интуитивно понятные способы ввода данных (например, поиск по названию продукта), а также отсутствие необходимости вникать в специфическую «логику» приложения.
- Предотвращение ошибок: Гораздо проще предотвратить ошибку, чем исправлять её последствия. Для «Журнала калорий» это могут быть валидация ввода данных в реальном времени (например, проверка на числовое значение в поле калорий), предупреждения при попытке удалить важную запись или предложение наиболее вероятных вариантов выбора (например, из списка часто употребляемых продуктов).
- Обратная связь: Система должна постоянно информировать пользователя о том, что происходит: успешно ли сохранена запись, сколько калорий осталось до цели, загружаются ли данные. В «Журнале калорий» это могут быть всплывающие уведомления об успешном добавлении продукта, индикаторы загрузки, визуальное отображение прогресса к дневной цели.
- Гибкость и эффективность: Интерфейс должен подходить как новичкам, так и опытным пользователям. Для «Журнала калорий» это может означать наличие упрощенного режима ввода для быстрых записей и более детализированного – для продвинутых пользователей, желающих указать все микроэлементы.
- Эстетика и минимализм: Красивый и чистый дизайн не только приятен глазу, но и способствует лучшей концентрации. В «Журнале калорий» это выражается в отсутствии избыточных элементов, четкой типографике, гармоничной цветовой палитре, которая не отвлекает от основной задачи.
- Совместимость с задачей и пользователем: Интерфейс должен быть адаптирован под конкретные задачи и потребности целевой аудитории. Для «Журнала калорий» это означает, что дизайн должен учитывать, что пользователи могут вводить данные на ходу, использовать приложение на разных устройствах и иметь различные диетические предпочтения.
- Ясность и надежность: Все элементы интерфейса должны быть однозначно интерпретируемы, а система должна работать стабильно и предсказуемо.
Методологии проектирования UI/UX
Проектирование пользовательского интерфейса – это не одномоментный акт, а последовательный процесс, включающий несколько ключевых этапов. Он начинается с глубокого анализа целевой аудитории, поскольку понимание того, кто будет пользоваться приложением, является фундаментом для создания релевантного и эффективного интерфейса. На этом этапе проводится изучение задач пользователей, их потребностей, болевых точек и ожиданий. Результатом этого исследования становится формирование профилей пользователей, или «персон» – архетипических моделей людей, которые будут взаимодействовать с приложением или сайтом.
Профиль пользователя – это не просто набор демографических данных. Он включает в себя социальные характеристики (возраст, образование, род занятий), навыки работы с компьютером (уровень владения, привычки использования цифровых устройств), мотивационно-целевую составляющую (почему пользователь будет использовать «Журнал калорий», какие цели он преследует) и описание рабочей среды (использует ли он мобильное приложение в спортзале или веб-версию дома). Например, для «Журнала калорий» могут быть выделены профили «Студент, желающий похудеть к лету», «Спортсмен, контролирующий макронутриенты» или «Человек с диабетом, отслеживающий уровень сахара». Каждый такой профиль диктует свои требования к интерфейсу, что, в конечном итоге, позволяет создать продукт, максимально отвечающий ожиданиям каждого сегмента аудитории.
В современном мире разработки программного обеспечения все большее распространение получают гибкие методологии, такие как Agile, Scrum и Kanban. Они нашли свое применение и в контексте UI/UX-дизайна, значительно трансформировав традиционный линейный подход. Agile-методологии способствуют итеративному подходу к проектированию, что означает, что дизайн интерфейса не создается один раз и навсегда, а постоянно дорабатывается и улучшается. Это позволяет проводить раннее и частое тестирование с реальными пользователями, что является критически важным для выявления проблем и получения ценной обратной связи на самых ранних этапах.
Постоянная обратная связь от пользователей и заинтересованных сторон позволяет гибко адаптироваться к изменениям требований и приоритизировать задачи на основе реальной ценности для пользователя. Работа в межфункциональных командах, где дизайнеры, разработчики и тестировщики работают в тесном взаимодействии, обеспечивает более глубокое понимание контекста и целей, что в конечном итоге приводит к созданию более согласованного и эффективного пользовательского опыта. Для «Журнала калорий» это означает, что интерфейс может быть быстро адаптирован к новым потребностям пользователей, например, добавлению новых категорий продуктов или интеграции с фитнес-трекерами.
Предотвращение и обработка ошибок в UI
Каждый пользователь рано или поздно столкнется с ошибкой в любом приложении. Искусство хорошего дизайна заключается не только в создании безупречного пути, но и в умении элегантно и эффективно обрабатывать отклонения от этого пути. При проектировании UI необходимо избегать двух основных типов ошибок: промахов и заблуждений.
- Промахи (Slips) – это ошибки, когда пользователь намеревался сделать одно, но случайно сделал другое. Например, случайно нажал не на ту кнопку, ввел неверный символ или пропустил обязательное поле.
- Заблуждения (Mistakes) – это ошибки, когда пользователь правильно выполнил действие, но система повела себя не так, как он ожидал, или его ментальная модель работы приложения оказалась неверна. Например, пользователь думал, что запись о еде будет сохранена автоматически, а её нужно было подтвердить отдельной кнопкой.
Важность предотвращения ошибок заранее трудно переоценить. Для «Журнала калорий» это означает применение ряда методов:
- Валидация ввода данных на стороне клиента: Это позволяет мгновенно сообщать пользователю о некорректном вводе (например, попытка ввести текст в поле «калории») еще до отправки данных на сервер, экономя время и предотвращая фрустрацию.
- Предоставление четких инструкций и подсказок: Например, в полях ввода продуктов могут быть плейсхолдеры «Название продукта», «Граммы», а рядом с полями – иконки с подсказками о допустимом формате.
- Возможность отмены действий пользователем: Кнопка «Отменить» или функция «Шаг назад» позволяют пользователю исправить ошибку без потери данных или необходимости начинать все сначала. Это особенно важно при удалении или изменении существующих записей.
- Использование стандартизированных элементов управления: Привычные пользователю элементы (выпадающие списки, чекбоксы, радиокнопки) уменьшают вероятность ошибок, так как их поведение интуитивно понятно.
Если же ошибка все-таки произошла, сообщения о ней должны быть максимально информативными и полезными:
- Понятность: Сообщение должно быть написано простым языком, избегая технического жаргона. Вместо «Ошибка #0x0000001A: Недопустимый тип данных» лучше написать «Пожалуйста, введите числовое значение в поле ‘Калории'».
- Однозначность: Сообщение должно четко указывать на причину ошибки. «Что-то пошло не так» совершенно бесполезно. «Не удалось сохранить прием пищи: вы не указали название продукта» – гораздо лучше.
- Предложения по исправлению: Идеальное сообщение об ошибке не просто констатирует факт, но и предлагает пользователю пути решения. Например, «Не удалось добавить продукт. Проверьте подключение к интернету или попробуйте позже.»
Применение этих подходов в «Журнале калорий» значительно повысит удобство использования, снизит вероятность некорректного ввода данных и улучшит общее впечатление от приложения.
Основы объектно-ориентированного моделирования и UML
В основе любой сложной программной системы лежит продуманная архитектура и четкое описание её компонентов. Унифицированный язык моделирования (UML) стал де-факто стандартом для достижения этой цели в мире объектно-ориентированной разработки.
Введение в UML
UML (Unified Modeling Language — унифицированный язык моделирования) — это не просто набор символов и линий; это мощный графический язык, предназначенный для определения, представления, проектирования и документирования широкого спектра систем: программных, организационно-экономических, технических и многих других. Он позволяет визуализировать структуру и поведение системы, делая абстрактные концепции осязаемыми и понятными.
История UML началась с попыток объединить лучшие практики объектно-ориентированного анализа и проектирования, разработанные тремя «отцами-основателями» — Гради Бучем, Джеймсом Рамбо и Иваром Якобсоном. Их усилия привели к созданию первой версии UML, которая была стандартизирована консорциумом Object Management Group (OMG) осенью 1997 года. Этот момент стал поворотным для программной инженерии, предоставив разработчикам единый и общепринятый язык визуального моделирования.
Цели разработки UML были амбициозными:
- Предоставление разработчикам единого языка визуального моделирования: Это устранило хаос, связанный с использованием множества разрозненных нотаций, улучшив коммуникацию и взаимопонимание в командах.
- Механизмы расширения и специализации языка: UML позволяет адаптировать его под специфические нужды проекта или предметной области, сохраняя при этом совместимость со стандартом.
- Независимость языка от языков программирования и процессов разработки: UML описывает концепции, которые могут быть реализованы на любом объектно-ориентированном языке (Java, C++, Python и т.д.) и в рамках различных методологий (Agile, Waterfall, RUP).
- Интеграция накопленного практического опыта: UML вобрал в себя лучшие идеи и подходы, проверенные годами в реальных проектах.
Важно понимать, что UML не является языком программирования. Вы не можете «запустить» UML-диаграмму. Однако он служит мощным связующим звеном между концептуальным дизайном и реализацией. На основании хорошо проработанных UML-моделей возможна частичная или даже полная генерация кода, что значительно ускоряет процесс разработки и снижает количество ошибок.
Принципы объектно-ориентированной технологии
Объектно-ориентированная технология (ООТ) — это парадигма программирования, которая рассматривает мир как совокупность взаимодействующих объектов. Она основывается на объектной модели, которая, в свою очередь, зиждется на нескольких фундаментальных принципах:
- Абстрагирование: Это процесс выделения существенных характеристик объекта и отбрасывания несущественных деталей. Например, для «Журнала калорий» объектом «Продукт» важны название, калорийность, белки, жиры, углеводы, но не важен его цвет упаковки или страна происхождения. Абстракция позволяет сосредоточиться на ключевых аспектах.
- Инкапсуляция: Это сокрытие внутренней реализации объекта от внешнего мира. Объект предоставляет строго определенный интерфейс для взаимодействия, а его внутреннее состояние и логика остаются скрытыми. В «Журнале калорий» объект «Пользователь» может иметь метод
обновить_вес(), но как именно он обновляет это значение в базе данных – скрыто от других объектов. Это повышает безопасность и упрощает изменение внутренней логики без затрагивания всей системы. - Модульность: Разделение системы на логически связанные и автономные модули (объекты). Каждый модуль выполняет свою конкретную функцию и взаимодействует с другими модулями через четко определенные интерфейсы. Это упрощает разработку, тестирование и сопровождение больших систем.
- Иерархичность: Упорядочивание абстракций по уровням. Часто это проявляется в виде наследования, когда один класс (потомок) наследует свойства и поведение другого класса (родителя). Например, в «Журнале калорий» может быть базовый класс «Продукт», а от него наследуются «Фрукт», «Овощ», «Мясной Продукт», каждый из которых добавляет свои специфические атрибуты.
- Типизация: Это механизм, который гарантирует, что объекты одного типа ведут себя схожим образом и что с ними можно взаимодействовать определенным образом. Типизация помогает на ранних этапах выявлять ошибки и обеспечивает структурную целостность системы.
- Параллелизм: Способность объектов выполнять свои операции независимо друг от друга или одновременно. Хотя в «Журнале калорий» это может быть не столь очевидно на уровне пользовательского интерфейса, на уровне серверной части обработка запросов от нескольких пользователей может быть параллельной.
- Сохраняемость: Способность объектов сохранять свое состояние между сеансами работы программы. Это критически важно для «Журнала калорий», где данные о питании, пользователях и продуктах должны быть сохранены в базе данных и доступны при следующем запуске приложения.
При объектно-ориентированном подходе данные и поведение объединяются в объекты, которые взаимодействуют друг с другом посредством обмена сообщениями. Такой подход позволяет создавать гибкие, масштабируемые и легко поддерживаемые системы.
Роль UML-диаграмм в моделировании информационных систем
Моделирование информационных систем (ИС) — это не просто прихоть, а неотъемлемый и жизненно важный этап в разработке любого программного обеспечения. Оно позволяет команде разработчиков, аналитиков и заказчиков создать общее видение системы, ещё до того, как будет написана первая строка кода. В этом процессе UML-диаграммы играют ключевую, если не центральную, роль.
UML-диаграммы предоставляют стандартизированный набор инструментов для визуализации и описания различных аспектов системы. Они действуют как универсальный язык, который могут понимать все участники проекта, независимо от их технического бэкграунда. Это особенно важно, когда речь идет о сложных системах, где требуется четкое и недвусмысленное представление.
UML-диаграммы обеспечивают визуализацию как структурных, так и поведенческих аспектов ИС:
- Структурные диаграммы (например, диаграммы классов) показывают статическую структуру системы: какие сущности существуют, каковы их атрибуты и как они связаны друг с другом. Это фундамент, на котором строится вся система.
- Поведенческие диаграммы (например, диаграммы взаимодействия, деятельности, вариантов использования) иллюстрируют динамические аспекты: как система реагирует на внешние воздействия, как объекты взаимодействуют друг с другом, какие последовательности операций выполняются.
Стандартизированный набор UML-диаграмм способствует значительному улучшению коммуникации между участниками проекта. Вместо того чтобы полагаться на текстовые описания, которые могут быть неоднозначными, команда может использовать графические модели, которые легко интерпретируются. Это помогает им гораздо лучше понимать требования, дизайн и функциональные характеристики ИС. Для «Журнала калорий» это означает, что каждый член команды будет иметь четкое представление о том, как пользователь добавляет пищу, как хранится информация о продуктах и как система обрабатывает данные о калориях.
Более того, построение UML-диаграмм помогает отслеживать изменения в системе на протяжении всего жизненного цикла проекта. Когда требования меняются или выявляются новые аспекты, диаграммы могут быть легко обновлены, предоставляя актуальное представление о системе. Это также упрощает управление сложностью системы, позволяя идентифицировать и анализировать потенциальные проблемы и риски на ранних этапах разработки, еще до того, как они превратятся в дорогостоящие ошибки. Таким образом, UML-диаграммы выступают не только как средство описания, но и как мощный инструмент для анализа, проектирования и управления проектами.
Применение UML-диаграмм для проектирования «Журнала калорий»
UML предлагает богатый арсенал диаграмм, каждая из которых предназначена для моделирования определенного аспекта системы. Они делятся на две основные категории: структурные (статические), описывающие статическую структуру системы, и поведенческие (динамические), показывающие её динамическое поведение. Для «Журнала калорий» мы продемонстрируем применение наиболее релевантных диаграмм, чтобы обеспечить всесторонний анализ и проектирование.
Диаграмма вариантов использования (Use Case Diagram)
Диаграмма вариантов использования (Use Case Diagram) — это один из наиболее высокоуровневых и понятных инструментов UML, предназначенный для отражения функционального назначения проектируемой системы с точки зрения конечного пользователя. Она отвечает на вопрос: «Что система должна делать для своих пользователей?».
В центре этой диаграммы находится понятие прецедента (вариант использования) — это типичное взаимодействие пользователя с системой, описывающее видимую пользователем функцию, которая достигает конкретной цели, важной для пользователя. Каждый прецедент представляет собой законченную, осмысленную для пользователя операцию. Например, для «Журнала калорий» такими прецедентами могут быть «Добавление приема пищи», «Просмотр статистики» или «Редактирование профиля».
На диаграмме вариантов использования система представляется в виде акторов (actors) — внешних сущностей, которые взаимодействуют с системой извне. Акторами могут быть люди (например, «Пользователь»), другие устройства (например, «Фитнес-трекер») или внешние программные системы (например, «Сервис аутентификации»). Акторы изображаются в виде стилизованных человеческих фигурок, а варианты использования — в виде овалов.
Связи между акторами и вариантами использования показывают, кто и какие функции инициирует. Кроме того, UML позволяет организовывать варианты использования с помощью специальных связей:
- Связь включения (
«include»): Используется, когда один вариант использования обязательно включает в себя функциональность другого варианта использования. Например, вариант использования «Добавление приема пищи» может включать«include»«Поиск продукта», так как без поиска продукта невозможно его добавить. - Связь расширения (
«extend»): Используется, когда один вариант использования может опционально расширять функциональность другого варианта использования. Например, «Добавление приема пищи» может быть расширено«extend»«Добавлением нового продукта в базу», если пользователь не нашел нужного продукта в существующем списке.
Диаграмма вариантов использования для «Журнала калорий»
| Элемент | Описание |
|---|---|
| Акторы |
|
| Варианты использования |
|
Примерная диаграмма вариантов использования (визуализация):
graph TD
actor[Пользователь] --> (Vhod v sistemu)
actor --> (Registratsiya)
actor --> (Dobavlenie priema pischi)
actor --> (Redaktirovanie priema pischi)
actor --> (Udalenie priema pischi)
actor --> (Prosmotr statistiki)
actor --> (Redaktirovanie profilya)
actor --> (Ustanovka tseley)
actor --> (Nastroyka uvedomleniy)
(Vhod v sistemu) -- «include» --> (Proverka uchetnyh dannyh)
(Dobavlenie priema pischi) -- «include» --> (Poisk produkta po nazvaniyu)
(Dobavlenie priema pischi) -- «extend» --> (Dobavlenie novogo produkta v bazu)
(Redaktirovanie profilya) -- «include» --> (Raschet bazovogo metabolizma)
Диаграмма деятельности (Activity Diagram)
Диаграмма деятельности (Activity Diagram) служит для моделирования динамических аспектов системы, фокусируясь на логике процедур, бизнес-процессах и потоках работ. Она позволяет наглядно представить последовательность действий, условия их выполнения и возможные ветвления, а также параллельные процессы. В отличие от традиционных блок-схем, диаграммы деятельности активно поддерживают параллелизм, что делает их идеальными для моделирования сложных потоков работ.
Диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов. Для «Журнала калорий» они могут быть использованы для отображения порядка выполнения вариантов использования, например, детально описав процесс добавления приема пищи.
Диаграмма деятельности для сценария «Добавление приема пищи»
Рассмотрим процесс добавления приема пищи, который является одним из центральных сценариев в «Журнале калорий».
| Элемент Диаграммы | Описание |
|---|---|
| Начальная нода | Обозначает начало процесса. |
| Действия |
|
| Ветвление/Слияние | Точка, где поток действий может пойти по одному из нескольких путей (например, продукт найден/не найден). |
| Завершающая нода | Обозначает окончание процесса. |
Примерная диаграмма деятельности (визуализация):
graph TD
start(Начало) --> A[Открыть экран "Добавить прием пищи"]
A --> B{Выбрать тип приема пищи}
B --> C[Ввести название продукта]
C --> D[Отобразить результаты поиска]
D --> E{Продукт найден?}
E -- Да --> F[Выбрать продукт из списка]
E -- Нет --> G{Предложить добавить новый продукт в базу?}
G -- Да --> H[Добавить новый продукт]
G -- Нет --> I[Показать сообщение об ошибке поиска]
I --> J(Конец)
H --> F
F --> K[Ввести количество продукта (граммы/порции)]
K --> L[Рассчитать калории и БЖУ]
L --> M{Данные корректны?}
M -- Да --> N[Сохранить прием пищи]
M -- Нет --> O[Сообщить об ошибке ввода]
O --> K
N --> P[Обновить статистику пользователя]
P --> Q[Показать сообщение об успехе]
Q --> J
Диаграмма классов (Class Diagram)
Диаграмма классов (Class Diagram) — это одна из наиболее фундаментальных и широко используемых структурных диаграмм в UML. Она представляет собой статическое представление системы, определяющее типы классов системы, их атрибуты (данные), операции (методы) и связи, существующие между ними. Диаграмма классов является центральной методикой моделирования, используемой практически во всех объектно-ориентированных методах, поскольку она описывает модель программной системы, отражающую основные закономерности предметной области.
На диаграмме классов могут отображаться:
- Классы: Представляются прямоугольниками, разделенными на три секции: имя класса, атрибуты и операции.
- Атрибуты: Характеристики класса (например,
имядля классаПользователь,калорийностьдляПродукт). - Операции (методы): Действия, которые класс может выполнять (например,
добавитьПриемПищи()дляПользователь). - Связи: Отношения между классами. Базовым отношением является ассоциация — структурное отношение, описывающее потенциально возможные отношения между объектами программной системы. Ассоциации могут иметь кратность (multiplicity), указывающую, сколько объектов одного класса могут быть связаны с объектами другого класса (например, «один ко многим», «многие ко многим»). Другие важные связи включают агрегацию (отношение «целое-часть», но часть может существовать отдельно), композицию (более строгая форма агрегации, часть не может существовать без целого) и обобщение (наследование).
Диаграммы классов позволяют моделировать структуру данных и взаимосвязи между классами, что критически важно для проектирования базы данных и общей архитектуры приложения.
Диаграмма классов для «Журнала калорий»
Рассмотрим основные классы, их атрибуты, методы и взаимосвязи для приложения «Журнал калорий».
| Класс | Атрибуты (Примеры) | Операции (Примеры) | Связи с другими классами |
|---|---|---|---|
| Пользователь | id: Integer, имя: String, email: String, пароль: String, вес: Double, рост: Double, дата_рождения: Date, пол: String, цель_калорий: Integer, цель_белков: Integer, цель_жиров: Integer, цель_углеводов: Integer |
зарегистрироваться(), войти(), обновитьПрофиль(), добавитьПриемПищи(), просмотретьСтатистику() |
1..1 --- 0..* Прием_Пищи1..1 --- 0..* Продукт (если пользователь может добавлять свои продукты) |
| Прием_Пищи | id: Integer, дата_время: DateTime, тип: String (Завтрак, Обед, Ужин, Перекус), пользователь_id: Integer |
сохранить(), редактировать(), удалить() |
1..1 --- 1..* Деталь_Приема_Пищи |
| Деталь_Приема_Пищи | id: Integer, прием_пищи_id: Integer, продукт_id: Integer, количество: Double (граммы) |
рассчитатьКалории(), рассчитатьБЖУ() |
1..1 --- 1..1 Продукт |
| Продукт | id: Integer, название: String, калории_на_100г: Double, белки_на_100г: Double, жиры_на_100г: Double, углеводы_на_100г: Double, пользователь_id: Integer (nullable, для пользовательских продуктов) |
сохранить(), редактировать(), удалить() |
0..* --- 1..1 Пользователь (для продуктов, добавленных пользователем) |
Примерная диаграмма классов (визуализация):
classDiagram
class Пользователь {
+id: Integer
+имя: String
+email: String
+пароль: String
+вес: Double
+рост: Double
+дата_рождения: Date
+пол: String
+цель_калорий: Integer
+цель_белков: Integer
+цель_жиров: Integer
+цель_углеводов: Integer
+зарегистрироваться()
+войти()
+обновитьПрофиль()
+добавитьПриемПищи()
+просмотретьСтатистику()
}
class Прием_Пищи {
+id: Integer
+дата_время: DateTime
+тип: String
+пользователь_id: Integer
+сохранить()
+редактировать()
+удалить()
}
class Деталь_Приема_Пищи {
+id: Integer
+прием_пищи_id: Integer
+продукт_id: Integer
+количество: Double
+рассчитатьКалории()
+рассчитатьБЖУ()
}
class Продукт {
+id: Integer
+название: String
+калории_на_100г: Double
+белки_на_100г: Double
+жиры_на_100г: Double
+углеводы_на_100г: Double
+пользователь_id: Integer (nullable)
+сохранить()
+редактировать()
+удалить()
}
Пользователь "1" -- "0..*" Прием_Пищи : владеет
Пользователь "1" -- "0..*" Продукт : добавляет
Прием_Пищи "1" -- "1..*" Деталь_Приема_Пищи : содержит
Деталь_Приема_Пищи "1" -- "1" Продукт : относится_к
Диаграмма последовательности (Sequence Diagram)
Диаграмма последовательности (Sequence Diagram) — это поведенческая UML-диаграмма, которая моделирует взаимодействие объектов на основе временной последовательности. Она наглядно иллюстрирует, как объекты взаимодействуют друг с другом, обмениваясь сообщениями, в рамках конкретного сценария или варианта использования. Диаграмма последовательности фокусируется на порядке событий и потоке управления.
На диаграмме последовательности каждый объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия, называемая линией жизни (lifeline) объекта. Линия жизни представляет собой существование объекта во времени. Стрелки между линиями жизни объектов соответствуют сообщениям, передаваемым между ними. Сообщения появляются на диаграмме в порядке сверху вниз, что отражает временную последовательность их выполнения. Каждое сообщение помечается именем, могут быть добавлены аргументы и управляющая информация. Также возможно показать самоделегирование (self-delegation) — сообщение, которое объект посылает самому себе для выполнения внутренней операции.
Диаграмма последовательности особенно полезна для понимания того, как различные части системы сотрудничают для достижения определенной цели.
Диаграмма последовательности для сценария «Запись нового приема пищи»
Рассмотрим сценарий, когда пользователь записывает новый прием пищи, чтобы отследить взаимодействие между компонентами UI, контроллером и базой данных.
| Компонент | Описание |
|---|---|
| UI | Представляет собой пользовательский интерфейс приложения (мобильное или веб), с которым непосредственно взаимодействует пользователь. |
| Контроллер_ПриемаПищи | Обрабатывает логику, связанную с приемами пищи. Он получает данные от UI, взаимодействует с сервисами и базой данных. |
| Сервис_Продуктов | Отвечает за поиск продуктов в базе данных, а также за добавление новых продуктов. |
| База_Данных | Хранилище всей информации о пользователях, продуктах, приемах пищи и их деталях. |
Примерная диаграмма последовательности (визуализация):
sequenceDiagram
participant User as Пользователь
participant UI as Пользовательский интерфейс
participant Controller as Контроллер_ПриемаПищи
participant ProductService as Сервис_Продуктов
participant DB as База_Данных
User->>UI: Открыть экран "Добавить прием пищи"
UI->>User: Отобразить форму ввода
User->>UI: Ввести название продукта ("яблоко")
UI->>Controller: запроситьПродукты(название="яблоко")
Controller->>ProductService: найтиПродукты(название="яблоко")
ProductService->>DB: SELECT * FROM Продукты WHERE название LIKE '%яблоко%'
DB-->>ProductService: [список продуктов]
ProductService-->>Controller: [список продуктов]
Controller-->>UI: отобразитьСписокПродуктов([список продуктов])
UI->>User: Отобразить результаты поиска
User->>UI: Выбрать "Яблоко (100г)"
User->>UI: Ввести количество (150г)
UI->>Controller: добавитьПриемПищи(пользователь_id, продукт_id=X, количество=150, тип="перекус")
Controller->>Controller: рассчитатьКалорииИБЖУ(продукт_id=X, количество=150)
Controller->>DB: INSERT INTO Приемы_Пищи (пользователь_id, дата_время, тип) VALUES (...)
DB-->>Controller: прием_пищи_id
Controller->>DB: INSERT INTO Детали_Приема_Пищи (прием_пищи_id, продукт_id, количество) VALUES (...)
DB-->>Controller: успех
Controller-->>UI: приемПищиДобавлен(успех=true)
UI->>User: Показать сообщение "Прием пищи добавлен!"
В этом примере наглядно видно, как пользователь взаимодействует с UI, который передает запросы контроллеру. Контроллер, в свою очередь, координирует работу с сервисом продуктов и базой данных, чтобы выполнить задачу записи приема пищи.
Проектирование базы данных для «Журнала калорий»
База данных является «сердцем» любой информационной системы, и «Журнал калорий» не исключение. Её грамотное проектирование критически важно для обеспечения стабильности, производительности и масштабируемости приложения. Без хорошо структурированной и эффективной базы данных, даже самый интуитивный интерфейс и продуманная бизнес-логика не смогут обеспечить бесперебойную работу.
Концепции проектирования информационных систем и баз данных
Согласно стандарту ISO 24765, проектирование — это систематический процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части. Целью проектирования является не только детализация внешних свойств системы, но и тщательное определение её внутренних свойств, что включает в себя и структуру базы данных.
Жизненный цикл информационной системы (ИС) обычно состоит из нескольких этапов:
- Планирование: Определение целей, масштаба и ресурсов проекта.
- Сбор и анализ требований: Детальное изучение потребностей пользователей и функциональных требований к системе.
- Проектирование системы: Разработка архитектуры, компонентов и интерфейсов, включая, что особенно важно, проектирование базы данных.
- Создание прототипа: Быстрая реализация ключевых частей системы для получения обратной связи.
- Реализация: Написание кода и сборка системы.
- Тестирование: Проверка функциональности, производительности и безопасности.
- Преобразование (развертывание): Внедрение системы в эксплуатацию.
- Сопровождение: Поддержка, обновление и развитие системы.
Хорошо структурированная информация в базе данных позволяет беспроблемно эксплуатировать систему, выполнять её текущее обслуживание, а также модифицировать и развивать её при модернизации предприятия. Небрежное проектирование БД на ранних этапах может привести к серьезным проблемам с производительностью, целостностью данных и сложностью внесения изменений в будущем, требуя значительных ресурсов на исправление.
В современных условиях доминируют гибкие (Agile) методологии, такие как Scrum и Kanban, а также подход DevOps, направленный на интеграцию процессов разработки и эксплуатации. Эти подходы также влияют на проектирование баз данных, способствуя итеративному уточнению схемы и использованию миграций для управления изменениями. Помимо этого, проектирование систем на основе микросервисов подразумевает, что каждый микросервис может иметь свою собственную, строго специализированную базу данных, что требует особого внимания к межсервисному взаимодействию и согласованности данных.
Один из ключевых аспектов проектирования баз данных в объектно-ориентированном подходе — это трансформация модели программной системы (представленной, например, диаграммой классов) в логическую модель базы данных. Классы становятся таблицами, атрибуты — столбцами, а ассоциации — связями между таблицами (внешними ключами). Принципы исследования и описания предметной области, структурного и объектно-ориентированного анализа, а также проектирования ИС и постановки требований к их разработке излагаются в многочисленных учебных пособиях, подчеркивая важность этого этапа.
Значительная часть кода для работы с базой данных, включая создание таблиц, запросы и операции CRUD (Create, Read, Update, Delete), может генерироваться автоматически с помощью CASE-средств или ORM-фреймворков. Автоматическая генерация кода с помощью CASE-средств может сократить время разработки на 30-50% и снизить количество ошибок. Это особенно эффективно для генерации шаблонного кода, структуры классов, методов-заглушек и взаимодействия с базой данных, причем для некоторых приложений может быть сгенерировано до 70-80% рутинного кода. Это позволяет разработчикам сосредоточиться на более сложной бизнес-логике, тем самым повышая общую эффективность проекта.
Разработка структуры базы данных для «Журнала калорий»
Основываясь на разработанной ранее диаграмме классов, мы можем детализировать логическую структуру таблиц базы данных для «Журнала калорий». Каждому классу будет соответствовать таблица, а атрибуты классов станут столбцами таблиц. Связи между классами будут реализованы через внешние ключи.
| Таблица | Столбцы (Тип данных) | Описание | Связи (Внешние ключи) |
|---|---|---|---|
| Пользователи | id (INT, PRIMARY KEY, AUTO_INCREMENT)имя (VARCHAR(255))email (VARCHAR(255), UNIQUE)пароль_хеш (VARCHAR(255))вес (DECIMAL(5,2))рост (DECIMAL(5,2))дата_рождения (DATE)пол (VARCHAR(10))цель_калорий (INT)цель_белков (INT)цель_жиров (INT)цель_углеводов (INT) |
Хранит информацию о зарегистрированных пользователях, их физических параметрах и диетических целях. | — |
| Продукты | id (INT, PRIMARY KEY, AUTO_INCREMENT)название (VARCHAR(255))калории_на_100г (DECIMAL(6,2))белки_на_100г (DECIMAL(5,2))жиры_на_100г (DECIMAL(5,2))углеводы_на_100г (DECIMAL(5,2))пользователь_id (INT, NULLABLE) |
Каталог продуктов с их пищевой ценностью. Поле пользователь_id позволяет пользователям добавлять собственные продукты. |
FK_Продукты_Пользователи (пользователь_id REFERENCES Пользователи.id) |
| Приемы_Пищи | id (INT, PRIMARY KEY, AUTO_INCREMENT)пользователь_id (INT)дата_время (DATETIME)тип (VARCHAR(50)) |
Записи о каждом приеме пищи пользователя (завтрак, обед, ужин, перекус). | FK_Приемы_Пищи_Пользователи (пользователь_id REFERENCES Пользователи.id) |
| Детали_Приемов_Пищи | id (INT, PRIMARY KEY, AUTO_INCREMENT)прием_пищи_id (INT)продукт_id (INT)количество (DECIMAL(7,2)) |
Детализация каждого приема пищи, связывающая его с конкретными продуктами и их количеством. | FK_Детали_Приемов_Пищи_Приемы_Пищи (прием_пищи_id REFERENCES Приемы_Пищи.id)FK_Детали_Приемов_Пищи_Продукты (продукт_id REFERENCES Продукты.id) |
Такая структура базы данных обеспечивает эффективное хранение и управление информацией о калориях, продуктах и пользователях, позволяя легко выполнять запросы для расчета статистики, добавления новых записей и редактирования существующих.
Инструменты и методологии проектирования баз данных
Для работы с базами данных и их программного управления ключевыми являются языки, такие как SQL (Structured Query Language) и QBE (Query By Example). SQL — это стандартизированный язык для определения, манипулирования и управления данными в реляционных базах данных. QBE, хотя и менее распространен, предоставляет более визуальный подход к запросам.
В контексте современных методологий проектирования ИС и БД, Agile-подходы (Scrum, Kanban) способствуют итеративному развитию схемы базы данных, используя концепции «миграций» для управления изменениями. Подход DevOps интегрирует процессы разработки и эксплуатации, что означает тесное сотрудничество между разработчиками баз данных и администраторами, а также автоматизацию развертывания изменений схемы. Архитектура микросервисов, в свою очередь, часто приводит к созданию множества небольших, специализированных баз данных, что требует особого внимания к дизайну API для взаимодействия между ними и обеспечению согласованности данных в распределенной среде.
Инструменты моделирования и прототипирования
Эффективная разработка программного обеспечения невозможна без адекватного инструментария. Для UML-моделирования и прототипирования пользовательских интерфейсов существует широкий спектр решений, каждое из которых обладает своими преимуществами и особенностями.
Обзор средств UML-моделирования
Выбор инструмента для создания UML-диаграмм является критически важной задачей, поскольку от него зависит удобство работы, качество моделей и возможность интеграции в общий цикл разработки. Практически все мировые производители CASE-средств поддерживают UML в своих продуктах.
Среди современных и широко используемых инструментов UML-моделирования выделяют:
- Enterprise Architect (Sparx Systems): Мощное и многофункциональное CASE-средство, поддерживающее все типы UML-диаграмм, а также другие стандарты моделирования (BPMN, SysML). Предлагает широкие возможности для генерации кода, обратного проектирования, управления требованиями и командной работы. Часто используется в крупных проектах.
- Visual Paradigm: Еще один комплексный инструмент с богатым функционалом, включающим поддержку UML, BPMN, ERD, генерацию кода, управление проектами и интеграцию с популярными IDE. Известен своим интуитивно понятным интерфейсом.
- StarUML: Легковесный, но при этом функциональный инструмент для создания UML-диаграмм. Отличается простотой использования и открытой архитектурой, позволяющей расширять его функциональность с помощью плагинов. Доступен как для коммерческого, так и для некоммерческого использования.
- Lucidchart: Облачный инструмент для создания различных диаграмм, включая UML. Отличается простотой использования, возможностями для совместной работы в реальном времени и богатой библиотекой шаблонов. Идеален для команд, которым нужна быстрая и удобная визуализация.
- Draw.io (он же diagrams.net): Бесплатный онлайн-инструмент для создания диаграмм, который может работать как в браузере, так и в виде десктопного приложения. Поддерживает широкий спектр диаграмм, включая базовые UML-диаграммы. Отличное решение для быстрого прототипирования и визуализации.
Кроме того, существуют средства для разработки графических редакторов DSL (Domain-Specific Language) с возможностью определения собственных графических нотаций, такие как MetaEdit+, MS DSL Tools, Eclipse GMF, State Machine Designer, REAL-IT, UFO-toolkit. QReal — это сложная система с многоуровневой архитектурой, позволяющая создавать визуальные редакторы как подключаемые модули, что дает максимальную гибкость для специфических задач.
Обзор средств прототипирования UI/UX
Помимо UML-моделирования архитектуры системы, не менее важным является прототипирование пользовательского интерфейса. Это позволяет визуализировать будущий продукт, получить обратную связь от пользователей на ранних этапах и итеративно улучшать дизайн.
Для «Журнала калорий» могут быть использованы следующие инструменты прототипирования UI/UX:
- Figma: Лидер в области совместного дизайна интерфейсов. Позволяет создавать макеты, прототипы, дизайн-системы и работать над проектом в реальном времени с другими членами команды. Отличный выбор для мобильных и веб-приложений.
- Adobe XD: Часть Creative Cloud, предлагающая мощные инструменты для дизайна и прототипирования UX/UI. Позволяет создавать интерактивные прототипы и проводить тестирование.
- Sketch: Популярный инструмент для дизайна интерфейсов, особенно среди дизайнеров на macOS. Обладает обширной экосистемой плагинов.
- Axure RP: Мощный инструмент для создания высокодетализированных интерактивных прототипов и спецификаций. Подходит для сложных проектов.
- InVision: Платформа для создания интерактивных прототипов из статических макетов, совместной работы и сбора обратной связи.
Критерии выбора инструментария
Выбор подходящих средств моделирования и прототипирования является стратегическим решением, которое может существенно повлиять на ход проекта. При их анализе и выборе следует учитывать следующие критерии:
- Поддержка стандарта UML: Инструмент должен полностью или в достаточной степени соответствовать спецификациям UML, чтобы обеспечить корректность и переносимость моделей.
- Возможность генерации и обратного проектирования кода: Некоторые CASE-средства могут генерировать каркас кода на основе UML-диаграмм, а также создавать диаграммы по существующему коду, что ускоряет разработку и документирование.
- Интеграция с другими инструментами разработки: Желательно, чтобы выбранные инструменты могли интегрироваться с IDE (например, IntelliJ IDEA, Visual Studio Code), системами контроля версий (Git) и системами управления проектами.
- Поддержка командной работы: Для современных проектов критически важна возможность совместной работы над моделями и прототипами, включая контроль версий, комментарии и одновременное редактирование.
- Удобство использования и производительность: Инструмент должен быть интуитивно понятным, иметь хорошо продуманный интерфейс и работать быстро, не замедляя процесс проектирования.
- Стоимость и лицензирование: Необходимо учитывать бюджет проекта и выбрать оптимальную модель лицензирования (бесплатное, коммерческое, подписка).
- Документация и сообщество: Наличие хорошей документации, обучающих материалов и активного сообщества пользователей может значительно упростить освоение инструмента и решение возникающих проблем.
Тщательный анализ этих критериев позволит выбрать наиболее подходящий инструментарий для эффективного проектирования «Журнала калорий», обеспечивая как структурированную архитектуру, так и удобный пользовательский интерфейс.
Выводы и заключение
Настоящая курсовая работа представила исчерпывающий анализ и проектирование программного обеспечения «Журнал калорий», демонстрируя комплексный подход к разработке информационных систем. Мы обозначили актуальность приложения для отслеживания питания в современном мире и последовательно реализовали поставленные цели и задачи.
Мы углубились в теоретические основы проектирования пользовательского интерфейса, рассмотрев междисциплинарный характер человеко-машинного взаимодействия и фундаментальную важность пользовательско-ориентированного подхода. Детальное изучение ключевых принципов UI – контроля пользователем, уменьшения загрузки памяти, последовательности, естественности, предотвращения ошибок, обратной связи, гибкости, эффективности, эстетики, минимализма, совместимости и надежности – позволило нам сформулировать конкретные рекомендации для «Журнала калорий», а также подчеркнуть роль Agile-методологий в современном UI/UX-дизайне.
Далее мы перешли к основам объектно-ориентированного моделирования, представив Унифицированный язык моделирования (UML) как стандартный и мощный инструмент для визуализации архитектуры системы. Были раскрыты основные принципы объектной модели: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм и сохраняемость, которые составляют фундамент для понимания внутренней логики программ.
Кульминацией практической части стало применение различных UML-диаграмм для проектирования «Журнала калорий». Мы разработали диаграмму вариантов использования, чтобы четко определить функциональность системы с точки зрения пользователя; диаграмму деятельности для моделирования потока работ в сценарии добавления приема пищи; диаграмму классов, которая статически описала структуру данных и взаимосвязи ключевых сущностей приложения (Пользователь, Прием пищи, Продукт); и, наконец, диаграмму последовательности, иллюстрирующую динамическое взаимодействие объектов при записи нового приема пищи.
Завершающим этапом стало проектирование базы данных, где мы трансформировали объектно-ориентированную модель в логическую структуру таблиц, определив поля и связи, необходимые для эффективного хранения и управления данными о калориях, продуктах и пользователях. Также был представлен обзор современных инструментов для UML-моделирования и прототипирования UI/UX, с формулированием критериев для их выбора.
Результаты данной работы подтверждают значимость комплексного подхода к проектированию программного обеспечения, объединяющего в себе глубокий анализ пользовательского опыта и строгие методологии объектно-ориентированного моделирования. Применение UI/UX-принципов гарантирует создание интуитивно понятного и эффективного интерфейса, а использование UML-диаграмм обеспечивает четкую, масштабируемую и поддерживаемую архитектуру.
Возможные направления для дальнейшего развития проекта «Журнал калорий» и исследования:
- Разработка детализированных прототипов пользовательского интерфейса на основе принципов, описанных в данной работе.
- Реализация серверной части приложения с использованием выбранных технологий и спроектированной базы данных.
- Интеграция с внешними API для получения данных о продуктах или синхронизации с фитнес-трекерами.
- Применение методов машинного обучения для персонализированных рекомендаций по питанию.
- Проведение юзабилити-тестирования с реальными пользователями для оценки эффективности интерфейса.
Данная курсовая работа заложила прочный фундамент для дальнейшей разработки «Журнала калорий» как современного и конкурентоспособного программного продукта, способного помочь пользователям достичь своих целей в области здоровья и питания.
Список использованной литературы
- Принципы разработки пользовательских интерфейсов // CyberLeninka : [сайт]. URL: https://cyberleninka.ru/article/n/printsipy-razrabotki-polzovatelskih-interfeysov (дата обращения: 30.10.2025).
- Смирнова М.В. Основные принципы и правила разработки графического пользовательского интерфейса // Молодой ученый : [сайт]. URL: https://moluch.ru/archive/291/66058/ (дата обращения: 30.10.2025).
- Астафьева В. В. Принципы и правила проектирования пользовательского интерфейса // Молодой ученый : [сайт]. URL: https://moluch.ru/archive/291/66058/ (дата обращения: 30.10.2025).
- Пирлиев К., Нурмаммедова О., Сарапов Р. Принципы эффективного дизайна пользовательских интерфейсов // CyberLeninka : [сайт]. URL: https://cyberleninka.ru/article/n/printsipy-effektivnogo-dizayna-polzovatelskih-interfeysov (дата обращения: 30.10.2025).
- ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС ДЛЯ КОРПОРАТИВНОГО ВЕБ-ПРИЛОЖЕНИЯ: РАЗРАБОТКА, ПРИНЦИПЫ И ЛУЧШИЕ РЕШЕНИЯ // CyberLeninka : [сайт]. URL: https://cyberleninka.ru/article/n/polzovatelskiy-interfeys-dlya-korporativnogo-veb-prilozheniya-razrabotka-printsipy-i-luchshie-resheniya (дата обращения: 30.10.2025).
- Пирогов Владислав Юрьевич. Информационные системы и базы данных: организация и проектирование: учебное пособие. БХВ, 2011.
- МОДЕЛИРОВАНИЕ ИНФОРМАЦИОННЫХ ПРОЦЕССОВ С ПОМОЩЬЮ UML // CyberLeninka : [сайт]. URL: https://cyberleninka.ru/article/n/modelirovanie-informatsionnyh-protsessov-s-pomoschyu-uml (дата обращения: 30.10.2025).
- Чистов Д. В. Проектирование информационных систем : учебник и практикум для вузов. Юрайт, 2024.
- Рочев К.В. Проектирование информационных систем. Издательство Лань, 2025.
- Гвоздева Т. В., Баллод Б. А. Проектирование информационных систем. Методы и средства структурно-функционального проектирования. Практикум. Издательство Лань, 2024.
- Вейцман В. М. Проектирование информационных систем. Издательство Лань.
- СРАВНИТЕЛЬНЫЙ АНАЛИЗ РЕДАКТОРОВ ВИЗУАЛЬНЫХ МОДЕЛЕЙ // ScienceForum : [сайт]. URL: https://www.scienceforum.ru/2014/pdf/8554.pdf (дата обращения: 30.10.2025).
- Шаблоны унифицированного языка моделирования для проектирования информационных систем UML TEMPLATES FOR INFORMATION SYSTEMS DESIGN // ResearchGate : [сайт]. URL: https://www.researchgate.net/publication/372722894_Sapka_N_U_Kajsanov_B_T_UML_TEMPLATES_FOR_INFORMATION_SYSTEMS_DESIGN (дата обращения: 30.10.2025).
- Построение диаграммы вариантов использования как средство описания типичных взаимодействий системы и пользователя на основе сервиса по сдаче помещений в аренду // CyberLeninka : [сайт]. URL: https://cyberleninka.ru/article/n/postroenie-diagrammy-variantov-ispolzovaniya-kak-sredstvo-opisaniya-tipichnyh-vzaimodeystviy-sistemy-i-polzovatelya-na-osnove-servisa-po-sdache-pomescheniy-v-arendu (дата обращения: 30.10.2025).
- ОБЗОР СОВРЕМЕННЫХ СРЕДСТВ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ // CyberLeninka : [сайт]. URL: https://cyberleninka.ru/article/n/obzor-sovremennyh-sredstv-imitatsionnogo-modelirovaniya (дата обращения: 30.10.2025).
- Розенберг Д., Кендалл С. Применение объектного моделирования на основе прецедентов с использованием UML: пример электронной коммерции. Addison Wesley, 2002.
- Разработка UML-модели информационно-аналитической системы перспективных научных проектов // Вестник ИрГТУ : [сайт]. URL: https://izdat.istu.ru/index.php/vestnik/article/view/3130 (дата обращения: 30.10.2025).
- ОБЗОР И АНАЛИЗ СРЕДСТВ МОДЕЛИРОВАНИЯ // Science Education : [сайт]. URL: https://science-education.ru/ru/article/view?id=21408 (дата обращения: 30.10.2025).
- Transformation of UML Class Diagram to UML Sequence Diagram // Semantic Scholar : [сайт]. URL: https://www.semanticscholar.org/paper/Transformation-of-UML-Class-Diagram-to-UML-Sequence/8c4b2e847c21147e808269e3650058b88d363b9d (дата обращения: 30.10.2025).