курсовая. Курсовая работа ИСУ. Курсовая работа по учебному курсу Проектирование информационных систем Разработка концептуальной и логической моделей ису
 Скачать 1.76 Mb.
|
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-диаграммах не указаны явно последовательность и время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений. Для создания информационной системы, необходимо понять, как работает медицинский центр и как его автоматизировать. Управляющий хорошо знает работу в общем, но не может более точно знать детали каждого сотрудника. Сотрудник знает, что твориться на его рабочем месте, но может не знать, какие конкретно цели выполняют коллеги. Поэтому для описания работы медицинского центра необходимо построить модель, которая будет содержать в себе знания всех процессов участников организации. В IDEF0 реализованы три базовых принципа моделирования процессов: принцип функциональной декомпозиции; принцип ограничения сложности; принцип контекста. Принцип функциональной декомпозиции: Способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложная бизнес-функция может быть представлена в виде совокупности элементарных функций. Представляя функции графически, в виде блоков, можно как бы заглянуть внутрь блока и детально рассмотреть ее структуру и состав. Принцип ограничения сложности: При работе с IDEF0 диаграммами главным условием является их разборчивости и удобочитаемости. Главный смысл принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. Соблюдение этого правила приводит к тому, что функции, представленные в виде IDEF0, хорошо структурированы, достаточно понятны и легко анализируемы. Принцип контекстной диаграммы: Создание модели делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается единственный блок - главная бизнес-функция системы. Если речь идет о создании модели целого подразделения, главная бизнес-функция не может быть сформулирована как, например, "продавать продукцию". Главная бизнес-функция системы - это «суть» системы, ее значение в окружающем мире. Нельзя правильно сформулировать главную функцию предприятия, не имея представления о его стратегии. 1.6 Проектирование в UML В этом разделе мы рассмотрим инструменты проектирования языка UML. язык графического описания для объектного моделирования в области разработки программного обеспечения, более детального моделирования бизнес-процессов, системного проектирования и отображения организационных структур. UML является языком широкого профиля, это - открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода. диаграммы, используется в проектировании информационных систем. На основе технологии UML строится единая информационная модель. UML поддерживает этапы жизненного цикла информационной системы и для этих целей предоставляет графические средства - диаграммы. На этапе создания концептуальной модели для описания деятельности используются диаграмма прецедентов и диаграммы видов деятельности. Диаграмма прецедентов Диаграмма прецедентов (диаграмма вариантов использования) в UML - диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне. Проектируемая система представляется в виде множества сущностей или актёров, взаимодействующих с системой с помощью, так называемых прецедентов. При этом актёром (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актёром. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актёров c системой. Прецедент - возможность моделируемой системы (часть её функциональности), благодаря которой пользователь может получить конкретный, измеримый и нужный ему результат. Прецедент соответствует отдельному сервису системы, определяет один из вариантов её использования и описывает типичный способ взаимодействия пользователя с системой. Варианты использования обычно применяются для спецификации внешних требований к системе.   Диаграмма классов Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру (поля, методы…) и типы отношений (наследование, реализация интерфейсов…). На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. На этом этапе принципиально знание ООП подхода и паттернов проектирования. Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Диаграммы последовательности Взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приёма сообщений между объектами используется диаграмма последовательности. Взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя. Диаграмма кооперации На диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации. В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определённые роли во взаимодействии.  Рисунок 7. Диаграмма кооперации Диаграмма компонентов Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.  Рисунок 8. Диаграмма компонентов Диаграмма состояний Главное предназначение этой диаграммы - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.  Рисунок 9. Диаграмма состояний В этой главе было рассмотрено и проанализирована предметная область нашей информационной системы. Рассмотрены инструменты проектирования и моделирования нашей информационной системы, которые мы будем использовать для описания в графическом виде перед конечным созданием информационной системы. И было дано обоснование экономической выгоды нашего проекта. Глава 2. Моделирование информационной системы |