Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы

Содержание:

ВВЕДЕНИЕ

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

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

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

Объектом исследования является работа обувной мастерской.

Предмет исследования – процесс проектирования информационной системы.

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

При написании данной работы нами использовались такие методы как: моделирование, сравнение и измерение.

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

ГЛАВА 1. Анализ структурных функциональных методов проектирования информационной системы и программного обеспечения, наглядно представляющий структуру ИС

1.1. Структурные методы анализа и проектирования ИС

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

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

Таким образом, первым шагом упрощения сложной системы является ее разбиение на «черные ящики», при этом такое разби­ение должно удовлетворять следующим критериям:

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

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

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

Структурным анализом принято называть метод исследова­ния системы, начинающий с ее общего обзора, который затем де­тализируется, приобретая иерархическую структуру со все боль­шим числом уровней. Для таких методов характерно:

• разбиение системы на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6—7);
• ограниченный контекст, включающий лишь существенные на каждом уровне детали;
• использование строгих формальных правил записи;
• последовательное приближение к конечному результату.

Все наиболее распространенные методы структурного подхо­да базируются на ряде общих принципов. Принципами структурного подхо­да являются:

• принцип «разделяй и властвуй» — принцип решения трудных проблем путем разбиения их на множество меньших неза­висимых задач, легких для понимания и решения;
• принцип иерархического упорядочения — принцип организа­ции составных частей системы в иерархические древовид­ные структуры с добавлением новых деталей на каждом уровне.
• принцип абстрагирования — выделение существенных аспек­тов системы и отвлечение от несущественных;
• принцип формализации – применение строго методического подхода к решению проблемы;
• принцип упрятывания – упрятывание несущественной на конкретном этапе информации: каждая часть «знает» только необходимую ей информацию;
• принцип концептуальной общности – следование единой философии на всех этапах ЖЦ (структурный анализ – структурное проектирование – структурное программирование – структурное тестирование);
• принцип полноты – контроль за присутствием лишних элементов
• принцип непротиворечивости — обоснованность и согласованность элементов системы;
• принцип логической независимости – концентрация внимания на логическом проектировании для обеспечения независимости от физического проектирования;
• принцип независимости данных – модели должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения;
• принцип структурирования данных — данные должны быть структурированы и иерархически организованы;
• принцип доступа конечного пользователя – пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).

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

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

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

В структурном анализе и проектировании используются раз­личные модели, описывающие:

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

Модель — это совокупность символов (математических, графических и т.п.), которая адекватно описывает некоторые свойства моделируемого объекта и отношения между ними.

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

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

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

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

Нотации — система условных обозначений, принятая в конкретной модели.

Средства — аппаратное и программное обеспечение, реализующее выбранную методологию, в том числе построение соответствующих моделей с принятой для них нотацией. [5]

1.2. Анализ средств, предусмотренных для проведения структурного анализа

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

• DFD (Data Flow Diagrams);
• STD (State Transition Diagrams);
• ERD (Entity-Relationship Diagrams);
• структурные карты Джексона и/или Константайна;
• FDD (Functional Decomposition Diagrams);
• SADT (Structured Analysis and Design Technique);
• семейство IDEF (Integration Definition for Function Modeling).

Современные структурные методологии анализа и проектирования классифицируются по следующим признакам:

• по отношению к школам – Software Еngineering (SE) и Information Engineering (IЕ);
• по порядку построения модели – процедурно-ориентированные, ориентированные на данные и информационно-ориентированные;
• по типу целевых систем – для систем реального времени (СРВ) и для информационных систем (ИС).
• Рассмотрим подробнее каждое средство структурного анализа:
• DFD (Data Flow Diagrams) — диаграммы потоков данных в нотациях Гейна-Сарсона, Йордона-Де Марко и других, обеспечивающие требования анализа и функционального проектирования информационных систем;

Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Итак, DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных, то есть используется разработчиками ИС для разработчиков ИС. DFD должна наглядно ответить на вопросы: из чего состоит ИС и что нужно, чтобы обработать информацию?

Зачем нужна нотация DFD? Исторически синтаксис этой нотации применяется в двух вариантах — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Различия между ними – в таблице 1:

Таблица 1. Сходства и отличия между синтаксисом
нотаций Yourdon и Gane-Sarson.

	Yourdon	Gane-Sarson
Внешняя сущность
Процесс
Хранилище данных
Поток данных

Непосредственно DFD нотация состоит из следующих элементов:

1. Процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми.

2. Внешние сущности (англ. External Entity). Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какиелибо носители информации и хранилища данных.

3. Хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов.

4. Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.

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

STD (State Transition Diagrams) — диаграммы перехода состояний, основанные на расширениях Хартли и Уорда-Меллора для проектирования систем реального времени.

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

STD состоит из следующих объектов:

• Состояние – моделируемая система в любой заданный момент времени должна находится точно в одном из конечного множества состояний
• Начальное состояние является стартовой точкой для начального системного перехода, соответствующего состоянию системы после её инсталляции. STD должна иметь только одно начальное состояние, а также любое (конечное) число завершающих состояний.
• Переход определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока (сигнала), возникающего как во внешнем мире, так: и внутри системы при выполнении некоторого условия.
• Действие – это операция, которая может быть связана с переходом, и выполняющаяся при выполнении перехода

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

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

Рисунок 1.1. пример ИС построенной средствами STD

ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» в нотациях Чена и Баркера, предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. С помощью ERD-диаграмм осуществляется детализация хранилищ данных моделируемой и проектируемой системы путем идентификации и документирования объектов (сущностей), важных для предметной области, свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).

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

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

Отношение представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (Имеет, Определяет, Может владеть и т.п.).

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

обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);

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

Рисунок 1.2. Символы ERD-диаграмм в нотации Чена

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

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

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

{«0 или 1». «0 или более», «1», «1 или более», “p : q” ( диапазон )}.

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

1*1(один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.

1*n(один-к-многим). Отношения данного типа являются наиболее часто используемыми.

n*m(многие-к-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных сущностей и с введением новых отношений).

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

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

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

Рисунок 1.3. Диаграмма атрибутов

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

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

Нотация Баркера

Дальнейшее развитие диаграммы «сущность-связь» получили в работах Баркера, предложившего оригинальную нотацию на рисунке 1.4, которая позволила интегрировать средства описания моделей Чена.

Рисунок 1.4 Символы ERD-диаграмм в нотации Баркера

В нотации Баркера используется только один тип диаграмм: собственно ERD-диаграммы. Сущность на ERD-диаграмме представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (возможно, неполный) и указатели ключевых атрибутов (знак «#» перед именем атрибута). Понятия категории и общей сущности Чена заменяются Баркером на эквивалентные понятия подтипа и супертипа соответственно.

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

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

Структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов

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

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

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

Фундаментальные элементы структурных карт в соответствии со стандартами IBM, ISO и ANSI.

Базовым элементом структурной карты является модуль. Возможно использовать различные типы модулей

Собственно модуль. Используется для представления обраба­тывающего фрагмента для его локализации на диаграмме.

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

Библиотека. Отличается от подсистемы тем, что определена вне проекта данной системы.

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

При построении структурных карт добавление модулей и увязыва­ние их вместе осуществляется с использованием потоков, демонстрирую­щих иерархию вызовов. При последовательном вызове модули вызываются в порядке их следования. При параллельном вызове модули могут вызываться в лю­бом порядке или одновременно (параллельно).

Для моделирования условных и циклических вызовов применяются следующие узлы.

Условный узел используется для условного вызова модуля-потомка. Он изображается с помощью ромба, потоки – альтернативные вызовы изображаются выходящими из него. Таким образом, если из ром­ба выходят два потока, это соответствует конструкции IF-THEN-ELSE, если один поток – конструкции IF-THEN.

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

Если необходимо показать, что подчиненный модуль не вызывает­ся повторно при активации главного, это осуществляется указанием циф­ры "1" в главном модуле напротив потока – вызова наследника.

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

По аналогии со структурными картами Константайна диаграмма Джексона может включать объекты следующих типов:

• Структурный блок (базовая компонента методологии) пред­ставляет частную функцию или блок кодов с одним входом и одним выходом.
• Процедурный блок является специальным видом структур­ного блока, представляющим вызов ранее определенной процедуры.
• Библиотечный блок аналогичен процедурному и представ­ляет вызов библиотечного модуля.

Для взаимоувязывания блоков используются связи следующих ти­пов:

• последовательная связь, обеспечивающая последовательное вы­полнение слева направо;
• параллельная связь, обеспечивающая одновременное выполнение блоков;
• условная связь, обеспечивающая выбор одной из альтернатив;
• итерационная связь, обеспечивающая выполнение блока в цикле.

SADT (Structured Analysis and Design Technique) – это методология инженерии разработки ПО (software engineering) для описания систем в виде иерархии функций (функциональной структуры).

Структурный анализ возник в конце 60-х годов в ходе революции, вызванной структурным программированием. Метод SADT был предложен Дугласом Т. Россом как способ уменьшить количество дорогостоящих ошибок за счет структуризации на ранних этапах создания системы, улучшения контактов между пользователями и разработчиками и сглаживания перехода от анализа к проектированию. Дуглас Т. Росс часть своих PLEX-теорий относящихся к методологии и языку описания систем, назвал «Методология структурного анализа и проектирования» (SADT). Исходная работа над SADT началась в 1969 г.

Ее широкое распространение в настоящее время в европейской, дальневосточной и американской аэрокосмической промышленности (под названием IDEF0) позволяет эти цифры существенно увеличить. Таким образом, SADT выделяется среди современных методологий описания систем благодаря своему широкому применению. Почему SADT имеет такое широкое применение?

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

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

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

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

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

SADT использует два типа диаграмм:

• модели деятельности (activity models);
• модели данных (data models).

SADT использует стрелки для построения этих диаграмм и имеет следующее графическое представление:

• главный блок (box), где определено название процесса или действия;
• с левой стороны блока – входящие стрелки: входы действия;
• сверху – входящие стрелки: данные, необходимые для действия;
• внизу – входящие стрелки: средства, используемые для действия;
• справа – исходящие стрелки: выход действия.

SADT использует декомпозицию на основе подхода «сверху вниз».

Каждый уровень декомпозиции содержит до 6 блоков.

SADT начинается с уровня (level) 0, затем может быть детализирован на более низкие уровни (1, 2, 3, ...). Например, на уровне 1, блок уровня 0 будет детализирован на несколько элементарных блоков и так далее.

Рисунок. 1.5. Пример уровня 0

На уровне 1 действие «Manufacture computers», может быть разбито (de- clined), например на 4 блока:

• получить электронные компоненты («receive electronic components»);
• сохранить электронные компоненты («store electronic components»);
• доставить электронные компоненты на сборочную линию («bring electronic components to the assembly line»);
• собрать компьютеры («Assemble computers»).

Семантика стрелок для действий (activities):

• входы (Inputs) входят слева и представляют данные или предметы по- требления (consumables), нужные действию (that are needed by the activity);
• выходы (Outputs) выходят справа и представляют данные или продукты, производимые действием (activity);
• управления (Controls) входят сверху и представляют команды, которые влияют на исполнение действия, но не потребляются. В последней редак- ции IDEF0 – условия, требуемые для получения корректного выхода. Данные или объекты, моделируемые как управления, могут быть транс- формированы функцией, создающей выход; механизмы означают средства, компоненты или инструменты, используемые для выполнения действия; представляют размещение (allocation) действий.

Семантика стрелок для данных (data):

• входы (Inputs) – это действия, которые генерируют эти данные (are activities that produce the data);
• выходы (Outputs) потребляют эти данные (consume the data);
• управления (Controls) влияют на внутреннее состояние этих данных (influence the internal state of the data). [4]

Метод SADT получил дальнейшее развитие. На его основе в 1981 году разработана известная методология функционального моделирования IDEF0.

Методология функционального моделирования IDEF0

IDEF0 (Integration Definition for Function Modeling) – методология функционального моделирования для описания функций предприятия, предлагающая язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем бизнес процессов; или анализа инженерии разработки ПО (or software engineering analysis).

Модель IDEF0 – это графическое описание (информационной) системы или предметной области (subject), которое разрабатывается с определенной целью с выбранной точки зрения. Модель IDEF0 представляет собой набор из одной или более (иерархически связанных) IDEF0-диаграмм, которые описывают функции системы или предметной области (subject area) с помощью графики, текста и глоссария.

Методология IDEF0 является развитием метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique).

IDEF0 как стандарт был разработан в 1981 году в рамках программы ICAM (Integrated Computer Aided Manufacturing – интегрированная компьютер- ная поддержка производства).

IDEF0 – Integration DEFinition language 0 – основан на SADT и в своей исходной форме включает одновременно:

• определение языка графического моделирования (синтаксис и семантику);
• описание полной (comprehensive) методологии разработки моделей. Последняя редакция IDEF0 была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).В 1993 году IDEF0 была принята в качестве федерального стандарта в США, а в 2000 году – в качестве стандарта в Российской Федерации. [4]

IDEF0 используется для создания функциональной модели, то есть результатом применения методологии IDEF0 к системе есть функциональная модель IDEF0. Функциональная модель – это структурное представление функций, деятельности или процессов в пределах моделируемой системы или предметной области.

Методология IDEF0 может быть использована для моделирования широкого спектра как автоматизированных, так и неавтоматизированных систем.

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

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

Основные цели (objectives) стандарта:

• задокументировать и разъяснить технику моделирования IDEF0 и правила ее использования;
• обеспечить средства для полного и единообразного (consistently) моделирования функций системы или предметной области, а также данных и объектов, которые связывают эти функции;
• обеспечить язык моделирования, который независим от CASE методов или средств, но может быть использован при помощи этих методов и средств. [4]

Ограничения сложности. Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в стандарте приняты соответствующие ограничения сложности, которые носят рекомендательный характер. При том, что, что на диаграмме рекомендуется представлять от трех до шести функциональных блоков, количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг предполагается не более четырех. [4], [3]

1.3. Анализ доступного программного обеспечения для наглядного представления средств структурного анализа

Dia Diagram Editor — бесплатный редактор для создания графиков различной сложности. Эта программа послужит крутой альтернативой для Microsoft Visio. Простой и понятный интерфейс, сотни фигур, поддержка баз данных и собственных фигур в XML или SVG. А ещё благодаря опенсорсному коду программа доступна на Windows, Mac и Linux. [9]

YEd Graph Editor — мощная программа для быстрого создания качественных диаграмм. В программе доступно как ручное создание, так и импорт внешних данных. Встроенные алгоритмы программы быстро обрабатывают массив данных и автоматически визуализируют их. Программа доступна на Windows, Unix/Linux и Mac. [9]

Pencil Project — ещё одна программа с открытым исходным кодом для создания диаграмм. Pencil Project ориентирован на визуальное создание диаграмм (то есть не из массива данных). Встроенная коллекция форм и шаблонов поможет быстро выбрать нужный формат диаграммы. Ещё у программы большое сообщество энтузиастов, которые всегда готовы помочь с созданием графиков или ответить на вопросы о программе. [9]

LibreOffice Draw — альтернатива офисному пакету от Microsoft. А значит, тут есть все инструменты, необходимые для составления диаграмм и схем. Действительно, если вы привыкли делать графики в Visio или Excel, то первым делом стоит попробовать альтернативу в виде LibreOffice Draw. Здесь вы найдёте всё те же привычные инструменты и функции, просто в немного другой упаковке.

Diagram Designer. Минималистичный до интерфейс, единственная цель которого — создать диаграмму. Несмотря на кажущуюся простоту, здесь много функций. Поддерживается импорт и экспорт данных, автоматический расчёт формул и многое другое. Есть портабельная версия, но поддерживается работа только на Windows системах. [9]

Draw.io – это сервис, предназначенный для формирования диаграмм и схем. Сервис разделён на три части — меню, панель объектов и сам документ.

С помощью веб-сервиса Draw.io можно создавать:

• Диаграммы.
• UML-модели.
• Вставка в диаграмму изображений.
• Графики.
• Блок-схемы.
• Формы и др.

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

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

Также доступен экспорт готовых схем в изображение (PNG, GIF, JPG, PDF), синхронизация полученных документов с Google Диском.

Все заготовки можно изменить и настроить под свои нужды. [5]

B draw.io имеется широкий набор инструментов для быстрого и удобного создания бизнес-моделей, схем, алгоритмов и даже инфографики.

Фигуры (плоские и объёмные), тексты (заголовки, основные тексты, «рыбу» Lorem Ipsum), стрелки, значки, иконки — всё это можно легко разместить на разлинованном листе, поменять размер, цвет, выровнять и расставить, как вам нужно.

С помощью draw.io можно создавать прототипы интерфейса сайтов, приложений, электронных курсов благодаря готовым элементам (кнопки, выпадающие списки, меню и пр.). [5]

Выводы по 1 главе. Таким образом, в первой главе были охарактеризованы основные структурные методы анализа и проектирования ИС, а также подробно описаны средства для проведения структурного анализа, в третьей части главы был проведен анализ доступного программного обеспечения для наглядной реализации реализация информационной системы организации на примере мастерской по ремонту обуви. Для проектируемой системы работы было принято взять за основу методологию IDEF0, так как она может быть использована сначала для определения требований и функций, и затем для реализации, удовлетворяющей этим требованиям и исполняющей эти функции. Для наглядного представления диаграмм использовалось приложение draw.io, так как оно в полной мере отвечает требованиям реализации ИС по теме работы. [1], [2], [9], [11].

ГЛАВА 2. Методология системного подхода IDEF0, для создания ИС

2.1. Определение и характеристика объекта исследования

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

Помимо самого процесса ремонта, к деятельности мастерской также относятся:

• работа с клиентами, которые посетили мастерскую в первый раз;
• обеспечение материалами для ремонта (поставка и реализация);
• постсервисное обслуживание клиентов.

Рассмотрим диаграмму А0, представленную на рисунке 2.1. Основной деятельностью является «ремонт обуви». Входные данные: поврежденная обувь, информация о клиенте, оплата, материалы. Управляющей информацией являются закон о правах потребителей (законы РФ) и правила и процедуры, управляющим механизмом – ИС мастерской и персонал. Выходные данные представляются в виде перевода денег в банк, квитанции на выполненный ремонт, отремонтированная обувь, поврежденная обувь, компенсация.

Рисунок 2.1. Диаграмма А0

Теперь проведем декомпозицию полученной диаграммы.

Деятельность «Работа мастерской» можно представить как последовательность следующих действий (Рисунок 2.2):

• Оформить заявку;
• Получение материалов;
• Отремонтировать обувь;
• Выдача обуви.

Рисунок 2.2. Декомпозиция диаграммы «Работа мастерской»

Проведем дальнейшую декомпозицию. Деятельность «Оформление» включает следующие действия (рисунок 2.3):

• Провести осмотр обуви;
• Проверить наличие материалов;
• Бухгалтерия;
• Принять заказ;
• Отремонтировать обувь;
• Внести сведения о ремонте.

Рисунок 2.3. Декомпозиция деятельности «Оформление»

Алгоритм «Проверка наличия материалов» (Рисунок 2.4) состоит из нескольких шагов:

• Проверить наличие материалов
• Заказать материалы
• Получить материалы
• Выдать материалы

Рисунок 2.4. Декомпозиция деятельности «Проверка наличия материалов»

Деятельность «Ремонт обуви» включает следующие действия (Рисунок 2.5):

• Провести осмотр обуви;
• Проверить наличие материалов;
• Отремонтировать обувь;
• Внести сведения о ремонте.

Рисунок 2.5. Декомпозиция деятельности «Ремонт обуви»

В деятельность по «Получению и постсервисному обслуживанию» входят следующие функции (рисунок 2.6):

• Принять квитанцию о ремонте;
• Выдать отремонтированную обувь
• Компенсировать потери клиента в случае неудавшегося ремонта;
• Оформление документации.

Рисунок 2.6. Декомпозиция деятельности «Получение и постсервисное обслуживание» [4], [6], [7].

2.2. Представление деятельности объекта в общем древе целей

После построения информационной модели сформируем древо целей (Рисунок 2.7):

Рисунок 2.7. Древо целей информационной системы

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

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

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

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

Параллельно с проектированием схемы базы данных выполнялось проектирование процессов, чтобы получить спецификации (декомпозиции) всех модулей ИС. Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. Конечным продуктом нашей работы является полноценная информационная система для мастерской по ремонту обуви. [10], [4], [8].

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Балабанов, И.Т. Современные моделирования./ И.Т. Балабанов – СПб: Питер, 2002. – 120 с.
2. Венчковский, Л.Б. Разработка сложных программных изделий. [Электронный ресурс]: URL: https://booksee.org/book/522849
3. Вендров, А.М. Проектирование программного обеспечения экономических информационных систем [Электронный ресурс]: URL: https://www.studmed.ru/vendrov-am-proektirovanie-programmnogo-obespecheniya-ekonomicheskih-informacionnyh-sistem_cad6fb3dce9.html
4. Евгений Андреевич, UML-диаграмма. Виды диаграмм UML [Электронный ресурс]: URL https://www.syl.ru/article/206012/new_uml-diagramma-vidyi-diagramm-uml
5. Инюшкина, О.Г. Проектирование информационных систем (на примере методов структурного системного анализа) [Электронный ресурс]: URL: http://elar.urfu.ru/bitstream/10995/28812/1/978-5-91128-072-7_2014.pdf

• Михно, Т.А. Программирование в картинках. Rational RoseТатьяна Михно[Электронный ресурс]: URL http://www.interface.ru/fset.asp ?Url=/rational/progras.htm

1. Мордаровский, Д. Draw.io — бесплатное средство для создания блок-схем, инфографики, прототипов [Электронный ресурс]: URL https://el-blog.ru/draw-io/
2. ITru. Моделировании ИС http:// www.it.ru /
3. INTERFACE. Моделирование бизнеса и архитектура информационной системы [Электронный ресурс]: URL http://www.interface.ru /
4. Optima. WorkFlow [Электронный ресурс]: URL http://www.optima.ru/
5. Пять бесплатных инструментов для создания диаграммы сети [Электронный ресурс]: URL https://www.internet-technologies.ru/articles/5-besplatnyh-instrumentov-dlya-sozdaniya-diagrammy-seti.html