Структурный анализ в проектировании информационных систем

Системное проектирование

Этапы построения системы

Процесс построения системы включает шесть этапов:

  1. системный анализ;
  2. системное программирование, включающее определение существующих целей: составление планов работы и графиков;
  3. системное проектирование — это реальное проектирование системы, ее компонентов и подсистем для получения оптимальной эффективности;
  4. разработка программ математического обеспечения;
  5. ввод системы в действие, ее проверка;
  6. обслуживание созданной системы.

Организация, которая представляет собой организованное целое в наиболее общей абстрактной форме, выступает предельным расширением каждой системы. Определение «организация» как регламентированное состояние целого равняется понятию «система». Определением, противоположным «системе», является определение «несистема».

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

Системный анализ и его методология

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

В системном анализе могут быть выделены следующие элементы:

  • методология;
  • аппаратная реализация;
  • приложения применимые на практике.

Методология состоит из определений применяемых понятий и принципов системного подхода. В системном анализе можно выделить следующие основные определения:

  1. Элемент — некий объект (информационный, материальный, энергетический), обладающий важными для человека свойствами, но внутренняя структура которого не зависит от цели, с которой его изучают.
  2. Связь – нужный для изучения обмен среди элементов информацией, веществом, энергией.
  3. Система – набор элементов, обладающий следующим набором признаков:

    • Связями, позволяющими с помощью проходов по ним от одного элемента к другому, объединить любые элементы совокупности;
    • Свойствами, отличными от свойств каждого элемента совокупности.

Статья: Методология системного анализа

Найди решение своей задачи среди 1 000 000 ответов

Каждый объект, при рассмотрении его в определённой плоскости, может рассматриваться в качестве системы. Но остаётся открытым вопрос, всегда ли это необходимо использовать. Большая система — это такая, которая состоит из большого числа единообразных частей и типовых связей между ними. Ярким примером является трубопровод. Его элементами являются промежутки между опорами или соединительными швами. Чтобы рассчитать прочность методом конечных элементов, надо считать элементами системы маленькие участки труб. Связи между элементами носят силовой (энергетический) характер, поскольку любой элемент воздействует на соседние.

Сложная система –это система, состоящая из элементов различных типов и обладающая разнообразными связями между элементами. Примером может служить электронная вычислительная машина (ЭВМ), лесопогрузчик или корабль.

Автоматизированная система – это сложная система, в которой главную роль играют элементы следующих типов:

  • различные технические средства;
  • практические действия человека.

Замечание 1

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

Структура систем

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

Определение 1

Определение декомпозиции может быть следующим: подразделение системы на составные части, которое даёт возможность выполнять различные операции с данной системой. Например, деление объекта на части, которые могут быть спроектированы отдельно

Иерархическая структура –это структура, в которой есть подчинённость, то есть связи между отдельными элементами имеют разные права. Т.е., например, действие в одну сторону(направление) влияет на элемент существенно сильнее, чем в обратном направлении.

Замечание 2

Типы структур, основанных на иерархии, достаточно многообразны, но на практике в основном применяются две: это древовидные структуры и ромбовидные.

Древовидная структура самая простая для практической реализации и анализа. И в ней просто выделить уровни иерархии, т.е. наборы элементов, которые находятся на равном расстоянии от основного (верхнего) компонента. Например, древовидную структуру имеет процесс создания технологического объекта по его главным характеристикам посредством выполнения проектов его составных частей, набора агрегатов, различных более мелких систем, опускаясь до реализации необходимых деталей.

Принципы системного подхода

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

  1. Главенство основной цели.
  2. Анализ и проектирование системы как единого целого объекта и как набора отдельных элементов.
  3. Связность элементов: все части анализируются вместе с их связями с другими элементами.
  4. Модульность проектирования: очень эффективна разбивка системы на модули и анализ её как набор модулей.
  5. Иерархический принцип: необходимо построить все элементы согласно их рангам.
  6. Функциональный принцип: структура и функции системы анализируются совместно, но приоритет имеют именно функции.
  7. Эволюционный принцип: учитывается способность системы изменяться, её развитие, расширение.
  8. Децентрализация: при принятии решений сочетаются принципы центрального управления и децентрализации.
  9. Необходимо учитывать различные неопределённости и случайности в системе.

Применение структурного анализа при проектировании информационных систем

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

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

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

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

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

Системный подход к проектированию информационных систем предполагает исследование, рассмотрение, описание выбранного объекта в полном объеме при учете его главных свойств. Основная цель такого подхода состоит в соблюдении следующих исходных принципов:

  1. Реализация всесторонней и целостной оценки динамических характеристик объектов, их взаимных связей с окружающей средой.
  2. Осуществление учета вероятных внешних и внутренних неблагоприятных условий, способных вывести объект из равновесного состояния.

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

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

Процессный подход

Цель и принципы подхода

  1. Обеспечения строгого подхода к принятию решений, разрешения конфликта требований, и оценке альтернативных физических решений (отдельных элементов и всей архитектуры);
  2. Определения уровня удовлетворения требований;
  3. Поддержки управления рисками;
  4. Подтверждения, что решения принимаются только после расчета затрат, сроков, производительности и влияния рисков на проектирование или перепроектирование системы.
  • Процессы описания требований стейкхолдеров и описания требований системы используют системный анализ для решения конфликтов между требованиями; в частности связанными с затратами, техническими рисками и эффективностью. Системные требования, подверженные высоким рискам или требующие существенных изменений архитектуры – дополнительно обсуждаются.
  • Процессы разработки логической и физической архитектуры используют системный анализ для оценки характеристик или разработки свойств вариантов архитектуры, получения обоснования для выбора наиболее эффективного варианта с точки зрения затрат, технических рисков и эффективности.

Задачи в рамках процесса

Планирование изучения альтернатив:Определение количества альтернативных вариантов для анализа, используемых методов и процедур, ожидаемых результатов (примеры объектов для выбора: поведенческий сценарий, физическая архитектура, элемент системы и т.д.), и обоснование.
Создание графика анализа согласно наличию моделей, технических данных (системные требования, описание свойств системы), квалификации персонала и выбранных процедур.

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

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

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

Артефакты и терминология процесса

  • Модель критериев выбора (список, шкалы оценки, веса);
  • Отчеты по анализу затрат, рисков, эффективности;
  • Отчет с обоснованием выбора.
Термин Описание
Критерий оценки В контексте системного анализа, критерий оценки – характеристика, используемая для сравнения элементов системы, физической архитектуры, функциональных сценариев и других элементов, которые могут сравниваться.Включает: идентификатор, название, описание, вес.
Оценочный выбор Управление элементами системы, на основе оценочного балла, который объясняет выбор элементов системы, физической архитектуры или сценария использования.
Оценочный балл (оценка) Оценочный балл получают элементы системы, физической архитектуры, функциональных сценариев используя набор критериев оценки. Включает: идентификатор, название, описание, значение.
Затраты Значение в выбранной валюте, связанное со значением элемента системы и т.д.Включает: идентификатор, название, описание, сумма, тип затрат (разработка, производство, использование, обслуживание, утилизация), метод оценки, период действия.
Риск Событие, которое может произойти и повлиять на цели системы или ее отдельные характеристики (технические риски). Включает: идентификатор, название, описание, статус.

Проверка правильности системного анализа

  • Соответствие моделей и данных в контексте использования системы;
  • Соответствие критериев оценки относительно контекста использования системы;
  • Воспроизводимость результатов моделирования и расчетов;
  • Достаточный уровень точности шкал сравнения;
  • Доверие к оценкам;
  • Достаточный уровень чувствительности полученных баллов относительно весов критериев оценки.

Некоторые принципы проверки качества и полноты информационной модели

(источник – Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

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

Регулярно представляйте вашу информационную модель или ее отдельные фрагменты, относительно которых у вас возникают сомнения, на одобрение пользователей

Особое внимание уделяйте исключениям из правил и ограничениям

Качество сущностей

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

Список проверочных вопросов для сущности:

  • Отражает ли имя сущности суть данного объекта?
  • Нет ли пересечения с другими сущностями?
  • Имеются ли хотя бы два атрибута?
  • Всего атрибутов не более восьми?
  • Есть ли синонимы/омонимы данной сущности?
  • Сущность определена полностью?
  • Есть ли уникальный идентификатор?
  • Имеется ли хотя бы одна связь?
  • Существует ли хотя бы одна функция по созданию, поиску, корректировке, удалению, архивированию и использованию значения сущности?
  • Ведется ли история изменений?
  • Имеет ли место соответствие принципам нормализации данных?
  • Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?
  • Не имеет ли сущность слишком общий смысл?
  • Достаточен ли уровень обобщения, воплощенный в ней?

Список проверочных вопросов для подтипа:

  • Отсутствуют ли пересечения с другими подтипами?
  • Имеет ли подтип какие-нибудь атрибуты и/или связи?
  • Имеют ли они все свои собственные уникальные идентификаторы или наследуют один на всех от супертипа?
  • Имеется ли исчерпывающий набор подтипов?
  • Не является ли подтип примером вхождения сущности?
  • Знаете ли вы какие-нибудь атрибуты, связи и условия, отличающие данный подтип от других?

Качество атрибутов

Следует выяснить, а действительно ли это атрибуты, то есть, описывают ли они тем или иным образом данную сущность.

Список проверочных вопросов для атрибута:

  • Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?
  • Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?
  • Имеет ли атрибут только одно значение в каждый момент времени?
  • Отсутствуют ли повторяющиеся значения (или группы)?
  • Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?
  • Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?
  • Не может ли он быть пропущенной связью?
  • Нет ли где-нибудь ссылки на атрибут как на “особенность проекта”, которая при переходе на прикладной уровень должна исчезнуть?
  • Есть ли необходимость в истории изменений?
  • Зависит ли его значение только от данной сущности?
  • Если значение атрибута является обязательным, всегда ли оно известно?
  • Есть ли необходимость в создании домена для этого и ему подобных атрибутов?
  • Зависит ли его значение только от какой-то части уникального идентификатора?
  • Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

Качество связи

Нужно выяснить, отражают ли связи действительно важные отношения, наблюдаемые между сущностями.

Список проверочных вопросов для связи:

  • Имеется ли ее описание для каждой участвующей стороны, точно ли оно отражает содержание связи и вписывается ли в принятый синтаксис?
  • Участвуют ли в ней только две стороны?

Не является ли связь переносимой?

  • Заданы ли степень связи и обязательность для каждой стороны?
  • Допустима ли конструкция связи?

Не относится ли конструкция связи к редко используемым?

  • Не является ли она избыточной?
  • Не изменяется ли она с течением времени?
  • Если связь обязательная, всегда ли она отражает отношение к сущности, представляющей противоположную сторону?

Для исключающей связи:

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

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

В основе методологии проектирования информационных систем лежат принципы создания их. Главный принцип построения различных систем – принцип иерархической декомпозиции обусловливает следующие виды методологий:

  •  структурно-функциональная методология, в основу которой положен принцип функциональной декомпозиции, когда структура информационной системы описывается в терминах иерархии ее функций(процессов, работ) и передачи информации между отдельными функциональными элементами;
  • объектно-ориентированная методология основана на принципе объектной декомпозиции, а структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами:
  • методология построения интегрированных информационных систем (Architecture of Integrated Information Systems, ARIS), которая основывается на концепции интеграции, предлагающей целостный взгляд на автоматизируемые бизнес-процессы, и представляет собой множество различных методологий, интегрированных в рамках единого системного подхода;
  • методология синергетического проектирования информационных систем, основанная на принципах синергетики, как науке о не равновесных процессах(управляемый хаос и т.п.).

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

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

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

К преимуществам  методологии ARIS разработчики относят следующие:

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

— богатство методов, позволяет моделировать широкий спектр систем; -все модели и объекты создаются и хранятся в единой базе проекта, что обеспечивает построение интегрированной и целостной модели предметной области.

Что такое системный дизайн?

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

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

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

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

Системный анализ и проектирование системы являются ключевыми этапами SDLC.

Практические рекомендации

Подводные камни

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

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

Оцените статью