Дипломная работа 50% (2023) (1). Задача данного проекта Процесс создание и разработки программ
 Скачать 1.38 Mb.
|
|
Глава 3. Моделирование Программных систем В практике проектирования программных систем широко применяется визуальное моделирование, которое осуществляется с использованием средств схематического или иного описания, анализа, проектирования и документирования решений по структурной организации ПО. Модели используются для того, чтобы разработчик и специалист по эксплуатации мог понять структуру и поведение программной системы, управление проектом осуществлялось максимально легко и прозрачно, с уменьшением возможных рисков. Кроме того, моделирование дает возможность документировать принимаемые проектные решения и служит основой взаимодействия между участниками проекта, что способствует созданию качественного ПО. Документация по программной архитектуре представлена набором графических средств и нотаций представления моделей системы и их описанием. В описании указывается, из каких подсистем состоит система, из каких модулей формируется каждая подсистема. Графические схемы позволяют оценить структуру системы с разных сторон. Модель системной архитектуры является основой для создания спецификации системных компонентов, причем при ее проектировании разрабатывается базовая структура, т. е. определяются основные элементы системы и взаимодействия между ними. Процесс моделирования может быть разделен на несколько этапов: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования. Принятие решений по системной организации программной системы представляет собой многогранный, плохо формализованный и сложный процесс, в ходе которого широко используются системные исследования и анализ с использованием моделирования различных аспектов проектирования. При этом может использоваться широкий спектр методологий системного анализа и моделирования. К наиболее продуктивным из них следует отнести методологию структурного анализа и моделирования SADT. Она интегрирует процессы моделирования и управления конфигурациями проекта с использованием дополнительных языковых средств логической систематизации структуры и поведения, а также эффективной визуализации программных систем. 28 Основные правила формирования и визуализации структурных моделей базируются на методологии IDEF, которая предназначена для решения задач моделирования, отображения и анализа деятельностей разнообразных сложных систем в различных разрезах. Глубина и объем обследования процессов определяются самим разработчиком, что позволяет оптимизировать создаваемую модель, не перегружая ее излишними данными. В настоящее время данная методология содержит 15 стандартов (от IDEF 0 до IDEF 14), используемых для создания различных видов представления сложных систем при проведении структурного анализа. В целом SADT представляет собой совокупность методов, правил и процедур, используемых для построения структурной модели объекта автоматизации. Модели SADT отображают функциональную, процессную или информационную структуры объекта, включая производимые элементами системы действия и связи между этими действиями. Основными концепциями методологии структурного анализа и проектирования являются: − графическое представление структурных блоков модели, при этом графика диаграммы представляет функцию в виде прямоугольного блока, а интерфейсы входа/выхода изображаются дугами, входящими в блок и выходящими из него − строгость и точность, предполагающие выполнение формальных условий SADT. При создании SADT-диаграммы нужно руководствоваться следующими правилами: − ограничение количества блоков на каждом уровне декомпозиции (правило 3–6 блоков). − связность диаграмм с помощью нумерации блоков; − уникальность наименований (отсутствие повторяющихся названий) − формальность синтаксических правил для графики блоков и дуг; − разделение входов и управлений для определения роли данных − исключение влияния организационной структуры на функциональную модель. Эта методология предназначена для моделирования широкого круга систем, а также определения требований и функций, которые затем являются основой для проектирования. Для уже существующих систем методология используется с целью структурного анализа функций, выполняемых системой, и указания механизмов, посредством которых они осуществляются. 3.1 Архитектура программной системы Под архитектурой программной системы понимается совокупность основополагающих решений по структурной организации программной системы. Она включает в себя: − выбор структурных элементов и их интерфейсов, с помощью которых обеспечивается их взаимодействие и совместное функционирование − соединение выбранных элементов структуры и поведения во всё более крупные системы − архитектурный стиль, который направляет всю организацию – все элементы, их интерфейсы, их сотрудничество и их соединение. Архитектурное проектирование является начальным этапом процесса проектирования, когда определяются основные подсистемы, процессы и структура управления и взаимодействия. Его результатом должно стать формирование структуры программного обеспечения. Архитектурный вид состоит из двух основных компонентов: структурных элементов и отношений между ними. При этом схематически архитектура может быть представлена в логическом или физическом виде. Если структурные элементы представляют собой концептуальные (логические) компоненты ПО, такие как прецеденты, классы, процессы, состояния и др., то такая модель программной архитектуры будет соответствовать логической. Физическая же архитектура будет являться реализацией логической структуры ПС, когда ее элементами станут физически существующие компоненты, такие как программы, базы и файлы данных, интерфейсы. На рис. 4 приведен пример логической структурной схемы программной архитектуры на примере системы управления эффективностью деятельности организации (ЕРМ-система). На рис. 5 представлена физическая модель программной архитектуры WEB-системы.   Модели архитектуры определяются и рядом нефункциональных системных требований, к которым следует отнести следующие. 1.Производительность. Требование высокой производительности системы предполагает такую архитектуру, где за все критические операции отвечало бы минимальное число подсистем с ограниченным взаимодействием между ними. В таких случаях лучше использовать компоненты в виде крупных модулей, а не мелкие структурные элементы. 2.Защищенность, для обеспечения которой требуется архитектура с многоуровневой структурой, где наиболее критические системные элементы защищены на внутренних уровнях, а проверка их безопасности осуществляется на более высоком уровне. 3.Безопасность, для обеспечения которой архитектуру следует спроектировать так, чтобы при этом за операции, влияющие на безопасность системы, должно отвечать как можно меньше подсистем. 4.Надежность, повысить которую можно путем разработки архитектуры с включением избыточных компонентов, которые можно было бы заменять и обновлять, не останавливая общее функционирование системы. 5.Удобство сопровождения предполагает, что системная архитектура системы должна основываться на уровне мелких структурных компонентов, которые можно легко заменять и модифицировать. Программные модули, создающие данные, необходимо отделить от модулей, их использующих. Кроме того, нужно избегать структур совместного использования данных. 3.2 Структурное моделирование процессов На первом этапе разработки программной архитектуры система разбивается на несколько взаимодействующих подсистем. На абстрактном уровне это показывается графически с помощью структурной схемы, в которой подсистемы представлены отдельными блоками. Стрелками, связывающими блоки, обозначаются потоки данных или потоки управления. Характерными представителями методов визуализации структурных моделей системы являются такие методологии структурного анализа 33 SADT, как функциональное моделирование IDEF0 и моделирование потоков данных DFD. В подходах IDEF0 структурной единицей системы является функциональный блок, выполняющий некоторое преобразование и связанный с внешним окружением и другими функциональными блоками интерфейсами (рис. 6).  Каждый функциональный блок в методологии IDEF0 может быть подвергнут декомпозиции, результатом которой является представление этого блока новой диаграммой, состоящей из функциональных блоков нижнего уровня структурной иерархии. Диаграммы потоков данных (DFD) используются в качестве основного средства моделирования функциональных требований к системной архитектуре. С их помощью структурные элементы разбиваются на процессы (поведенческие компоненты) и представляются в виде связанной потоками данных сети. 3.3 Структурное моделирование информации Большинство информационных хранилищ используют технологию реляционных баз данных, поскольку она предлагает надежные, проверенные и эффективные средства хранения и управления большими объемами данных. Важнейшим вопросом, связанным с конструированием хранилищ данных, является структура базы данных как логическая, так и физическая. Создание логической схемы информационной базы требует всеобъемлющего моделирования автоматизируемой деятельности. Цель моделирования данных состоит в обеспечении разработчика ПС концептуальной схемой БД в виде одной или нескольких локальных моделей, которые относительно легко преобразуются в систему информационных баз. Самым известным и популярным средством моделирования данных являются диаграммы «сущность – связь» (ERD), позволяющие осуществить детализацию накопителей данных в моделях потоков данных, а также документировать информационные аспекты автоматизированной системы, важные для предметной области объекты (сущности), их свойства (атрибуты) и связи с другими объектами (отношения). Сущность (Entity) характеризует множество однотипных экземпляров реальных или абстрактных объектов (людей, событий, состояний, предметов), обладающих общими атрибутами или характеристиками. Любой информационный объект может быть представлен одной сущностью, при этом имя которой должно отражать тип объекта, а не его конкретный экземпляр. Сущность должна обладать уникальным идентификатором, который и используется для однозначной идентификации экземпляра данного типа сущности. Сущность должна обладать следующими свойствами: − иметь уникальное имя; − иметь один или несколько атрибутов, которые могут принадлежат сущности или наследоваться через связь − иметь один или несколько атрибутов, однозначно идентифицирующих каждый экземпляр. Сущность может иметь произвольное количество связей с другими сущностями. Связью (Relationship) называется поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Атрибутом (Attribute) является любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут – это тип характеристики или свойства, ассоциированных с множеством реальных или абстрактных объектов. Среди методов визуализации моделей данных путем построения ER диаграмм наиболее популярными методами являются метод Баркера и метод IDEF1X, входящий в методологию SADT. Рассмотрим основные особенности решения этой задачи на примере последней. IDEF1X является методом разработки реляционных БД и использует условную нотацию, специально разработанную для удобного построения концептуальной схемы, которая называется универсальное представление структуры данных, независимое от конечной реализации БД и аппаратной платформы. Пример диаграммы «сущность – связь» представлен на рис. 7 моделью информационной базы системы учета заказов по обслуживанию компьютерной техники.  Создание модели данных начинается с разработки логической модели, после чего проектировщик может выбрать необходимую СУБД и создать соответствующую физическую модель Глава 4. Архитектуры распределенных программных систем Основным критерием при определении понятия распределенной автоматизированной системы (РАС) является разделение ее функций между несколькими компьютерами. При таком подходе к распределенной можно отнести любую программную систему, обработка данных в которой разделена между двумя и более компьютерами. Э. Таненбаум дает более узкое и точное определение, согласно которому распределенная система определяется как набор соединенных каналами связи независимых компьютеров, которые с точки зрения пользователя выглядят единым целым программным комплексом. В таких системах функции одного уровня программного приложения могут быть разнесены между несколькими компьютерами, и в то же время программное обеспечение, установленное на одном компьютере, может отвечать за выполнение функций, относящихся к разным уровням. Поэтому подход к определению распределенной системы, считающей ее простой совокупностью компьютеров, является достаточно условным. Для более точного описания и реализации распределенных систем используется понятие программной компоненты. Под ней понимается единица программного обеспечения, исполняемая на одном компьютере в пределах одного процесса и предоставляющая определенный набор сервисов, которые используются через внешний интерфейс другими компонентами, выполняющимися как на том же компьютере, так и на удаленных компьютерах. Совокупность компонент пользовательского интерфейса предоставляют интегрированный сервис конечному пользователю. 4.1 Характеристики современных распределение систем Чтобы достигнуть основной цели своего функционирования – обеспечения эффективного выполнения запросов пользователя – распределенная система должна удовлетворять ряду необходимых требований, который можно представить приведенным нижеследующим набором характеристик 1. Открытость. Внутри РАС все протоколы взаимодействия компонентов в идеале должны быть основаны на общедоступных стандартах, что позволяет использовать для их создания универсальные средства разработки и операционные системы. При этом каждый компонент должен содержать точную и полную спецификацию своих сервисов. 2.Масштабируемость. Наиболее важный аспект этой характеристики состоит в потенциальной возможности добавления в РАС новых компонентов и компьютеров для увеличения производительности системы и обеспечения балансировки нагрузки на серверы системы. К масштабированию относят также обеспечение эффективного распределения ресурсов сервера, обслуживающего запросы клиентов. 3.Поддержание логической целостности данных. Данное свойство предполагает, что запрос пользователя в распределенной системе должен корректно выполняться целиком или не выполняться вообще. Должны быть исключены ситуации, когда часть компонентов системы корректно обработали поступивший запрос, а часть – нет. 4.Устойчивость. Под этой характеристикой понимается возможность автоматического перераспределения функций внутри системы при выходе из строя одного из узлов, что обеспечивается дублированием несколькими компьютерами одних и тех же функций. В идеале это означает практически полное отсутствие ситуации, когда выход из строя одного любого компьютера приводило бы к невозможности обслужить пользовательский запрос. 5. Безопасность. Данные, передаваемые между компонентами, должны быть защищены как от искажения, так и от просмотра третьими сторонами, а функции системы должны использоваться авторизированными на это компонентами или пользователями. 6.Эффективность. Под свойством понимается минимизация накладных расходов, связанных с распределенным характером системы. Эффективность может противоречить безопасности, открытости и надежности системы, поэтому требование эффективности обычно является наименее приоритетным. Так, на поддержку логической целостности данных в распределенной системе можно потратить значительные ресурсы времени и памяти, но система с недостоверными данными вряд ли вообще будет нужна пользователям. 4.2 Проблемы проектирование распределенных систем 1. Сложность. РАС имеют более сложную организацию по сравнению с централизованными системами, что обусловливает определенные трудности при понимании, оценивании и тестировании их свойств. В частности, производительность системы зависит не от скорости работы отдельного процессора, а от полосы пропускания сети и совокупной скорости обработки информации разными процессорами. На производительность системы может радикально повлиять перемещение ресурсов из одной части в другую. 2.Безопасность. Поскольку доступ к системе можно получить с разных компьютеров системы, то сообщения в сети могут просматриваться и перехватываться. Поэтому в РАС намного сложнее поддерживать информационную безопасность. 3.Управляемость. Так как система может состоять из разнотипных компьютеров с разными версиями операционных систем, то ошибки, возникшие на одной машине, могут распространиться на другие с непредсказуемыми последствиями. Поэтому для того, чтобы управлять и поддерживать систему в рабочем состоянии, требуется значительно больше усилий. 4. Непредсказуемость. При возникновении различных событий реакция РАС может быть непредсказуемой, так как она зависит и от полной загрузки системы, и от ее организации и сетевой нагрузки. Причем эти параметры могут периодически изменяться, поэтому и время, потраченное на выполнение запроса пользователя, может существенно различаться. Перечисленные трудности вызывают и соответствующие проблемы проектирования РАС, которые можно разделить на следующие группы. 1.Идентификация ресурсов. Так как ресурсы распределенной системы размещаются на разных компьютерах, то систему имен ресурсов следует продумать так, чтобы пользователи без труда открывали и ссылались на необходимые им ресурсы. Примером является система унифицированного указателя ресурсов URL, которая определяет адреса WEB-страниц. Если не иметь легко воспринимаемую и универсальную систему идентификации, то большая часть ресурсов окажется недоступной. 2.Коммуникации. Наиболее эффективным способом организации взаимодействия между компьютерами для большинства распределенных систем является Internet и реализация протоколов ТСР/IP. Однако в случаях, когда на производительность, надежность и другие характеристик накладываются специальные требования, можно воспользоваться и другими, альтернативными способами системных коммуникаций. 3.Качество системного сервиса. Под ним обычно понимается производительность, работоспособность и надежность сервиса, предлагаемого системой. Качество сервиса в РАС определяется целым рядом дополнительных факторов, таких как распределение системных процессов, системные и аппаратные средства, возможности адаптации системы. 4.Архитектура ПО РАС. Определяет распределение системных функций по компонентам системы, а также развертывание этих компонентов по процессорам. Для поддержки высокого качества системного сервиса выбор правильной архитектуры может оказаться решающим фактором. 4.3 Основные типы архитектур РАС Архитектура РАС строится на основании принципов разделения, которые можно разделить на два типа: функциональное и естественное. Функциональное разделение основывается на выделении специфичных задач, решаемых узлами, например клиент – сервер, хост – терминал, сборка данных – обработка данных – предоставление данных. При естественном разделении учитываются требования, определяемые структурой самой задачи автоматизации, например обслуживание сети супермаркетов, сеть для поддержки коллективной работы и др. Основными мотивами разделения являются: 1) обмен информацией между системами, при котором распределение нагрузки и балансировку загрузкой процессоров системы стремятся осуществлять так, чтобы оптимизировать общую загрузку системы; 2) усиление мощности, когда различные узлы должны работать над одной задачей так, чтобы система, содержащая набор процессоров, по мощности могла приближаться к суперкомпьютеру; 3) физический мотив, при котором система строится в предположении, что узлы физически разделены исходя из требования к надежности и устойчивости к сбоям 4) экономические мотивы, так как набор дешевых чипов может обеспечить лучшие показатели отношения цена/производительность, чем мэйнфрэйм 5) специализация компонентов, при которой происходит их упрощение и удешевление − архитектура клиент – сервер как модель, представленная набором системных сервисов, которые предоставляются серверами клиентам, при этом по назначению и характеру использования серверы и клиенты значительно отличаются друг от друга; − архитектура распределенных объектов как модель, в которой между серверами и клиентами не делается никаких различий, такая система представляется как набор взаимодействующих объектов, место расположения которых не имеет особого значения. РАС проектируются на основе объектно-ориентированного подхода, конструируются из слабо интегрированных частей, каждая из которых может непосредственно взаимодействовать как с пользователем, так и с другими частями системы. Такие компоненты должны по возможности реагировать и на независимые события. Программные компоненты, разработанные на основе таких принципов, являются естественными частями РАС. Архитектура распределенных объектов представляется наиболее общим и универсальным подходом в проектировании РАС, при котором различия между клиентом и сервером стираются. Компонентами такой системы являются объекты, реализующие сервисы. При этом не делается различий между клиентом (пользователем сервиса) и сервером (поставщиком сервиса). 4.5 Технологии проектирование РАС В инфраструктуру системной поддержки проектирования РАС входят: − язык описания интерфейсов − транслятор с этого языка − библиотеки, реализующие функциональность, необходимую для удаленного вызова процедуры. Часть ее используется при разработке программ, использующих удаленный вызов процедур, другая часть необходима для реализации во время выполнения такого вызова. Аналогично работают и другие виды взаимодействия распределенных компонентов. Системная поддержка РАС может иметь следующие формы организации системного взаимодействия. 1. Системы на базе удаленного вызова процедур. Являются наиболее общим способом системного взаимодействия. Они содержат программы для прозрачного преобразования обычных вызовов процедур в удаленные. Такие системы лежат в основе почти всех других форм системного программного обеспечения, включая сетевые службы. 2. Транзакционные мониторы, которые относятся к наиболее надежной и стабильной технологии интеграции прикладных распределенных систем. Они могут рассматриваться как системы удаленного вызова процедур с транзакционными расширениями. 3. Брокеры объектов. Появились в результате применения объектноориентированного подхода к системам на базе систем удаленного вызова. Такие системы более развиты, чем системы удаленного вызова, хотя и мало от них отличаются. Наиболее распространены брокеры объектов, построенные на основе подхода CORBA, предложенного группой OMG при том, что основная часть их функциональности уже была реализована в транзакционных мониторах. Они были переведены на объектно-ориентированные языки программирования. В настоящее время на смену технологии CORBA пришли стандартизованные протоколы WEB-сервисов, такие как XML, WSDL, SOAP и др. |