ГБПОУ ВО ХЛК имени Г.Ф.Морозова / 17.04.2025 / Иванников Илья 641 группа 4 курс / ila_iv_id566844132@dnevnik.ru / ПРЕДДИПЛОМНАЯ ПРАКТИКА

разработка требований к системе: формулирование технических и функциональных требований на основе анализа бизнес-процессов;

планирование внедрения: создание плана внедрения изменений,

включая этапы разработки, тестирования и обучения персонала;

мониторинг и анализ результатов: после внедрения системы необ-

ходимо провести мониторинг изменений и оценить их влияние на работу боль-

ницы.

Этот анализ поможет обеспечить, что новая система автоматизации бу-

дет соответствовать реальным потребностям больницы и принесет максималь-

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

2.4 Характеристика приложения StarUML

StarUML — это одна из популярных программ для проектирования и мо-

делирования программного обеспечения. Она поддерживает UML (Unified

Modeling Language), что делает её удобным инструментом для визуализации и документирования архитектуры систем. Вот некоторые ключевые характери-

стики StarUML:

поддержка стандартов uml 2.x: staruml полностью совместима со стандартами uml 2.x, что позволяет создавать различные типы диаграмм, такие как классы, объекты, состояния, активности, компоненты и развертывания;

расширяемость: пользователи могут расширять функциональ-

ность staruml с помощью плагинов, которые могут быть разработаны на

javascript или typescript;

импорт/экспорт: поддерживает импорт из других программ моде-

лирования и экспорт диаграмм в различные форматы, включая html, jpeg, png

и др;

11

шаблоны и стили: предлагает разнообразные шаблоны и стили оформления диаграмм, что позволяет пользователям создавать профессио-

нально выглядящие документы;

профили и стереотипы: позволяет использовать профили uml для настройки моделей под специфические требования проекта;

совместимость с mdg (model driven generation): возможность гене-

рации кода на основе моделей для различных языков программирования;

интерфейс и удобство использования: интуитивно понятный ин-

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

StarUML является мощным инструментом для разработчиков программ-

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

Преимущества:

поддержка uml 2.x: staruml поддерживает последние стандарты

uml, что позволяет создавать все основные типы uml-диаграмм;

расширяемость: пользователи могут улучшать функциональность приложения с помощью плагинов;

интуитивно понятный интерфейс: удобный и понятный интерфейс облегчает работу с программой как новичкам, так и профессионалам;

широкие возможности экспорта: экспорт диаграмм в различные форматы, включая изображения и документы;

шаблоны и стили: возможность использовать различные шаблоны

истили для диаграмм;

генерация кода в языки: C#, Java, С++;

12

поддержка работы с фреймворками;

удобный графический редактор;

полное соответствие стандарту UML 2.0;

возможность расширения функционала (про это написано отдель-

ное руководство разработчика);

кспорт документации в форматы: DOC, PPT, TXT, XLS;

поддрежка паттернов;

импорт проектов Rational Rose;

приятный размер дистрибутива.

Недостатки:

ресурсоемкость: может потреблять значительные системные ре-

сурсы, особенно на слабых компьютерах;

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

ограниченная поддержка интеграции: интеграция с некоторыми другими инструментами и системами может быть ограничена;

закрытый исходный код;

бесплатные case-инструменты;

неполная поддержка UML 2.0;

отсутствие возможности отменить изменения;

разработчики ArgoUML должны быть настолько оптимистич-

ными, что люди (особенно разработчики программного обеспечения) никогда не ошибаются.

Эти аспекты следует учитывать при выборе инструмента для моделиро-

вания в зависимости от конкретных потребностей и ресурсов. StarUML подхо-

дит для широкого спектра задач по проектированию программного обеспече-

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

13

Раздел 3 Построение логической модели

3.1 Модель деятельности пользователей

Модель деятельности пользователей — это инструмент визуализации и анализа, который используется для представления потоков работы или бизнес-

процессов. В контексте UML (Unified Modeling Language), модель деятельно-

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

Вот основные компоненты модели деятельности:

действия: основные шаги или задачи, которые выполняются в про-

цессе;

решения: узлы, где процесс может разветвляться на основе усло-

вий или правил;

параллельные процессы: действия, которые могут выполняться одновременно;

потоки данных: показывают, как данные передаются между дей-

ствиями;

события: триггеры, которые запускают или завершают процесс;

пулы и дорожки: представляют различных участников или роли,

которые участвуют в процессе.

Модель деятельности помогает анализировать и оптимизировать про-

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

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

шения качества обслуживания.

На рисунке 1 представлена модель деятельности пользователей.

14

Рисунок 1 – Модель деятельности пользователей

3.2 Функциональная диаграмма IDEFO

Функциональная диаграмма IDEF0 является методологией, разработан-

