Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Информационные системы и технологии на предприятиях

Методы структурного анализа и проектирования ПО

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

o функциональную структуру системы;

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

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

Наиболее распространенным средством моделирования данных является модель "сущность - связь" (Entity-Relationship Model, ERM). Она впервые была введена П. Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, однако, по сути, это подмножество объектной модели предметной области. Одна из разновидностей модели "сущность - связь" используется в методе IDEF1-X, принадлежащей семейству стандартов IDEF, и реализуется в ряде распространенных CASE-средств (в частности, AH Fusion ERwin Data Modeler).

Методы объектно-ориентированного анализа и проектирования ПО. Язык UML

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

Большинство современных методов ООАП базируются на использовании языка UML. Унифицированный язык моделирования UML (Unified Modeling Language) это язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разных видов.

UML - это преемник того поколения методов ООАП, которые появились в конце 1980-х и начале 1990-х годов. Создание

UML фактически началось в конце 1994 г., когда Граде Вуч и Джеймс Рамбо начали работу по объединению их методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method. Тогда же в 1995 г . к ним присоединился автор метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. Таким образом, UML является прямым объединением и унификацией методов Г. Буча, Д. Рамбо и Г. Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:

o предоставить пользователям готовый к использованию выразительный язык визуального моделирования, что позволяет им разрабатывать осмысленные модели и обмениваться ими;

o предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;

o обеспечить независимость от конкретных языков программирования и процессов разработки;

o обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

o стимулировать рост рынка объектно-ориентированных инструментальных средств;

o интегрировать лучший практический опыт.

UML принят на вооружение практически всеми крупнейшими компаниями - производителями ПО (Microsoft, Oracle, IBM, Hewlett-Packard, Sybase и т.д.). Кроме того, практически все мировые производители CASE-средств, кроме IBM Rational Software, поддерживают UML в своих продуктах (Oracle Designer, Together Control Center (Borland), AllFusion Component Modeler (Computer Associates), Microsoft Visual Modeler). Стандарт UML версии 1.1, принятый OMG в 1997 г., содержит следующий набор диаграмм: '

Структурные модели (structural):

o диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;

o диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;

o последовательность выполняемых действий;

o передачу информации между функциональными процессами;

o отношения между данными. Распространенными моделями проектирования ПО:

1) функциональная модель SADT (Structured Analysis and Design Technique);

2) модель IDEF3;

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

Метод SADT является совокупностью правил и процедур, предназначенных для построения функциональной модели объекта определенной предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. его действия и связи между этими действиями. Метод SADT разработан Дугласом Россом в 1969 г. для моделирования искусственных систем средней сложности. Этот метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и т.д. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), которые являются основной частью программы ИСАМ (интегрированная компьютеризация производства), проводимой по инициативе ВВС США.

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

Метод SADT реализован именно в одном из стандартов этого семейства - IDEF-0, который был утвержден федеральный стандарт США в 1993 г.

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

o полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);

o жесткие требования метода, обеспечивающих получение моделей стандартного вида;

o соответствие подхода к описанию процессов стандартам ISO 9000.

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

Метод моделирования IDEF-3, что является частью семейства стандартов IDEF, разработан в 1980 г. для закрытого проекта Минобороны США. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF-3 и не достиг статуса федерального стандарта США, он получил широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF-0 (модели IDEF-3 могут использоваться для детализации функциональных блоков IDEF-0, не имеющих диаграмм декомпозиции). Основой модели IDEF-3 служит сценарий процесса, который выделяет последовательность действий и под-процессов анализируемой системы.

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

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

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

Подход RAD-технологии предполагает наличие трех составляющих:

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

o короткого, но тщательно проработанного производственного графика;

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

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

Жизненный цикл ПО с подходом RAD включает четыре стадии:

1) анализ и планирование требований;

2) проектирование;

3) реализация;

4) введение в действие.

На стадии анализа и планирования требований пользователи осуществляют следующие действия:

а) определяют функции, которые должна выполнять система;

б) выделяют важнейшие функции, которые требуют об-работки в первую очередь;

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

o ограничивается масштаб проекта;

o устанавливаются временные рамки для каждой из последующих стадий;

o определяется сама возможность реализации проекта в заданных размерах финансирования.

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

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

o подробнее рассматриваются процессы ИС;

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

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

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

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

o входной элемент приложения (входной документ или экранная форма);

o выходной элемент приложения (отчет, документ, экранная форма);

o запрос (пары "вопрос/ответ");

o логический файл (совокупность записей данных, используемых внутри применения);

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

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

o диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.

Модели поведения (behavioral):

o диаграммы вариантов использования (use case diagrams) - для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователей с системой);

o диаграммы взаимодействия (interaction diagrams);

o диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами;

o диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;

o диаграммы деятельности (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования или потоков управления.

UML имеет механизм расширения, предназначенный для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF-0, IDEF-IX, IDEF-3, DFD и ERM. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является языком, слабо типізується. К ее механизмов расширения относят: стереотипы; тегирование (именуемые) значения; ограничения.

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

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

Ограничения - это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL - Object Constraint Language), который невозможно представить с помощью нотации UML.

Основой взаимосвязи между структурным и объектно-ориентированным подходами является общность ряда категорий и понятий обоих подходов (процесс и вариант использования, суть и класс и т.п.). Эта взаимосвязь может проявляться в различных формах. Так, одним из возможных вариантов является использование структурного анализа как основы для объектно ориентированного проектирования. При этом структурный анализ следует прекращать, как только структурные модели начнут отражать не только деятельность организации, но и систему ПО. После выполнения структурного анализа можно различными способами приступить к определению классов и объектов. Другой формой проявления взаимосвязи можно считать интеграцию объектной и реляционной технологий. Реляционные СУБД являются на сегодня основным средством реализации крупномасштабных баз данных и хранилищ данных. Причины этого очевидны: реляционная технология используется достаточно долго, освоена огромным количеством пользователей и разработчиков, стала промышленным стандартом, в нее вложены значительные средства и создана множество корпоративных БД в самых разнообразных отраслях, реляционная модель проста и имеет чисто математическое представление; есть большое разнообразие промышленных средств проектирования, реализации и эксплуатации реляционных БД. Вследствие этого реляционные БД в основном используются для хранения и поиска объектов в так называемых объектно реляционных системах.

RAD-технология - кодирование. Одновременность создания клиентских и серверных мест ИС и активное привлечение пользователей к процессу разработки прикладного ПО обусловили распространение технологи быстрой разработки приложений RAD (Rapid Application Development) в рамках спиральной модели ЖЦ.

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

o общую информационную модель ИС;

o функциональные модели системы в целом и подсистемы, реализуемые отдельными командами разработчиков;

o интерфейсы между автономно работающими подсистемами;

o прототипы экранных форм, отчетов, диалогов.

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

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

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

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

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

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

o анализируется использование данных и определяется необходимость их распределения;

o разрабатывается физическое проектирование базы данных;

o формулируются требования к аппаратным ресурсам;

o устанавливаются способы повышения производительности;

o завершается разработка документации проекта.

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

o разработать новую систему "с нуля";

o создать модель деятельности предприятия, по которой можно разработать 1С;

o разработать 1С на основе старой.

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

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

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

Основной недостаток этого варианта - неэффективное использование системы-прототипа: после устранения недостатков в проекте и совершенствование постановки задачи прототипы не используют.

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

o разработка приложений итерациями;

o необязательность полного завершения работ на каждой стадии ЖЦПЗ;

o обязательность вовлечения пользователей в процесс разработки ИС;

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

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

o использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей;

o тестирование и развитие проекта, осуществляемые одновременно с разработкой;

o ведение разработки благодаря немногочисленной команде профессионалов;

o грамотное управление разработкой ИС, четкое планирование и контроль выполнения работ.

 
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 

Предметы
Агропромышленность
Банковское дело
БЖД
Бухучет и аудит
География
Документоведение
Естествознание
Журналистика
Инвестирование
Информатика
История
Культурология
Литература
Логика
Логистика
Маркетинг
Математика, химия, физика
Медицина
Менеджмент
Недвижимость
Педагогика
Политология
Политэкономия
Право
Психология
Региональная экономика
Религиоведение
Риторика
Социология
Статистика
Страховое дело
Техника
Товароведение
Туризм
Философия
Финансы
Экология
Экономика
Этика и эстетика
Прочее