Файл: Задача данного проекта Процесс создание и разработки программ.docx
Добавлен: 11.12.2023
Просмотров: 99
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Глава 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. Архитектуры распределенных программных систем
Основным критерием при определении понятия распределенной автоматизированной системы (РАС) является разделение ее функций между несколькими компьютерами. При таком подходе к распределенной можно отнести любую программную систему, обработка данных в которой разделена между двумя и более компьютерами. Э. Таненбаум дает более узкое и точное определение, согласно которому распределенная система определяется как набор соединенных каналами связи независимых компьютеров, которые с точки зрения пользователя выглядят единым целым программным комплексом. В таких системах функции одного уровня программного приложения могут быть разнесены между несколькими компьютерами, и в то же время программное обеспечение, установленное на одном компьютере, может отвечать за выполнение функций, относящихся к разным уровням. Поэтому подход к определению распределенной системы, считающей ее простой совокупностью компьютеров, является достаточно условным. Для более точного описания и реализации распределенных систем используется понятие программной компоненты. Под ней понимается единица программного обеспечения, исполняемая на одном компьютере в пределах одного процесса и предоставляющая определенный набор сервисов, которые используются через внешний интерфейс другими компонентами, выполняющимися как на том же компьютере, так и на удаленных компьютерах. Совокупность компонент пользовательского интерфейса предоставляют интегрированный сервис конечному пользователю.
В практике проектирования программных систем широко применяется визуальное моделирование, которое осуществляется с использованием средств схематического или иного описания, анализа, проектирования и документирования решений по структурной организации ПО. Модели используются для того, чтобы разработчик и специалист по эксплуатации мог понять структуру и поведение программной системы, управление проектом осуществлялось максимально легко и прозрачно, с уменьшением возможных рисков. Кроме того, моделирование дает возможность документировать принимаемые проектные решения и служит основой взаимодействия между участниками проекта, что способствует созданию качественного ПО. Документация по программной архитектуре представлена набором графических средств и нотаций представления моделей системы и их описанием. В описании указывается, из каких подсистем состоит система, из каких модулей формируется каждая подсистема. Графические схемы позволяют оценить структуру системы с разных сторон. Модель системной архитектуры является основой для создания спецификации системных компонентов, причем при ее проектировании разрабатывается базовая структура, т. е. определяются основные элементы системы и взаимодействия между ними. Процесс моделирования может быть разделен на несколько этапов: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования. Принятие решений по системной организации программной системы представляет собой многогранный, плохо формализованный и сложный процесс, в ходе которого широко используются системные исследования и анализ с использованием моделирования различных аспектов проектирования. При этом может использоваться широкий спектр методологий системного анализа и моделирования. К наиболее продуктивным из них следует отнести методологию структурного анализа и моделирования 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. Архитектуры распределенных программных систем
Основным критерием при определении понятия распределенной автоматизированной системы (РАС) является разделение ее функций между несколькими компьютерами. При таком подходе к распределенной можно отнести любую программную систему, обработка данных в которой разделена между двумя и более компьютерами. Э. Таненбаум дает более узкое и точное определение, согласно которому распределенная система определяется как набор соединенных каналами связи независимых компьютеров, которые с точки зрения пользователя выглядят единым целым программным комплексом. В таких системах функции одного уровня программного приложения могут быть разнесены между несколькими компьютерами, и в то же время программное обеспечение, установленное на одном компьютере, может отвечать за выполнение функций, относящихся к разным уровням. Поэтому подход к определению распределенной системы, считающей ее простой совокупностью компьютеров, является достаточно условным. Для более точного описания и реализации распределенных систем используется понятие программной компоненты. Под ней понимается единица программного обеспечения, исполняемая на одном компьютере в пределах одного процесса и предоставляющая определенный набор сервисов, которые используются через внешний интерфейс другими компонентами, выполняющимися как на том же компьютере, так и на удаленных компьютерах. Совокупность компонент пользовательского интерфейса предоставляют интегрированный сервис конечному пользователю.