«система»
| Вид материала | Лекция |
- Лекция 2 Экономическая система, как объект кибернетики, 70.17kb.
- 1. Назва модуля: Конструкція та динаміка двигунів внутрішнього згорання Код модуля, 20.12kb.
- Воспитательная система образовательного учреждения. Концепция всш, 120.08kb.
- Налоговая система, 798.68kb.
- Тема Правовые системы современности, 23.96kb.
- Солнечная система автор: Самиев Махмуд, 6 «Б» класс, 547.98kb.
- Темы рефератов икурсовых работ общие. Система государственного управления: основные, 90.41kb.
- Лекция Система национальных счетов, 238.7kb.
- Школа как педагогическая система и объект научного управления, 71.64kb.
- В. А. Геодакян Окружающий нас мир состоит из разных систем: наша галактика система,, 284.73kb.
ЛЕКЦИЯ 4.
СОВРЕМЕННЫЕ МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ ПРИЛОЖЕНИЙ.
На современном этапе развития существуют два подхода к проектированию и построению приложений: методология структурного анализа и методология объектно-ориентированного подхода.
^ Методологии структурные анализа и проектирования основаны на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. При этом важен порядок построения модели. Процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонентов по отношению к проектированию структур данных. При информационно-ориентированном подходе вход и выход являются наиболее важными - структуры данных определяются первыми, а процедурные компоненты являются производными от данных.
Одной из структурных методологий, основанных на информационно-ориентированном подходе, является информационная инженерия.
^
Информационная инженерия
Информационная инженерия вращается вокруг двух основных концепций.
1. Послойный целостный подход к разработке интегрированных приложений, базирующийся на стратегическом планировании информационных систем.
^ 2. Направленность на моделирование данных, а затем - на функциональное моделирование.
Для организаций, разрабатывающих целый ряд приложений за определенный период, бывает затруднительно приспособить их все к совместной работе. Клиенты недовольны, когда им приходится несколько раз запрашивать одну и ту же информацию в разных отделах одной организации. Служащие нуждаются в информации от всех частей организации для ответа на вопросы и решения проблем. Программистам надоедает писать одни и те же коды вновь и вновь, когда существующие функции оказываются очень похожими. Все эти примеры указывают на необходимость интеграции приложений.
^ В информационной инженерии конкретные решения этих проблем начинаются с разработки плана некоторой информационной системы (Information System Plan - ISP), как указано на рисунке 1 (модель информационной инженерии).
Высокоуровневый стратегический документ - ISP охватывает большинство приложений организации, которые предполагается разработать за некоторый, довольно длинный период времени. Первоначально фокусируясь на проектировании БД, ISP также имеет дело с классическим планированием, включая организационные структуры. Более всего ISP обеспечивает представление высокого уровня на общую основу объединения всех приложений данной организации вместе.
^ Базируясь на ISP, планировщики разделяют все множество потенциальных приложений этой организации на некоторое число областей бизнеса. Сначала рассматриваются характерные подразделения данной организации относительно различных видов ее деятельности. Затем подбираются инструментальные средства для группирования приложений - наборы процессов бизнеса, совместно протекающих и базирующихся на использовании общих данных.
После установления приоритетов эти области бизнеса тщательно анализируются, одна за другой, в процессе, именуемом анализом области бизнеса (Business Агеа Analysis - ВАА). Каждый ВАА обеспечивает более детальную модель структур БД и функций приложений, требуемых в этой конкретной области бизнеса.
Далее, выбираются отдельные приложения для проектирования деловой системы (Business System Design - BSD) и ее последующего конструирования (Business System Construction - BSC). Фактически информационная инженерия затем переходит к предписанным отдельным, более многочисленным, стадиям для завершения управляемого методологией процесса, включающего подходы для тестирования, выпуска продукции и сопровождения приложений.
Таким образом, ядром информационной инженерии является обоснованный набор шагов для планирования и построения по методу сверху вниз. Информационная инженерия также предписывает набор моделей и стратегий проектирования для моделирования приложений.
^ Недостатки моделирования данных
1. На общем уровне БД и модель данных рассматриваются как центральные понятия в планировании и проектировании приложений.
^ 2. Фактические вычисления, работа пользователя и правила бизнеса рассматриваются как некоторое дополнение к БД исходя из ориентированных на задачи перспектив.
Но этот подход имел несколько недостатков:
1. Разработка полной корпоративной модели данных дорогая и сложная. Многие организации решились построить такие модели, но после заполнения 30 или 40 томов документации за период в 2 - 3 года они пришли к заключению, что могут никогда не закончить эту работу.
2. Высшее руководство не принимает участия в разработке и до сих пор не понимает модели данных. Попытки вовлечь их в этот процесс обречены на неудачу. Высшее руководство, однако, понимает процессы, протекающие в их бизнесе.
3. Основательная модель данных является важной, но далеко не достаточной.
Одностороннее акцентирование внимания на модели данных и ее разработке фактически тормозило соответствующую основу для функционального проектирования.
Итак, применение информационной инженерии приводило к тому, что основное внимание уделялось моделированию данных в ущерб моделированию процессов. Поэтому с возникновением методологии реинжиниринга бизнес-процессов остро встал вопрос о методологии проектирования соответствующих приложений.
Основой для перепроектирования процессов бизнеса является переход от задач к рассмотрению процессов. Один из первых подходов, использованных для рассмотрения функциональной стороны основы приложения, называется функциональной декомпозицией. Функциональная декомпозиция является точным эквивалентом разделения сложных процессов на маленькие задачи. Функциональная декомпозиция начинается с описания основного процесса. Затем он разлагается на составные части - меньшие задачи и процессы. Такое дробление выполняется снова и снова. Очень скоро этот общий процесс становится разделенным на части в форме небольших понятных задач, которые затем можно легко и быстро запрограммировать.
В результате применения этой методологии разрабатывается модель общего процесса. Модель в своем развитии проходит три стадии. В следующей таблице трехслойная архитектура приложения представлена как трехстадийный процесс - планирование, проектирование, разработка.
Стадии проектирования приложений
| | Концептуальная | Логическая | Физическая |
| Документы | Поток работ | Поток форм | Формы |
| ^ Правила бизнеса | Поток процессов | Модель компонентов | Программы |
| База данных | Модель данных | Схема БД | Таблицы, индексы |
Рассмотрим более детально эти стадии.
Концептуальная. Первой стадией в любом проекте является обзор требований и разработка общего проекта. В слое документа этот проект рассматривает обширные потоки работ от подразделения к подразделению, от сотрудника к сотруднику, без учета детальных форм и интерфейсов. На уровне процесса рассматриваются высокоуровневые диаграммы деловых процессов. На уровне БД рассматривается высокоуровневая, интегрированная основа моделей данных предприятия и его подразделений.
Логическая. На этой стадии принимаются во внимание детальные правила бизнеса, проект улучшается в соответствии с тем, как эти правила можно приспособить. На уровне слоя документа смакетированы последовательности детализированных форм, показывающие точную последовательность шагов, необходимых для завершения конкретных задач. На уровне процесса высокоуровневые кружки разбиваются на более детальные процессные взаимодействия и диаграммы запрос/действие, которые показывают, как работают более крупные кружки. На уровне БД высокоуровневая модель преобразуется в классическую диаграмму сущность/связь, показывающую потенциальную схему БД, которая учитывает основные вопросы согласованности и содержательности.
Физическая. Проект преобразуется в фактическую систему. На уровне рабочего стола программисты проектируют отдельные формы, улучшают прототипы в детальных графических интерфейсах и пишут код. Потоки процессов преобразуются в специфичные куски программного кода. Проект БД улучшается, нормализуется, устанавливаются индексы.
Таким образом, при последовательном прохождении всех трех стадий проектирования ищутся ответы на вопросы о будущем приложении клиент/сервер.
Концептуальная модель отвечает на три вопроса: Как будет выглядеть новое приложение? Как изменится данный бизнес? Как будут отображены требования к новым процессам бизнеса?
Логическая модель делает шаг вперед и обсуждает такой вопрос: Какие шаги, в деталях, будут происходить при выполнении каждого из самых крупных процессов, описанных на концептуальном уровне? Логическая модель доказывает, что приложение может работать.
На следующих два вопроса: Можно ли это реализовать? Будет ли новое приложение хорошо выполняться? отвечает физическая модель. Физический уровень в нашем процессе - это место, где данное приложение программируется, определяются требования к памяти, скорости передачи данных и другая необходимая информация для эффективной работы приложения.
Теперь рассмотрим три вида моделей, которые соответствуют трем слоям архитектуры приложений.
^ Статические структурные модели, соответствующая слою БД. Модель данных прекрасно описывается с помощью статических структурных моделей, охватывающих статическую структуру отдельных компонентов (сущности и их атрибуты) и связи между компонентами.
^ Динамические модели, соответствующие слою правил процессов бизнеса. Такие модели хорошо описывают высокоуровневый поток работ пользователя, высокоуровневые модели процессов. Охватываются важнейшие функциональные компоненты и взаимодействия между ними.
Прототипирование, соответствующий слою документов (слою рабочего стола пользователя). Важная деталь слоя документов - интерфейс пользователя. Фактически единственным, очень мощным способом моделирования интерфейса пользователя является построение его прототипа. Прототип, который можно построить различными инструментальными средствами, позволяют проектировщику буквально за часы разработать модель интерфейса пользователя, учитывающую все его пожелания и предназначенную точно отразить конечный продукт. Проектирование хорошего интерфейса - скорее творческий процесс. Наблюдение за опытными разработчиками прототипов показывает, что их работа носит экспериментальный характер. Без прототипа пользователю было бы довольно трудно понять работу предлагаемой системы, поскольку они не могут достаточно четко представить себе работу интерфейсов. Прототипы не только легки в построении, но также легко изменяемы. Это дает возможность построить несколько альтернативных вариантов и выбрать из них лучший.
Таким образом, под прототипированием можно понимать итерационный процесс создания пользовательского интерфейса с помощью разработки различных вариантов этого интерфейса.