Задачи при разработке ИС. Модели архитектуры ИС. CASE - технология.

Задачи при разработке ИС. Модели архитектуры ИС. CASE - технология.

При разработке информационных систем (ИС) нужно решать множество взаимосвязанных задач. Это умение строить математические модели, понимать и уметь реализовать управление, разрабатывать алгоритмы и программное обеспечение, разрабатывать документацию и сопровождать функционирование системы. Потребность контролировать процесс разработки привела к появлению целой совокупности инженерных методов и средств создания программ (Softwhere Engineering (SE)).

 

1 Этап (90-ые годы):

Стандартизация и систематизация процессов на основе структурного подхода.

 

2 Этап (20 век):

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

 

В основе СИ лежит основная идея: проектирование систем является формальным процессом который можно стандартизировать.

 

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

 

Главный принцип СИ использовать модельный подход к разработке системы.

 

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

 

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

 

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

 

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

Совместные способы стали возможны при появлении программно – технических средств специального класса (CASE). CASE (Computer-aided software engineering) средства - совокупность методов проектирования систем, а также набор инструментарных средств позволяет в наглядной форме моделировать подсистемы и системы, анализировать на всех стадиях и разрабатывать приложения в соответствии с информационными потребностями пользователя.

 

Парадигмы CASE-технологии. Жизненный цикл ИС.

Прадигмы:

 

Методолгоия.

Как с помощью моделей и методов описать весь процесс создания системы. Выбрать комплекс инструментальных средств, обеспечивающих автоматизированное проектирование. В основе методологии лежит пошаговый метод, который требует следования определенным этапам жизненного цикла, правила выполнения каждого этапа, упорядочивание всего процесса проектирования. В современной методологии 3 этапа: Структурный подход, ОО подход, RAD (Rapid Application Development) средства.

 

Метод.

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

 

Нотация.

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

 

Средства.

Инструментарий для поддержки и усиления методов.

 

Жизненный цикл ИС:

 

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

CASE-средство – программное средство, поддерживающее процессы ЖЦ ПО, определенные в стандарте ISO/IEC 12207:1995.

Традиционно выделяются следующие основные этапы ЖЦ ПО:

 анализ требований,

 проектирование,

 кодирование (программирование),

 тестирование и отладка,

 эксплуатация и сопровождение.

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

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

Проектирование

Кодирование

Тестирование

Эксплуатация

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

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

 

Процессы: основные, вспомогательные, организационные. Модели реализации ИС.

 

Процессы:

 

Приобретение (Заказ)

Поставка

Разработка

Эксплуатация

Сопровождение

 

Модели реализации ЖЦ ИС:

 

Каскадная модели:

 

Анализ требований (сбор требований к продукту) => проектирование (описание внутренней структуры, диаграммы, тексты) => реализация (программирование, интеграция) => тестирование => внедрение => сопровождение.

 

Спиральная модель:

 

Анализ => проектирование => реализация и тестирование => выполнять более одного раза.

 

Положительные стороны каскадного подхода:

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

 

Спиральные и инкрементные процессы:

Барии Боен.

Необходимость предупреждения рисков.

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

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

Минусы:

Требуется более искусное управление.

Необходимость поддержки целостности документации в конце каждой версии.

Трудность в определении момента перехода на следующий этап.

Переход осуществляется в соответствии с планом, даже если не все работы выполнены.

 

Типичный проект – это, трудоемкость которого оценивается в 3 человека месяца. Затраты на проведение большого числа шагов могут превысить выгоду от дополнительных итераций.

 

DFD-моделирование. Основные компоненты. Примеры DFD-модели.

 

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

Для изображения DFD традиционно используется две различные нотации: Йордана и Гейна-Сарсона. Далее при построении будет использоваться нотация Гейна-Сарсона.

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

Методология структурного анализа и проектирования базируется на интеграции следующих средств:

Ø DFD-диаграмм потоков данных, которые являются графическими иерархическими спецификациями (описаниями) систем с позиций потоков данных. Основные символы DFD в нотации Гейна-Сарсона приведены в таблице 1.

Таблица 1. Нотация Гейна-Сарсона.

Компонент	Графическое представление	Назначение
Поток данных (Arrow)		Потоки данных описывают движение объектов из одной части системы в другую.
Процесс (Activity)		Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса.
Хранилище (Data Store)		Хранилище данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами.
Внешняя сущность (External Reference)		Внешняя сущность представляет сущность вне контекста системы, являющуюся источником или приемником данных системы. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

 

Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, хранилищам данных (ХД) или внешним сущностям - потребителям информации. Потоки могут подходить и выходить из любой грани прямоугольника работы и могут быть двунаправленными для описания взаимодействия типа “запрос-ответ” (рис.2.2).

Рис.2.2. Взаимодействие типа “запрос-ответ ”.

Ø Словарей данных (репозиториев), использующихся для хранения метаданных (структуры потоков данных, ХД), описания их компонентов. Для определения статей словаря данных используется специальный язык Бэкуса-Наура.

Ø Спецификаций процессов, использующихся для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD. Фактически спецификации процессов представляют собой алгоритмы описания задач, выполняемых процессами: множество всех спецификаций является полной спецификацией системы. Для описания тела процесса будем использовать структурированный естественный язык (СЕЯ).

 

IDEF-технология проектирования ИС. IDEF0, IDEF3-модели. Примеры.

 

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

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

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

Диаграмма является основной единицей описания в IDEF3-модели.

Единицы работы – Unit of Work (UOW), также называемые работами, являются центральными компонентами модели. Изображаются прямоугольниками и имеют имя и номер (рис.2.4).

 

 

Номер родительской работы

Номер работы

 

Рис.2.4.Изображение работы в диаграмме IDEF3.

Связи показывают взаимоотношения работ. Все связи в IDEF3 являются однонаправленными.

Таблица 2. Типы связей.

Тип связи	Графическое представление	Назначение
Временное предшествование (Temporal Precedence).		Соединяет последовательно выполняемые работы.
Нечеткое отношение (Relationship).		Используется для изображения связей между единицами работ, а также между единицами работ и объектами ссылок.
Объектный поток (Object Flow).		Применяется для описания использования объекта в двух или более единицах работы.

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

Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) потоков. Перекресток не может быть использован одновременно для слияния и разветвления.

 

Таблица 3. Типы перекрестков.

Наименование	Обозначение	Смысл в случае слияния потоков	Смысл в случае разветвления потоков
Asynchronous AND		Все предшествующие процессы должны быть завершены.	Все следующие процессы должны быть запущены.
Synchronous AND		Все предшествующие процессы должны быть завершены одновременно.	Все следующие процессы запускаются одновременно.
Asynchronous OR		Один или несколько предшествующих процессов должны быть завершены.	Один или несколько следующих процессов должны быть запущены.
Synchronous OR		Один или несколько предшествующих процессов должны быть завершены одновременно.	Один или несколько следующих процессов запускаются одновременно.
XOR (Exclusive OR)		Только один предшествующий процесс завершен.	Только один следующий процесс запускается.

 

Объекты-ссылки являются специальными символами, которые ссылаются на внешние части процесса. Они добавляются на диаграмму для того, чтобы обратить внимание на что-либо важное, что невозможно связать со стрелкой, работой или перекрестком. Официальная спецификация IDEF3 различает три стиля объектов-ссылок – безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты-ссылки. При внесении объектов-ссылок необходимо указать их тип.

 

Таблица 4. Типы объектов-ссылок.

Тип объекта-ссылки	Цель описания
OBJECT	Описывает участие важного объекта в работе.
GOTO	Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на перекресток.
UOB (Unit of behavior)	Применяется, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работ.
NOTE	Используется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму.
ELAB (Elaboration)	Используется для усовершенствования графиков или более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках.

 

Объекты-ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями.

Рассмотрим пример. На стадии разработки технического задания заказчик системы играет важную роль, снабжая разработчиков необходимой информацией для создания системы. Поэтому на диаграмме показан соответствующий объект-ссылка “Заказчик”, влияющий на работу “Разработка технического задания” (рис.2.5).

Рис.2.5. Использование объекта-ссылки на диаграмме.

ППО второго типа

ППО, отнесенное по нашей классификации ко второй группе (middleware, обеспечивающее взаимодействие между активными приложениями), может быть условно разбито на три основных типа: ППО удаленного вызова процедур (RPC, Remots Procedure Call), ППО передачи сообщений (MOM, Message Orientet middleware) и ППО брокеров объектных запросов (ORB, Object Request Broker).

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

До недавнего времени применение RPC было сопряжено с немалыми сложностями, когда приходилось обращаться к приложению, написанному на другом языке программирования или работающему под другой ОС. Современные средства RPC позволяют разработчику действовать на более высоком уровне абстракции, не задумываясь о специфике языка программирования и ОС, - RPC стала удобным механизмом для взаимодействия приложений на различных программно-аппаратных платформах. Распространение Java вызвало к жизни аналог RPC для Java-приложений - RMI (Remote Method Invocation).

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

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

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

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

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

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

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

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

В настоящее время основная доля рынка MOM принадлежит двум компаниям - IBM с ее продуктом IBM MQSeries и Microsoft с MSMQ. IBM MQSeries отличается многоплатформностью, поддержкой различных сетевых протоколов и открытостью интерфейсов, позволяющих легко наращивать функциональность системы. Главное достоинство MSMQ - его тесная интеграция с OC Windows, а также поддержка COM.

ORB. Технология брокеров запросов к объектам является наряду с MOM наиболее бурно развивающимся типом ППО. ORB управляют обменом сообщениями в сети. Подобно "человеческому" брокеру, ORB выполняет функции интеллектуального посредника, т. е. принимает запросы от клиента (клиентского приложения), осуществляет поиск и активизацию удаленных объектов, которые принципиально могут ответить на запрос, и передает ответ объектам запрашивающего приложения. ORB, как и RPC и MOM, скрывает от пользователя процесс доступа к удаленным объектам. Запрашивающий объект должен знать имя активизируемого объекта и передать ему некоторые параметры (как правило, это информация об интерфейсе вызываемого объекта - своего рода API для ORB). Интерес к ORB подогревается тем, что это middleware поддерживает объектную модель, ставшую де-факто стандартом при разработке больших информационных систем. В настоящее время на рынке конкурируют стандарт CORBA и технология COM корпорации Microsoft.

Как работает JDBC?

В JDBC определён набор объектов и методов для взаимодействия с БД. Программа на Java сначала открывает соединение с БД, создаёт объект-оператор, передаёт SQL-оператор соответствующей СУБД посредством объекта-оператора и извлекает данные в виде информации находящейся в объекте представляющем результат запроса. Файлы, содержащие классы JDBC, необходимые для работы с БД посредством Java и само приложение или аплет могут находиться на машине клиента или быть получены по сети. Но для уменьшения задержек при работе будет лучше, если файлы с классами JDBC будут находиться у клиента. БД находится на удалённой машине или на машине клиента.

JDBC может быть реализован как родной драйвер, т.е. специфичной для данной ОС (например JDBCODBC.DLL) или как шлюз к RPC и др. сетевым протоколам. Принимать решение о том, какой способ использовать, нужно исходя из того для каких целей создаётся программа. Для локальных БД лучше подходит родной драйвер, т.к. он работает более быстро. Для сетевых компьютеров основанных полностью на Java, не обойтись без второго варианта.

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

При работе с JDBC для обозначения данных используют термин источник данных (Data Source) вместо терминов СУБД, БД или файл. Это понятие более точно соответствует действительности, т.к. для программы, использующей JDBC, фактическое нахождение дан-ных является не существенным, лишь бы существовал драйвер, обеспечивающий доступ к этим данным.

 

 

Задачи при разработке ИС. Модели архитектуры ИС. CASE - технология.

При разработке информационных систем (ИС) нужно решать множество взаимосвязанных задач. Это умение строить математические модели, понимать и уметь реализовать управление, разрабатывать алгоритмы и программное обеспечение, разрабатывать документацию и сопровождать функционирование системы. Потребность контролировать процесс разработки привела к появлению целой совокупности инженерных методов и средств создания программ (Softwhere Engineering (SE)).

 

1 Этап (90-ые годы):

Стандартизация и систематизация процессов на основе структурного подхода.

 

2 Этап (20 век):

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

 

В основе СИ лежит основная идея: проектирование систем является формальным процессом который можно стандартизировать.

 

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

 

Главный принцип СИ использовать модельный подход к разработке системы.

 

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

 

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

 

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

 

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

Совместные способы стали возможны при появлении программно – технических средств специального класса (CASE). CASE (Computer-aided software engineering) средства - совокупность методов проектирования систем, а также набор инструментарных средств позволяет в наглядной форме моделировать подсистемы и системы, анализировать на всех стадиях и разрабатывать приложения в соответствии с информационными потребностями пользователя.