Файл: Курсовая работа по учебному курсу Проектирование информационных систем Разработка концептуальной и логической моделей ису.doc

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 12.12.2023

Просмотров: 152

Скачиваний: 4

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

1.3 Методологии проектирования


Автоматизированная информационная система - это совокупность информации, моделей, технических, программных, технологических средств и штата специалистов, предназначенную для обработки информации и принятия управленческих решений. Создание АИС способствует повышению эффективности производства экономического объекта и обеспечивает качество управления.

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

Жизненный цикл информационной системы можно представить, как ряд событий, происходящих с системой в процессе её создания и использования.

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

Модели жизненного цикла:



Рисунок 3. Модели жизненного цикла
1) Каскадная модель - последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.

2) Поэтапная модель с промежуточным контролем (водопадная модель). Разработка ИС ведётся итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.


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

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

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

Во время всего жизненного цикла автор будет руководствоваться стандартами:

1. ГОСТ 34.601-90 - устанавливает стадии и этапы создания автоматизированных информационных систем. Стандарт описывает содержание работ на каждом этапе. Стадии и этапы работы, закреплённые в стандарте, степени соответствуют каскадной модели жизненного цикла.

2. ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды программного обеспечения. Стандарт не содержит описания фаз, стадий и этапов.

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы жизненного цикла программного обеспечения делятся на три группы:

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

1.4 Методы проектирования


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



a. от общего к частному (нисходящее проектирование). от частного к общему (восходящее проектирования)

Нисходящее проектирование:

Метод проектирования, общее название которому «сверху-вниз». Проектирование происходит, начиная с обобщенной модели верхнего уровня описывающий только общий функционал. И на каждом последующем уровне модели, ее функциональные особенности будут уточнятся. Примером данного моделирования можно описать использования стека инструментов.

SADT (IDEF0)

UML (диаграмма прецедентов)

UML (диаграмма компонентов)

UML (диаграмма классов)

UML (диаграмма объектов)

UML (диаграмма активности)

Восходящее моделирование:

Метод моделирования «снизу-вверх». Моделирование по этому методу начинается с описания самых функций нижнего уровня, по мере повышения программа складывается из подфункций в функции, функции обретают классы, классы в свою очередь связываются между собой и обретают полноценный интерфейс. Стек инструментов в этом методе используется только UML.

UML (диаграмма активности)

UML (диаграмма классов)

UML (диаграмма объектов)

UML (диаграмма компонентов)

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

1.5 Проектирование в SADT


Метод SАDT (Struсturеd Аnаlysis аnd Dеsign Tесhniquе) технология структурного анализа и проектирования считается классическим методом функционального подхода к управлению. Главный принцип процессного подхода заключается в создании единой структуры деятельности компании в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Именно бизнес-процессы, обращающие в единую форму значимый для потребителя результат, представляют главную ценность, и именно их улучшением предстоит в дальнейшем заниматься. Модель, основанная на организационно-штатной структуре, может не всегда продемонстрировать структурированную модель. С другой стороны, модель, основанная на бизнес-процессах, содержит в себе и организационно-штатную структуру предприятия.

В соответствии с этим принципом бизнес-модель должна выглядеть следующим образом:



Рисунок 4. Принцип проектирования SADT

Метод SАDT представляет собой совокупность правил и функций, предназначенных для создание систематизированной функциональной модели объекта какой-либо предметной области. Функциональная модель SАDT отображает единую функциональную структуру объекта, т.е. производимые им действия и зависимости между этими действиями. Основные элементы этого метода основываются на следующих концепциях:

1. Графическое представление блочного моделирования.

2. Строгость и точность

3. Отделение организаций от функции, то есть исключение влияние административной структуры организации на функциональную модель.

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

Под субъектом понимается сама система, при этом необходимо точно установить, что находится внутри системы, а что лежит за ее пределами, другими словами, определить, что будет в дальнейшем рассматриваться как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будут главным образом влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна отвечать. Другими словами, в начале необходимо определить область для создания модели. Описание области как системы в целом, так и ее компонентов является главным и наиболее существенным шагом построения модели. В ходе моделирования область возможно откорректировать, но она должна быть сформулирована в основе, поскольку именно область определяет направление моделирования. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является законченной. При определении глубины системы необходимо помнить об ограничениях времени - затраты на труд при построения модели растут в геометрической прогрессии с увеличением глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему. Строится набор диаграмм, последовательно детализирующих процессы функционирования объекта управления.


Общий вид блока диаграммы, построенной согласно методологии IDEF0 (IDEF0-диаграммы, или IDEF0 - модели).



Рисунок 5. Состав функциональной модели.
Одной из наиболее значимы особенностей метода SАDT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. Каждый компонент SАDT-модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме.

Построение SАDT-модели заключается в выполнении следующих действий:

 сбор информации об объекте, определение его границ;

 определение цели и точки зрения модели;

 построение, обобщение и декомпозиция диаграмм;

 критическая оценка, рецензирование и комментирование.

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

Это верно и для интерфейсных дуг - они также соответствуют полному набору внешних интерфейсов системы в целом.

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

Данная декомпозиция выявляет полный набор подфункций, каждая из которых показана как блок, границы которого определены дугами. Каждая из этих функций может быть разбита на подфункции в целях большей детализации.

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

К функции нельзя ничего добавить лишнего, и из нее не может быть ничего удалено непосредственно входящее. Модель SАDT представляет собой серию диаграмм с документацией, поясняющей созданную модель, разбивающие сложный объект на составные части, которые изображены в виде блоков.

На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы. На SАDT-диаграммах не указаны явно последовательность и время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений.