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

Обновлено: 05.07.2024

Проектирование информационных систем.( Массель Л.В.)

56__ Определение и классификация информационных систем

Возьмём за основу две трактовки термина " информационная технология ":

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

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

Основным является деление информационных технологий на:

Функциональные – связанные с предметной областью

Обеспечивающие – используются при реализации функциональных ит.

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

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

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

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

57__ Структурный подход к проектированию информационных систем .

Сущность структурного подхода

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

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

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

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

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

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

принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков данных;

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

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

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

ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

связность диаграмм (номера блоков);

уникальность меток и наименований (отсутствие повторяющихся имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

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

Принцип второй – принцип неизменности точки зрения.

Принцип четвертый – принцип декомпозиции диаграмм.

Принцип пятый – принцип сохранения дуг

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

Принцип шестой – принцип декомпозиции дуг.

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

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

DFD (Data Flow Diagram)

В основе данной методологии (другое название – методология Gane/Sarson по имени авторов) лежит представление жизненного цикла информации в виде потоков данных, являющихся результатом определенных процессов (сбора, обработки, хранения, передачи) анализируемой ИС – проектируемой или реально существующей.

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

IDEF3

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

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

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

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

Содействовать принятию оптимальных решений при реорганизации технологических процессов.

Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ. "

Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.

58__ Объектный подход к проектированию информационных систем.

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

Методы разбивают на три группы:

метод структурного проектирования сверху вниз (оказалось, что структурный подход не работает, если объем программы превышает приблизительно 100000 строк);.

метод потоков данных (DFD) (структура программной системы строится как преобразование входных потоков в выходные);

объектно-ориентированное проектирование (OOD).

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

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

Модели объектно-ориентированного проектирования. Важность построения моделей при проектировании сложных систем диктует необходимость наличия нескольких типов моделей (рис.3).

Несмотря на различия в моделях, методы проектирования моделей имеют что-то общее. Их, в частности, объединяет следующее:

условные обозначения - язык для описания каждой модели;

процесс - правила проектирования модели;

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

Рис . 3. Модели объектно-ориентированного проектирования.

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

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

Основные предпосылки создания объектно-ориентированного подхода:

прогресс в области архитектуры ЭВМ (включая системную и аппаратную часть);

развитие языков программирования, таких как Simula, Smalltalk, CLU, Ada;

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

Три момента, оказавшие влияние на становление объектного подхода:

развитие теории баз данных (ER-модели);

исследования в области искусственного интеллекта (теория фреймов);

достижения философии и теории познания (греки – мир можно рассматривать как в терминах объектов, так и событий; Декарт _люди имеют объектный взгляд на мир; Клир – редукционизм и холизм).

Компоненты объектного подхода

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

Классы и объекты

Цели (наиболее часто выраженные в терминах исчисления предикатов)

Ориентированный на правила

Правила "если…- то…"

Ориентированный на ограничения

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

Ему соответствуют четыре главных элемента

(без любого из них подход не будет ОО)

и три дополнительных элемента:

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

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

Выделяют следующие обстракции:

Объект представляет собой модель некой сущности (описание существенных сторон) предметной области

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

•Абстракция в виде виртуальной машины

Объект объединяет группы операции, которые либо используются для управления объектом (на более высоком уровне управления), либо сами используют некоторый набор операций более низкого уровня

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

Наиболее интересны абстракции сущностей объектов, так как они соответствуют словарю предметной области.

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

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

Понятия операция ( Ada ), метод ( Smalltalk ) и функция-элемент ( C++ ) - фактически обозначают одно и то же и используются как эквивалент.

Все абстракции обладают как статическими, так и динамическими свойствами.

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

Уже насчитывается около 2000 языков программирования, более 100 – объектных (имеющих механизмы реализации абстрактных данных и классов, например, Ada) и объектно-ориентированных языков (в которых реализован механизм наследования как средство отражения иерархии классов, например, Smalltalk, Object Pascal (в нем есть простое наследование), C++, Clos).

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

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

Пример: В Object Pascal формально нет ограничений доступа, тем не менее все поля являются обособленными, а доступ к ним осуществляется через методы класса.

3. Модульность – является элементом конструкции и позволяет осуществлять на её основе проектные решения. В таких языках ( например, Object Pascal, C++, Ada, CLOS, LISP) классы и объекты составляют логическую структуру системы, эти абстракции организуются в модули, образуя физическую структуру системы (особенно когда система состоит из сотен классов).

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

Определение: Модульность - это свойство системы, связанное с возможностью декомпозиции ее на ряд тесно связанных модулей.

Пример: обратиться к рис. 3 на стр. 5. Выявление классов и объектов - логическое проектирование, деление на модули – физическое проектирование

4. Иерархия – это ранжированная или упорядоченная последовательность.

Пример иерархии: наследование - такое отношение между классами (отношение родитель/потомок), когда один класс заимствует структурную или функциональную часть одного или нескольких других классов (соответственно, простое или множественное наследование ).

Дополнительные элементы объектно-ориентированного стиля.

1. Типизация. Концепция типизации строится на понятии типов абстрактных данных.

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

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

Объект является основой, которая объединяет обе концепции: каждый объект (как абстракция реальности) может представлять собой отдельный канал управления (абстракцию процесса). Такой объект называется активным.

Определение: Параллелизм - это свойство объектов находиться в активном, либо пассивном состоянии.

3. Устойчивость – это свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и (или) в пространстве (перемещение объекта из адресного пространства, в котором он был создан )

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

Инкапсуляция – объединение в данном элементе и данных, и способов их обработки. Можно определить данные, входящие в классы, и действия, которые могут выполняться над этими данными, как некоторую структуру–объект в системе, работающей согласно набору правил.

Сущность структурного подхода. Методология функционального моделирования SADT. Графическое представление процесса IDEF0. Взаимосвязи и взаимодействия процессов в IDEF0. Состав функциональной модели. Проблемы при информационной стыковке компонентов.

Рубрика	Программирование, компьютеры и кибернетика
Вид	лекция
Язык	русский
Дата добавления	28.12.2013
Размер файла	45,2 K

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

Структурный подход к проектированию ИС

1. Сущность структурного подхода

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

Все наиболее распространенные методологии структурного подхода:

структурный анализ и разработка приложений SADT,

объектно-ориентированный анализ и проектирование OOAП,

методология структурного проектирования Йодана,

структурный системный анализ Гейна-Сарсона,

структурный анализ Де-Марко,

развитие систем Джексона,

развитие структурных схем Варнье-Орра,

подход Чена и другие базируются на ряде общих принципов.

В качестве двух базовых принципов используются следующие:

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

*принцип иерархического упорядочивания -- принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

*принцип абстрагирования -- заключается в выделении существенных аспектов системы и отвлечения от несущественных;

*принцип формализации -- заключается в необходимости строгого методического подхода к решению проблемы;

*принцип непротиворечивости -- заключается в обоснованности и согласованности элементов;

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

*SADT (Structured Analysis and Design Technique) -- модели и соответствующие функциональные диаграммы;

*DFD (Data Flow Diagrams) -- диаграммы потоков данных;

*ERD (Entity-Relationship Diagrams) -- диаграммы "сущность-связь".

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

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

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

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

Методология SADT разработана Дугласом Россом в 1969 г. В то же время была предложена и реализована программа комплексной компьютерной поддержки производства (ICAM - Integrated Computer-Aided Manufacturing), в рамках которой, в частности, применялась методология структурного анализа систем. Позже на базе этого подхода была разработана методология функционального моделирования IDEF0, которая в 1993 году была принята в качестве федерального стандарта в США , а в 2000 году - в качестве руководящего документа по стандартизации в Российской Федерации.

В методологии функционального моделирования IDEF0 для графического представления процесса используется следующая нотация.

Графическое представление процесса IDEF0

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

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

*графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

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

Правила SADT включают:

*ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

*связность диаграмм (номера блоков);

*уникальность меток и наименований (отсутствие повторяющихся имен);

*синтаксические правила для графики (блоков и дуг);

*разделение входов и управлений (правило определения роли данных).

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

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

3. Состав функциональной модели

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

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

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

4. Иерархия диаграмм

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

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

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

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

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

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

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

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

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

Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. Пример:

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

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

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

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

5. Стратегия декомпозиции

При построении иерархии диаграмм используется следующие стратегии декомпозиции:

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

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

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

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

Использование: данную стратегию декомпозиции (т.е. разложение на подсистемы) рекомендуется использовать толео тогда, когда разделение на основные части системы не меняется.

Недостаток: нестабильность границ подсистем быстро обесценит как отдельные модели, так и их объединение.

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

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

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

6. Завершение моделирования (определение момента прекращения декомпозиции)

Когда же следует завершить построение модели?

Размер иерархической модели увеличивается со скоростью геометрической прогрессии. Например общее количество блоков в четырехуровневой модели будет 1365 (Тор - 1, 0-й ур. -5, 1-й ур. - 21, 2-й ур. - 85, 3-й ур. - 341, 4-й ур. - 1365).

Обычно модель строят слоями, большинство блоков не раскрываются далее 3-го уровня. Наиболее важные функции детализируются до 5-6 уровня (но очень редко).

Существуют рекомендации по прекращению процесса декомпозиции.

Декомпозиция одного из блоков должна прекратиться, если:

Блок содержит достаточно деталей. Т.е. блок описывает систему нужным уровнем подробности. Это типичная ситуация, которая встречается в конце процесса декомпозиции. Как проверить достаточность деталей? Надо спросить себя: отвечает ли блок на все или часть вопросов, составляющих цель системы? Если блок помогает ответить на один или более вопросов, то дальнейшая декомпозиция может не понадобиться.

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

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

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

7. Типы связей между функциями

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

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

- принцип иерархического упорядочивания;

- принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

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

- принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

- принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

- SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

- DFD (Data Flow Diagrams) диаграммы потоков данных;

- ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

2.3. Примеры комплексов CASE-средств

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

- средство разработки приложений JAM;

- мост Silverrun-RDM JAM;

- комплекс средств тестирования QA;

- менеджер транзакций Tuxedo;

- комплекс средств планирования и управления проектом SE Companion;

- комплекс средств конфигурационного управления PVCS;

- объектно-ориентированное CASE-средство Rational Rose;

- средство документирования SoDA [6].

Примерами других подобных комплексов являются:

- Vantage Team Builder for Uniface + Uniface (фирмы "DataX/Florin" и "ЛАНИТ");

- комплекс средств, поставляемых и используемых фирмой "ФОРС":

- CASE-средства Designer/2000 (основное), ERwin, Bpwin и Oowin (альтернативные);

- средства разработки приложений Developer/2000, ORACLE Power Objects (основные) и Usoft Developer (альтернативное);

- средство настройки и оптимизации ExplainSQL (Platinum);

- cредства администрирования и сопровождения SQLWatch, DBVision, SQL Spy, TSReorg и др. (Platinum);

- средство документирования ORACLE Book.

- комплекс средств на основе продуктов фирмы CENTURA:

- CASE-средства ERwin, Bpwin и Oowin (объектно-ориентированный анализ);

- средства разработки приложений SQLWindows и TeamWindows;

- средство тестирования и оптимизации приложений "клиент-сервер" SQLBench (ARC);

- средства эксплуатации и сопровождения Quest и Crystal Reports [8].

3. Анализ языков программирования

3.1. Обзор языков программирования

3.1.1. Языки программирования системного уровня

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

К концу 50-х годов начали появляться языки программирования более высокого уровня, такие как Lisp, Fortran, ALGOL. В них уже не было точного соответствия между языковыми конструкциями и машинными командами. Преобразование строк исходного кода в последовательности двоичных команд осуществлялось компилятором. Со временем их число пополнилось языками PL /1, Pascal, C, C++, Java. Все они менее эффективно используют аппаратуру по сравнению с языками ассемблера, но позволяет быстрее создавать приложения. В результате им удалось практически полностью вытеснить языки ассемблера при создании крупных приложений [2].

Раздел: Информатика, программирование
Количество знаков с пробелами: 100010
Количество таблиц: 1
Количество изображений: 8

современные методы и средства проектирования информационных систем

Структурный подход к проектированию ИС ( реферат , курсовая , диплом , контрольная )

Сущность структурного подхода

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

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

принцип абстрагирования — заключается в выделении существенных аспектов системы и отвлечения от несущественных;

принцип формализации — заключается в необходимости строгого методического подхода к решению проблемы;

принцип непротиворечивости — заключается в обоснованности и согласованности элементов;

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2);

DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);

Читайте также: