Разработка логической модели информационной системы учета больничных листов в поликлинике
БТЭУПК (Белорусский торгово-экономический университет потребительской кооперации)
Курсовая работа (проект)
на тему: «Разработка логической модели информационной системы учета больничных листов в поликлинике»
по дисциплине: «Программное обеспечение сетей связи и языки моделирования»
2021
23.00 BYN
Разработка логической модели информационной системы учета больничных листов в поликлинике
Тип работы: Курсовая работа (проект)
Дисциплина: Программное обеспечение сетей связи и языки моделирования
Работа защищена на оценку "9" без доработок.
Уникальность свыше 40%.
Работа оформлена в соответствии с методическими указаниями учебного заведения.
Количество страниц - 22.
В работе имеется только 2 глава.
В работе также имеются диаграммы, выполненные в MS Visio Drawing.
В работе также имеется программа на языке С#.
В работе также имеются диаграммы, выполненные в MS Visio Drawing.
В работе также имеется программа на языке С#.
Поделиться
2. Разработка логической модели информационной системы с помощью UML
2.1 Моделирование и декомпозиция бизнес-процессов
2.2 Построение диаграммы вариантов использования
2.3 Построение диаграммы классов
2.4 Построение диаграммы взаимодействия
2.5 Построение диаграммы потоков данных
2.6 Построение диаграммы состояния
Список использованной литературы
2. Разработка логической модели информационной системы с помощью UML
2.1 Моделирование и декомпозиция бизнес-процессов
При создании любой информационной системы не обойтись без обследования объекта, на котором будет использоваться создаваемая система.
Специалисты по информационным технологиям при исследовании организаций часто используют соответствующие методологии, позволяющие понять работу объекта в целом путем построения его функциональной модели. В IDEF0 система представляется как совокупность взаимодействующих работ или функций.
Функциональная направленность означает, что функции системы исследуются независимо от механизмов, которые обеспечивают их выполнение. В целом такой подход направлен на изучение того, что делает исследуемая система, а не каким конкретно способом. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель [1].
Нотация IDEF0 – это достаточно строгая методика, которая изначально была разработана, как и стандарты технического конструирования, для ручного моделирования. Поэтому там содержатся требования по размещению стрелок, формату всех элементов, содержанию информационной рамки к IDEF0 диаграмме и пр. Поскольку деятельность компании – это сложная многоуровневая система действий, то схем получается всегда много, и необходима однозначная систематизация и навигация по всем элементам модели. Сейчас это делают в основном компьютерные системы, поддерживающие моделирование в данной нотации. На территории России наиболее известными и доступными на сегодня являются системы AllFusion Process Modeler и Business Studio. Обзору этих систем я планирую посвятить отдельные статьи.
2.2 Построение диаграммы вариантов использования
Процесс проектирования любой информационной системы начинается с формулирования требований к создаваемой информационной системе (что должно быть реализовано в создаваемой системе).
Эти требования обычно вырабатываются на основе анализа функционирования объекта предполагаемого внедрения информационной системы. Для наглядного представления требований к создаваемой информационной системе в последнее время используются так называемые диаграммы вариантов использования (use case).
Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой и отражает представление о поведении системы с точки зрения пользователя [2].
В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать, или целей, которые он преследует по отношению к разрабатываемой системе.
Цель построения диаграмм вариантов использования – документирование функциональных требований к системе в самом общем виде.
2.3 Построение диаграммы классов
Диаграммы классов являются центральным звеном методологии объектно-ориентированного анализа и проектирования информационных систем. Диаграммы классов содержат информацию об объектах системы и статических связях между ними, отражают декларативные знания о предметной области, оперируют понятиями класса, объекта, отношения, тем самым представляя логический аспект проекта [3].
Диаграммы классов служат для следующих целей:
- моделирования данных (анализ предметной области позволяет выявить основные характерные для нее сущности и связи между ними);
- представления архитектуры проектируемой системы (можно выделить архитектурно значимые классы и показать их на диаграммах, описывающих архитектуру);
- моделирования навигации экранов (на таких диаграммах показываются пограничные классы и их логическая взаимосвязь).
В зависимости от степени детализации используется два вида диаграмм классов:
- Диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов.
- Диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Секция имени не может быть опущена. Прочие секции могут быть пустыми или отсутствовать вовсе.
2.4 Построение диаграммы взаимодействия
Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображаются ряд объектов и те сообщения, которыми они обмениваются между собой.
В ходе проектирования ИС аналитик поэтапно спускается от общей концепции, через понимание ее логической структуры к наиболее детальным моделям, описывающим физическую реализацию.
С помощь диаграммы прецедентов (вариантов использования) выявляются основные пользователи системы и задачи, которые данная система должна решать. С помощью диаграммы деятельности мы описываем последовательность действий для каждого прецедента, необходимая для достижения поставленной цели [4].
Далее проектируется логическая структура системы с помощью диаграммы классов. На данном этапе выделяются классы, формирующие структуру БД Системы, а также классы реализующие некий набор операций, способствующий достижению целей в рамках выбранного прецедента. Для описания сложного поведения некоторых объектов (экземпляров класса) составляется диаграмма состояний.
Таким образом, аналитиками фиксируются такие поведенческие аспекты как алгоритм действий в рамках одного или нескольких прецедентов, необходимый для достижения определённого результата, а также изменение состояния объектов в ходе выполнения приведенных действий.
2.5 Построение диаграммы потоков данных
Диаграмма DFD наглядно отображает течение информации в пределах процесса или системы. Для изображения входных и выходных данных, точек хранения информации и путей ее передвижения между источниками и пунктами доставки в таких диаграммах применяются стандартные фигуры, такие как прямоугольники и круги, а также стрелки и краткие текстовые метки [5].
Диаграммы DFD варьируются от простейших набросков процессов (включая нарисованные вручную) до подробных многоуровневых схем с глубоким анализом способов обработки данных. Диаграммы DFD применяются для анализа существующих и моделирования новых систем.
В лучших традициях визуализации данных диаграммы DFD часто наглядно «рассказывают» о процессах, которые сложно объяснить словами, и позволяют эффективно донести информацию и до «физиков», и до «лириков», то есть до всех участников организации — от разработчиков до генеральных директоров. Вот почему диаграммы DFD не утратили популярности за долгие годы существования.
Однако стоит упомянуть, что хотя диаграммы DFD отлично подходят для программ и систем потоков данных, в наши дни они далеко не всегда отвечают требованиям ПО и систем, ориентированных на интерактивность, работу в реальном времени и базы данных.
Самые распространенные системы нотации DFD-схем названы в честь их создателей:
• Йордон и Коуд;
• Йордон и Де Марко;
• Гейн и Сарсон.
2.6 Построение диаграммы состояния
Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий.
Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой.
Требование клиента называется событием (event), именно такие события и вызывают переход из одного состояния в другое. Если клиент снимает деньги с открытого счета, он может перейти в состояние Превышение кредита. Это происходит, только если баланс по этому счету меньше нуля, что отражено условием на диаграмме. Заключенное в квадратных скобках ограничивающее условие (guard condition) определяет, когда может или не может произойти переход из одного состояния в другое [6].
На диаграмме имеются два специальных состояния – начальное (start) и конечное (stop). Начальное состояние выделено черной точкой, оно соответствует состоянию объекта, когда он только что был создан.
Большинство переходов должны иметь события, так как именно они заставляют переход осуществиться. Тем не менее, бывают и автоматические переходы, не имеющие событий. При этом объект сам перемещается из одного состояния в другое со скоростью, позволяющей осуществиться входным действиям, деятельности и выходным действиям. Ограничивающие условия (guard conditions) определяют, когда переход может, а когда не может осуществиться.
1. Принципы построения модели IDEF0 [Электронный ресурс]. – Режим доступа: https://it.wikireading.ru/35221.
2. Средства UML [Электронный ресурс]. – Режим доступа: https://lektsii.com/1-40164.html.
3. Диаграмма классов [Электронный ресурс]. – Режим доступа: https://bstudy.net/794536/informatika/diagramma_klassov.
4. Назначение и область применения диаграмм [Электронный ресурс]. – Режим доступа: https://studopedia.net/16_26581_naznachenie-i-oblast-primeneniya.html.
5. DFD – диаграммы потоков данных [Электронный ресурс]. – Режим доступа: https://infopedia.su/12x891b.html.
6. Диаграммы состояния [Электронный ресурс]. – Режим доступа: https://studme.org/257100/informatika/diagrammy_sostoyaniya.
Работа защищена на оценку "9" без доработок.
Уникальность свыше 40%.
Работа оформлена в соответствии с методическими указаниями учебного заведения.
Количество страниц - 22.
В работе имеется только 2 глава.
В работе также имеются диаграммы, выполненные в MS Visio Drawing.
В работе также имеется программа на языке С#.
В работе также имеются диаграммы, выполненные в MS Visio Drawing.
В работе также имеется программа на языке С#.
Не нашли нужную
готовую работу?
готовую работу?
Оставьте заявку, мы выполним индивидуальный заказ на лучших условиях
Заказ готовой работы
Заполните форму, и мы вышлем вам на e-mail инструкцию для оплаты