ной для моделирования решений, функций и процессов в системах. Она ис-

пользуется для анализа работы компании или организации и для представле-

ния процессов на высоком уровне. Диаграмма IDEF0 включает в себя серию блоков или "коробок", которые представляют функции или процессы, и стре-

лок, показывающих потоки данных и взаимосвязи между этими функциями.

Вот основные элементы функциональной диаграммы IDEF0:

1.Блоки (Boxes): Каждый блок представляет отдельную функцию или процесс в системе. Блоки имеют уникальные идентификаторы и краткое описание функции.

2.Стрелки (Arrows): Существуют четыре типа стрелок, которые свя-

зывают блоки:

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

необходимые для выполнения функции;

15

выходы (outputs): представляют результаты или продукты, генери-

руемые функцией;

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

управление (controls): указывают ограничения или правила, кото-

рые направляют выполнение функции.

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

4.Связность: Диаграммы IDEF0 могут быть связаны друг с другом,

показывая, как один процесс влияет на другой.

Функциональная диаграмма IDEF0 помогает анализировать "что должно быть сделано" и "как это должно быть сделано", обеспечивая ясность и струк-

турированность в понимании сложных систем и процессов. Это особенно по-

лезно при проектировании систем, оптимизации процессов и внедрении изме-

нений в организационные структуры.

На рисунке 2 представлена функциональная диаграмма IDEF0.

Рисунок 2 – Функциональная диаграмма IDEFO

16

3.3 Диаграмма декомпозиции

Диаграмма декомпозиции — это инструмент, используемый для визуа-

лизации иерархической структуры системы или процесса. Она позволяет раз-

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

Вот ключевые элементы диаграммы декомпозиции:

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

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

ставляют более мелкие и специфические части системы;

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

Диаграмма декомпозиции помогает:

определить иерархию: понять, какие компоненты являются частью более крупных элементов и как они соотносятся друг с другом;

упростить сложность: разбить сложные системы на более простые

ипонятные части;

облегчить коммуникацию: улучшить общение между членами ко-

манды и заинтересованными сторонами, предоставляя четкую визуализацию структуры;

планировать проекты: использовать диаграмму для планирования задач и распределения ресурсов.

Диаграмма декомпозиции широко применяется в управлении проек-

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

17

На рисунке 3 представлена диаграмма декомпозиции.

Рисунок 3 – Диаграмма декомпозиции

3.4 Модель взаимодействия объектов

Модель взаимодействия объектов представляет собой концепцию, кото-

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

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

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

Основные принципы модели взаимодействия объектов включают:

инкапсуляция: каждый объект скрывает свое внутреннее состоя-

ние и обеспечивает доступ к нему только через заданный интерфейс;

наследование: объекты могут быть связаны иерархическими отно-

шениями, где дочерние объекты наследуют свойства и методы родительских

объектов;

18

полиморфизм: объекты могут вести себя по-разному в зависимо-

сти от контекста.

Модель взаимодействия объектов помогает обеспечить четкую струк-

туру и организацию программного кода, упростить его повторное использова-

ние и обеспечить лучшую масштабируемость и гибкость при разработке про-

грамм.

На рисунке 4 представлена модель взаимодействия объектов.

Рисунок 4 – Модель взаимодействия объектов

3.5 Диаграмма прецедентов

Диаграмма прецедентов (или use case diagram) — это визуальное пред-

ставление функциональных требований системы, которое показывает различ-

ные действия или услуги, которые пользователь (или "акторы") ожидает от си-

стемы. Диаграммы прецедентов используются в методологии UML (Unified Modeling Language) для описания поведения системы и являются ключевым компонентом в процессе анализа и проектирования систем.

19

Вот основные элементы диаграммы прецедентов:

акторы: представляют пользователей или внешние системы, кото-

рые взаимодействуют с анализируемой системой. акторы изображаются в виде

человеческих фигурок;

прецеденты (use cases): описывают цели или задачи, которые ак-

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

отношения: существуют различные типы отношений на диаграмме прецедентов, такие как ассоциации (прямые связи между акторами и преце-

дентами), включения (include), расширения (extend) и обобщения

(generalization).

Диаграмма прецедентов помогает:

определить функциональность: ясно определить, что система должна делать с точки зрения пользователя;

облегчить коммуникацию: упростить общение между разработчи-

ками и заинтересованными сторонами;

поддержать планирование: обеспечить основу для планирования проекта, включая определение требований, тестирование и написание пользо-

вательской документации.

Диаграмма прецедентов является важным инструментом в ранних ста-

диях разработки системы, так как она помогает всем участникам проекта по-

нять, какие функции система должна предоставлять и как они будут использо-

ваться.

На рисунке 5 представлена диаграмма прецедентов.

20